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