Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.cis.okstate.edu!newsfeed.ksu.ksu.edu!news.mid.net!news.dra.com!news.starnet.net!spool.mu.edu!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 Date: 9 Jul 1996 16:18:41 GMT Organization: Silicon Graphics Inc., Mountain View, CA Lines: 77 Message-ID: <4ru0p1$7e5@fido.asd.sgi.com> 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> 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:44497 comp.unix.bsd.netbsd.misc:3974 comp.unix.bsd.freebsd.misc:23131 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. Hey, first things first. You've got the cart before the horse. Let's take TCP latency as an example. Suppose the benchmark showed how well you could do 100 latency tests in parallel. The numbers don't tell you if the perf problem is in your socket lookup code or if it is elsewhere. The reason is that you are mixing the single threaded case with the multi threaded case. I explictly shipped all single threaded (or uniprocessor, whatever you want to call it) benchmarks because I wanted people to see how fast the basic operations worked. I'm fully aware this doesn't tell the whole story. I focussed on the single threaded case because all of the SMP OS people were happily ignoring those cases, using the fact that they could scale crappy performance to get to OK performance. I want to get people fixing the single threaded case *before* they move on to the scaling case. Otherwise, all you get is people scaling poor base line results. : 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. 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. : If you are interested in reading some quality papers in a related area : that address scaling, you might consider reading some of Jon Turner's : work on ATM Switching (http://www.arl.wustl.edu/~jst). Over the years : I've noticed that if you present something to Jon and don't address : the scaling issue he will be sure to ask you about it in the Q/A session. He may have great taste in performance issues, but he sure has bad taste in networking devices. I personally wouldn't (and haven't) waste my time with ATM, that's just stupid. I'm a little suspect of somebody that is investing time in ATM, are you sure this guy is that bright? : 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). While playing around with free operating systems is fun and all, the real point here is to get the corporations to give you an OS that you can use, not some slow junker like solaris. The corporation mentality is quite different from that found on the net. Which would you rather have: something that makes solaris/irix/hpux/aix better or something that makes freebsd/linux better? Which one do you think is going to impact your work life more? -- --- Larry McVoy lm@sgi.com http://reality.sgi.com/lm (415) 933-1804