*BSD News Article 73291


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!nntp.coast.net!zombie.ncsc.mil!newsgate.duke.edu!newshost.convex.com!cnn.exu.ericsson.se!eua.ericsson.se!news.algonet.se!news.hebel.net!news.sics.se!news.telia.se!news.helsinki.fi!news
From: torvalds@linux.cs.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,comp.unix.bsd.freebsd.misc
Subject: Re: TCP latency
Date: 10 Jul 1996 10:42:39 +0300
Organization: A Red Hat Commercial Linux Site
Lines: 64
Message-ID: <4rvmtf$ven@linux.cs.Helsinki.FI>
References: <4paedl$4bm@engnews2.Eng.Sun.COM> <31DC8EBA.41C67EA6@dyson.iquest.net> <4rqcsk$ff8@fido.asd.sgi.com> <31E106AF.41C67EA6@dyson.iquest.net>
NNTP-Posting-Host: linux.cs.helsinki.fi
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Xref: euryale.cc.adfa.oz.au comp.os.linux.networking:44605 comp.unix.bsd.netbsd.misc:3980 comp.unix.bsd.freebsd.misc:23194

In article <31E106AF.41C67EA6@dyson.iquest.net>,
John S. Dyson <toor@dyson.iquest.net> wrote:
> 
>Linus EQUATED latency with quality.  That is where alot of the
>problem was.  I had brought up the notion that there are alot
>of other factors associated with quality, and the cheer about
>the no-load latency being so low was kind-of overblown.

No, Linus did not EQUATE latency with quality.

Linus equated the _relation_ between latency and throughput with the
_relation_ between quality and quantity. I may have worded it badly, but
you also seem to still think the world is black-and-white. It isn't, and
in BOTH these relations you have to see both sides.

If you think quality vs quantity should always look at quality, you're a
very sorry individual.  I'm NOT slighting bandwidth by comparing it to
quantity, nor am I trying to make latency look important by comparing it
to quality.  BOTH are needed.  Quality without quantity is useless
(empty promises), and quantity without quality is fodder.  THAT was the
whole idea of the comparison (read the post again, without colouring it
with your preconceptions - there is nothing inherently "better" with
Quality vs Quantity). 

In fact, my posts tried actively to not mention any specific OS's at
all, and tried to mention the issues without getting too involved with
such details as what OS you're running, or even what _medium_ you're
running (I tried to make you think about latency and throughput on
memory subsystems too, not just TCP or networks: the issues are really
exactly the same).

In short, I'm NOT attacking BSD for having slower TCP latency: that may
well not even be true under different circumstances. I'll freely admit
that we have our own set of problems with Linux, and we won't just sit
still and be contented with what we have.  What I AM attacking is the
mentality that people show (not only you, John, but you've been arguing
that most) that seems to think that bandwidth is more important than
latency. 

I'd also like to argue that a "idle" system is not less important than a
"loaded" system.  For clients, the idle system tends to be the normal
case, while servers have the loaded behaviour.  BOTH are important, and
I find it very very scary indeed that the UNIX community _always_ seems
to think that servers and throughput are somehow "more important" than
clients and latency.  Damn UNIX idiots (and here I'm attacking the UNIX
vendors, not you, John). 

Discounting numbers just because they were done under low load is just
STUPID, John. You're discounting the client side with that, and the
client side is at least 50% of the equation (and depending on how you
count, the client side is likely to be 100:1 the server side, simply
because there are usually more clients ;-).

Finally, the discussion may have been a bit one-sided: we've been able
to discuss only the low-load latency, simply because we don't have
numbers for anything else.  I'd be more than happy to discuss server
side issues too, including high load, throughput, and lots of
connections per second.  I'm NOT ignoring that side or saying that it's
less important.  I'm not a black-and-white person.  But the fact is that
I don't have any numbers for it..  (hint hint, write a benchmark you
think is valid, and we'll discuss the numbers for THAT, along with the
validity of THAT benchmark.  Deal?). 

		Linus