Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!nntp.coast.net!sgigate.sgi.com!news-res.gsl.net!news.gsl.net!swrinde!elroy.jpl.nasa.gov!decwrl!news.PBI.net!news.mathworks.com!newsfeed.internetmci.com!zdc!zdc-e!szdc-e!news From: "John S. Dyson" <toor@dyson.iquest.net> Newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,comp.unix.bsd.freebsd.misc Subject: Re: TCP latency Date: Tue, 09 Jul 1996 20:47:31 -0500 Organization: John S. Dyson's home machine Lines: 69 Message-ID: <31E30BB3.41C67EA6@dyson.iquest.net> References: <4paedl$4bm@engnews2.Eng.Sun.COM> <4rfkje$am5@linux.cs.Helsinki.FI> <31DC8EBA.41C67EA6@dyson.iquest.net> <4rqcsk$ff8@fido.asd.sgi.com> <4rrm33$oor@dworkin.wustl.edu> <4ru0p1$7e5@fido.asd.sgi.com> NNTP-Posting-Host: dyson.iquest.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0b5a (X11; I; FreeBSD 2.2-CURRENT i386) Xref: euryale.cc.adfa.oz.au comp.os.linux.networking:44580 comp.unix.bsd.netbsd.misc:3979 comp.unix.bsd.freebsd.misc:23187 Larry McVoy wrote: > > Chuck Cranor (chuck@ccrc.wustl.edu) wrote: > : Hi Larry, hmm, I bet you dislike reading academic papers as much as I > : do :-). At your suggestion I re-read <4rfkje$am5@linux.cs.Helsinki.FI> > : (can't seem to find the second message you are referring to) and I came > : to the same conclusion that I did the first time I read it: the analysis > : presented is too simplistic because it doesn't take into account the > : issue of scaling and performance under load. > > > : Writing stuff like "Think Quality (latency) vs Quantity (throughput)" > : implies that we are looking at a problem that only has two dimensions, > : and that just isn't true. Isn't this one of the motivations behind > : lmbench 2.0? > > I think you are quoting Linus out of context. I aggree that there are > more than two dimensions, but I happen to think that Linus has put his > finger on the first order terms. If you have decent single stream > latency and throughput, scaling that is fairly straightforward. If you > don't, then when you try and get good scaling numbers, you don't know > why it isn't working. > It was pretty obvious that he had over-simplified the argument. Unfortunately, there are alot of people out there who believe that he is an authority on OS subjects. Gross oversimplification in both the claims of superiority and in judging the relative merits of various parameters is what I have been arguing against. > Here's a for instance. When you go look at scaling issues in TCP (yeah, > we do look at that, even me :-), if your single threaded numbers are OK, > then next thing is the lookup code and MP contention. You *know* that > before you even start staring at the code. Linux has this problem: it > gets good latencies if there aren't other sockets in the system and then > it falls apart. > That is *exactly* what I have been arguing. Not necessarily that Linux is slower (which I have heard that it really is under load and you aren't the only one to say so), but that the claims of superiority are unfounded given the benchmarks that we have been discussing. > > : If anything, we need more analysis of the numbers. Just collecting a > : matrix of benchmark results is not that useful [not to pick on Larry, > : but look at http://reality.sgi.com/employees/lm/lmbench/lmbench-summary]. > > The hell it isn't. You obviously don't have to deal with the mentality > of corporations. While you may want pages of analysis, the people that > make resource decisions want a single number that says "we're great" or > "we suck". They apply engineering resources to the "we suck" parts > (if you're lucky). > So is this a commercial venture, or does it have educational value? Perhaps both? Why not carefully analyze the reasons for the results? Then we all learn something. The benchmarks that I see randomly posted (and truthfully, my posted benchmark results) are of much less value without a thorough understanding of what is measured. So were the LMBENCH benchmarks funded by SGI? John