Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.mel.connect.com.au!news.mira.net.au!vic.news.telstra.net!act.news.telstra.net!psgrain!usenet.eel.ufl.edu!spool.mu.edu!howland.reston.ans.net!swrinde!news-res.gsl.net!news.gsl.net!news.mathworks.com!newsfeed.internetmci.com!uwm.edu!fnnews.fnal.gov!unixhub!news.Stanford.EDU!kithrup.com!cygnus.com!usenet
From: jtc@rtl.cygnus.com (J.T. Conklin)
Newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,comp.unix.bsd.freebsd.misc
Subject: Re: TCP latency
Date: 22 Jul 1996 16:33:32 -0700
Organization: Cygnus Support
Lines: 46
Message-ID: <tjenm3ualv.fsf@rtl.cygnus.com>
References: <4paedl$4bm@engnews2.Eng.Sun.COM> <4t01jm$bot@news.siemens.at>
NNTP-Posting-Host: rtl.cygnus.com
In-reply-to: mingo@pc5829.hil.siemens.co.at's message of 22 Jul 1996 14:01:26
GMT
X-Newsreader: Gnus v5.1
Xref: euryale.cc.adfa.oz.au comp.os.linux.networking:46087 comp.unix.bsd.netbsd.misc:4140 comp.unix.bsd.freebsd.misc:24240
>>>>> "Ingo" == Ingo Molnar <mingo@pc5829.hil.siemens.co.at> writes:
Ingo> : Maybe not. In my development kernel, gettimeofday is a user-land
Ingo> : wrapper around clock_gettime(). Thus it has additional function call
Ingo> : overhead plus the (relatively expensive) divisions needed to convert
Ingo> : timespecs to timevals.
Ingo> i think he ment 'gettimeofday(0,0)'. No real code runs in that case,
Ingo> only the kernel enter and exit logic.
I say again that in my (netbsd) development kernel, gettimeofday is a
user-land wrapper. In the case of getimeofday(0,0), no system call is
made at all. IMO, this makes this particular case useless as a system
call latency benchmark, as that's not what's being measured.
Ingo> : With those numbers as a baseline, you can then measure the additional
Ingo> : overheads related to timers, file descriptors/systems, process tables,
Ingo> : etc. if those numbers are interesting.
Ingo> i think Mr. McVoy has done a great job in that field. I'm sure you dont
Ingo> want to know how many things he has taken care of, to get a useful
Ingo> microbenchmark on all current Unix kernels :))
I agree that this is difficult --- perhaps impossibly difficult.
However, before you can legitimately compare the results of different
implementations, you must be certain that what you're comparing is
equivalent. Without source code for some of the systems being
measured, you can only guess.
It appears that using a write to /dev/null is a particularly bad
choice for measuring syscall latency because it includes some amount
of filedescriptor/filesystem overhead that differs from implementation
to implementation.
I suspect this number might be interesting for applications needing to
know this aspect of filesystem overhead. I would not criticize it for
being advertised as such. But when it's called a syscall latency
benchmark, it misrepresents itself.
Ingo> And i think many people misinterpret the lmbench package. It's aim is
Ingo> not to prove things, but to analyze kernels.
And used in that manner, it's a good tool. My only issue is when it
is used to compare different things, and then those figures are used
out of context.
--jtc