Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!spool.mu.edu!sgigate.sgi.com!newsfeeder.sdsu.edu!chi-news.cic.net!cs.utexas.edu!uwm.edu!news-res.gsl.net!news.gsl.net!news.mathworks.com!newsfeed.internetmci.com!in2.uu.net!EU.net!Austria.EU.net!siemens.at!siemens.at!not-for-mail From: mingo@pc5829.hil.siemens.co.at (Ingo Molnar) Newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,comp.unix.bsd.freebsd.misc Subject: Re: TCP latency Followup-To: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,comp.unix.bsd.freebsd.misc Date: 22 Jul 1996 14:01:26 GMT Organization: Siemens AG Austria Lines: 34 Message-ID: <4t01jm$bot@news.siemens.at> References: <4paedl$4bm@engnews2.Eng.Sun.COM> NNTP-Posting-Host: pc5829.hil.siemens-austria X-Newsreader: TIN [UNIX 1.3 BETA-950824-color PL0] Xref: euryale.cc.adfa.oz.au comp.os.linux.networking:46034 comp.unix.bsd.netbsd.misc:4137 comp.unix.bsd.freebsd.misc:24207 J.T. Conklin (jtc@hippo.cygnus.com) wrote: : lm> Maybe gettimeofday() would have been a better null syscall, what : lm> do you think? : : Maybe not. In my development kernel, gettimeofday is a user-land : wrapper around clock_gettime(). Thus it has additional function call : overhead plus the (relatively expensive) divisions needed to convert : timespecs to timevals. i think he ment 'gettimeofday(0,0)'. No real code runs in that case, only the kernel enter and exit logic. getpid() executes in 225 cycles on my system, gettimeofday() executes in 228 cycles. The overhead for the two calls (if memory serves): getpid(): pushing the pid onto the user space stack gettimeofday(): getting two parameters (both are 0) from user space : With those numbers as a baseline, you can then measure the additional : overheads related to timers, file descriptors/systems, process tables, : etc. if those numbers are interesting. i think Mr. McVoy has done a great job in that field. I'm sure you dont want to know how many things he has taken care of, to get a useful microbenchmark on all current Unix kernels :)) And i think many people misinterpret the lmbench package. It's aim is not to prove things, but to analyze kernels. The only thing i miss is nanosec resolution :) [i know it cant be done on all platforms :((] -- mingo