Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!solace!eru.mt.luth.se!bloom-beacon.mit.edu!news.mathworks.com!fu-berlin.de!irz401!orion.sax.de!uriah.heep!news From: j@uriah.heep.sax.de (J Wunsch) Newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,comp.unix.bsd.freebsd.misc Subject: Re: TCP latency Date: 16 Jul 1996 10:14:59 GMT Organization: Private BSD site, Dresden Lines: 36 Message-ID: <4sfq33$meq@uriah.heep.sax.de> References: <4paedl$4bm@engnews2.eng.sun.com> <4s6k8o$4o0@fox.ksu.ksu.edu> <31E6FD92.41C67EA6@dyson.iquest.net> <4s8cuq$ljd@bertrand.ccs.carleton.ca> <31E7C0DD.41C67EA6@dyson.iquest.net> <4s8tcn$jsh@fido.asd.sgi.com> <31E80ACA.167EB0E7@dyson.iquest.net> <4sadde$qsv@linux.cs.helsinki.fi> <31E9E3A7.41C67EA6@dyson.iquest.net> <4sefde$f0l@fido.asd.sgi.com> Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) NNTP-Posting-Host: localhost.heep.sax.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: knews 0.9.6 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Xref: euryale.cc.adfa.oz.au comp.os.linux.networking:45409 comp.unix.bsd.netbsd.misc:4074 comp.unix.bsd.freebsd.misc:23725 lm@neteng.engr.sgi.com (Larry McVoy) wrote: > Maybe gettimeofday() would have been a better null syscall, what do you think? No. If you de-optimized your gettimeofday() in order to give as accurate information as possible, but have poor hardware (i.e., everything less than i586 on the iNtel front), gettimeofday() requires IO operations to the ISA bus, and this will make it _very_ slow, for the benefit of giving accurate information (i.e., the returned values have a much better resolution than ``HZ''). So you will essentially measure IO overhead on an obsolete bus system. Looking at syscalls.master... kill(1, 0) - should just return you success or EPERM, depending on your effective UID), has to walk the process table however, so it depends on the organization of this table dup(0) - might have some VFS overhead getppid() - cannot be cached in userland, the parent might have died since the previous call, so the process got a new parent umask(umask(0)) - does modify the process context in the kernel, but the modification is of a very simple nature -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)