*BSD News Article 73236


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