Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!nntp.coast.net!news-res.gsl.net!news.gsl.net!news.mathworks.com!nntp.primenet.com!news.cais.net!nntp.uio.no!nntp-oslo.UNINETT.no!nntp-trd.UNINETT.no!not-for-mail From: sthaug@nethelp.no (Steinar Haug) Newsgroups: comp.os.linux.networking,comp.unix.bsd.freebsd.misc Subject: Re: TCP latency Date: 13 Jul 1996 20:33:39 GMT Organization: Nethelp Consulting, Trondheim, Norway Lines: 60 Message-ID: <4s9173$b8l@verdi.nethelp.no> References: <4paedl$4bm@engnews2.Eng.Sun.COM> <31E106AF.41C67EA6@dyson.iquest.net> <4rvmtf$ven@linux.cs.Helsinki.FI> <31E3D9E2.41C67EA6@dyson.iquest.net> <4s5bl2$qpg@linux.cs.Helsinki.FI> <31E664EB.167EB0E7@inuxs.att.com> NNTP-Posting-Host: trane.uninett.no In-reply-to: "John S. Dyson"'s message of Fri, 12 Jul 1996 09:44:59 -0500 Xref: euryale.cc.adfa.oz.au comp.os.linux.networking:45114 comp.unix.bsd.freebsd.misc:23493 ["John S. Dyson"] | > No, read the numbers again. Linux was faster on loopback too. | > | Given the same kernel compile options, that has not shown to be | true. The difference of 20usecs is well within the range of them. . | I get big differences on kernel compile options (I have seen 10% or | better given -O vs. -O2 -fomit-frame-pointer, especially on code that | uses lots of registers.) OK, let's see if we can get at least some of these problems out of the way. I promise this will be the last posting from me on the subject ;-) I have repeated my original lat_tcp measurements for the loopback case. It's been done on *one* processor only, specific details: Processor: AMD 5x86-133, overclocked to 160 MHz Motherboard: ASUS PVI-486SP3, 24 MByte memory, 256 kByte cache OS: Either FreeBSD 2.2-960612-SNAP or Linux 2.0.0 C compiler: gcc-2.6.3 for FreeBSD, 2.7.2 for Linux Optimization: Three different levels: 1. Default FreeBSD: -O 2. Default Linux: -O2 -fomit-frame-pointer -fno-strength-reduce 3. Mix: -O2 -fomit-frame-pointer I did 3 also because I thought that might be the fastest. This was not necessarily the case; more on that below. I also tried the -m486 option, which Linux uses by default on my AMD. It made absolutely no difference. I ran 400 iterations of lat_tcp on an unloaded machine (single user mode). As has been pointed out, this says nothing about scaling, or performance under load conditions. It *does* say something about what's the minimum achievable latency. Times below are the averages over 400 iterations, in usecs. Optimization FreeBSD Linux -------------------------------------------- 1 389 351 2 379 366 3 367 369 I also estimated standard deviation using the normal formula. It was in the range 10-15 for all of the numbers above. And what does it mean? - On this particular machine, the measured versions of FreeBSD and Linux are so close on the lat_tcp loopback test that I'm highly doubtful it makes any difference at all in practice. - Linux was somewhat faster on the average for two of the optimization levels, but given the estimated standard deviation I find it hard to draw any conclusion from this. - The compilation options have *some* effect, but not necessarily what you think. You need to actually try it out to draw sensible conclusions. Steinar Haug, Nethelp consulting, sthaug@nethelp.no