Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mira.net.au!news.mel.connect.com.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.eng.convex.com!newshost.convex.com!newsgate.duke.edu!news.mathworks.com!newsfeed.internetmci.com!sgigate.sgi.com!fido.asd.sgi.com!neteng!lm From: lm@neteng.engr.sgi.com (Larry McVoy) 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: 13 Jul 1996 19:28:23 GMT Organization: Silicon Graphics Inc., Mountain View, CA Lines: 76 Message-ID: <4s8tcn$jsh@fido.asd.sgi.com> References: <4paedl$4bm@engnews2.Eng.Sun.COM> <x7687w1dsr.fsf@oberon.di.fc.ul.pt> <4s220u$nmq@symiserver2.symantec.com> <31E53C2B.41C67EA6@inuxs.att.com> <4s6k8o$4o0@fox.ksu.ksu.edu> <31E6FD92.41C67EA6@dyson.iquest.net> <4s8cuq$ljd@bertrand.ccs.carleton.ca> <31E7C0DD.41C67EA6@dyson.iquest.net> Reply-To: lm@slovax.engr.sgi.com NNTP-Posting-Host: neteng.engr.sgi.com X-Newsreader: TIN [version 1.2 PL2] Xref: euryale.cc.adfa.oz.au comp.os.linux.networking:45096 comp.unix.bsd.netbsd.misc:4025 comp.unix.bsd.freebsd.misc:23483 : Yes I am disputing the fact, the fact is that he had said that the : TCP latency is faster. Bzzt, that is the wrong conclusion. The : TCP latency under NO LOAD is faster. Most people don't understand : the difference, but one claim is accurate, and the other is NOT. Nobody said that Linux' TCP latency under load is faster, in fact, I pointed out that it degrades to about the same as FreeBSD under load. I said, and the benchmark said, that a ping pong test using TCP was faster under Linux than on FreeBSD. You turned it into this general statement about TCP latency under all conditions. That's your problem. : The point is being missed, and this is why either Linus either doesn't : know the scalability issues, or he is disinforming. The issue is that : when most people who use the OS see the latency problem, it is when the : systems are under heavy load, and the latency that was measured by lat_tcp : is pretty much meaningless. It's useful to know what your protocol stack is costing you. If you load up the system, you don't know if the degradation is due to cache misses, TCP lookup problems, locking (either bottom/upper half and/or SMP), etc. It's useful to know the unloaded latency because it is safe to say that it is unlikely that the latency is going to get better under load (it could, but I think we can agree - maybe - that that is an anomaly). So if you are trying to scale to N ping pong tests, and you know that one takes 10% of your system, then you have a pretty good idea that you aren't going to do much better than 10 (yes, you actually could do much better than 10 if you worked your OS right. Bitch about that when you've got an OS that shows better average latency under load than under no load; I've been through this, it isn't easy. But since you are screaming about how you have this great OS under load, perhaps you'd like to share those great results?). : > Of course, you might have trouble finding a benchmark that everyone : > agrees is `meaningful'. Although you might possess the arrogance to : > declare what `most FreeBSD users' consider meaningful, I'm almost : > certain Linus will let the Linux community speak for itself. : > : The only arrogance that I have seen is that certain people are trying : to pass off benchmark results with bogus conclusions. You seem to be drawing the bogus conclusions. I personally let the numbers speak for themselves. In the year or so that lmbench has been in widespread public use, the only time I ever get involved (and I shouldn't) has always been because of some BSD issue. : Please take a look at lat_tcp, and considering that it is run alone : on a machine and there are generally only a few other TCP connections : on the machine... How can it POSSIBLY show ANYTHING but NO-LOAD latency? : If a claim is made other than NO-LOAD latency, then someone is trying to : pull the wool over your eyes... And where is that claim being made, John? Where? You can claim that it would be better if the TCP latencies where shown as a function of the number of copies running in parallel, and I would agree that that's a nice benchmark, but so what? Nobody claimed that lat_tcp was a scaling benchmark. Maybe the problem is that you assumed it was, or you wanted it to be. It's kind of fun to contrast this with the Linux crowd: BSD guys: "your benchmark sucks! your numbers are wrong! you mislead the world! you suck! whine!" Linux guys: "Hey Larry, the null syscall benchmark is busted because we can do a null syscall in about 1 usec. You need to change it so it times in nanoseconds". So, I give up on convincing the BSD crowd of anything. I have too much work to do anyway. If you have specific requests for the next release of lmbench, please write up a "man page spec" for what you want. Steal one of the existing lmbench man pages and modify it. Send that to me. -- --- Larry McVoy lm@sgi.com http://reality.sgi.com/lm (415) 933-1804