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!hunter.premier.net!news-res.gsl.net!news.gsl.net!nntp.coast.net!news00.sunet.se!sunic!news99.sunet.se!news.rccn.net!master.di.fc.ul.pt!usenet
From: Pedro Roque Marques <roque@di.fc.ul.pt>
Newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,comp.unix.bsd.freebsd.misc
Subject: Re: TCP latency
Date: 17 Jul 1996 15:33:23 +0100
Organization: Faculdade de Ciencias da Universidade de Lisboa
Lines: 117
Sender: roque@oberon.di.fc.ul.pt
Message-ID: <x7enmbkkzw.fsf@oberon.di.fc.ul.pt>
References: <4paedl$4bm@engnews2.Eng.Sun.COM>
<31E106AF.41C67EA6@dyson.iquest.net> <4rvmtf$ven@linux.cs.Helsinki.FI>
<31E3D9E2.41C67EA6@dyson.iquest.net> <4s5bl2$qpg@linux.cs.Helsinki.FI>
<31E664EB.167EB0E7@inuxs.att.com> <4s67sk$oa9@fido.asd.sgi.com>
<31E6B8AB.3E6C@indy.celebration.net>
<x791cmo9cs.fsf@oberon.di.fc.ul.pt>
<31EA4153.167EB0E7@dyson.iquest.net>
NNTP-Posting-Host: oberon.di.fc.ul.pt
Mime-Version: 1.0 (generated by tm-edit 7.69)
Content-Type: text/plain; charset=US-ASCII
X-Newsreader: Gnus v5.2.25/XEmacs 19.14
Xref: euryale.cc.adfa.oz.au comp.os.linux.networking:45541 comp.unix.bsd.netbsd.misc:4094 comp.unix.bsd.freebsd.misc:23834
>>>>> "John" == John S Dyson <toor@dyson.iquest.net> writes:
John> Pedro Roque Marques wrote:
>> John,
>>
>> what are the precise mechanisms and design decisions in BSD
>> networking that make it's TCP scalable ?
>>
John> Good question. I would like to rather focus the argument on
John> how the general conclusion that the Linux TCP latency is
John> faster than FreeBSD by seeing that the latency under no load
John> is faster.
John, we seen good technical posts from people off the several camps
trying to interpret the latency issues and the general conclusions we
can draw is that the latency figures are in fact helpful (in the
spirit of the usefulness of a micro benchmark like lmbench) but don't
quite mimic the actual "response times" to user applications. I will
not go into personal arguments with nobody but i think that the
technical posts show that:
a) TCP latency is not irrelevant. It can be an helpful indicator for
developers.
b) TCP latency can hardly give you a noticion of what OS is better in
terms of user response or pratical applications.
c) The results of the TCP latency tests we have may not cover special
conditions that occur on high load but the general properties that
make you have a good low load number are also helpful under
load. Not having high-load numbers does not invalidate the unloaded
results, it simply limits the conclusions you can draw on them.
John> I find that to be interesting considering that
John> no such data is presented.
As said above that only limits the conclusions you can draw on
them. The no load numbers have suficient implications for the work i
develop for me to consider them relevant and feel like to exchange
ideas on them.
John> At least that is the basis of my position that excessive
John> claims are being made based upon benchmarks results that are
John> presented publically. I would like to see some details
John> actually show that the claims are substantiated .
>> Can you argue that BSD TCP is inherently more scalable that
>> Linux's ? Or even that is prepared for large servers ?
>>
John> I believe that the issue has been that benchmarks that show
John> performance under no load do not indicate performance under
John> heavy load.
John, Larry has explained quite well the usefullness of lmbench and
it's philosophy. IMHO lmbench is a great work and a good contribution
to OS design in general. We just need to know what the figures
represent. You said that you do have benchmarks designed with other
philosophies that can show things like scalability. I personally
believe they could be usefull for a lot of people and i urge you to
publish them but i strongly believe the two benchmarks philosophies to
be orthogonal. Both valid, both usefull, both with a different set of
conclusions you can draw from.
John> A good example of this is the old (1.2.X)
John> context switching performance. Works really well until you
John> run 20 or so processes. Same idea.
John, i can show you line by line that the improvements to TCP latency
on Linux come from code optimizations without creation of special fast
paths for the one packet case. That does not preclude problems under
high load but it does show that improvements under no load also help
you under load (with one exception which is the delay ack timer that
could get out of control with *extreme* high load - I'm not saying it
does ... but this does not invalidate the rest of the work on this).
>> (please do focus your answer on TCP)
>>
John> Well, let's say that you have internal data structures that
John> map the IP/Port addresses and protocol to a connection.
John> Those data structures can be hashed or a single linked list
John> or some combination inbetween.
I would believe that only extremely naif implementations fail to use
hashed searches to demultiplex PCBs. Hoping not to offend anyone, BSD
networking is not really rocket science, everybody has studied it and
a lot of people have made modifications to it in one way or
another. (This could be seen as a compliment to the original work).
John> There are other things that affect scalability (my VM work
John> has shown several areas that are applicable to most areas of
John> the system.) We can discuss that later.
I would be interessted. Do you have anything written i can fetch ?
John> Suffice it to say,
John> that there are significant scalability issues, and it is not
John, if we want to turn into TCP scalability we should start by
listing the problems... One of the biggest experiences on TCP
scalability is called "altavista". It's really a pleasure to talk to
the DEC people on this issue ... From what i've heard from them the
biggest scalability problems don't affect ``a generally good solution
for a good latency'' (it would be quite difficult to explain what this
means, so please don't ask unless you have to ;-)).
John> However, I am not making a claim that FreeBSD is
John> faster/slower in the networking area than Linux. I am
John> making a claim that the benchmark results do not correspond
John> to the claim being made... Simple as that. It is mostly an
^^^^^^^^^^^^^^^^
From reading the flame feast mails on this thread i never got to
understand what was the claim. The only claim i've seen is that
latency is not irrelevant, claim that I and most of the participants
on this thread seam to consider correct, as long as you don't try to
draw conslusions on the best www/ftp/whatever server based on it.
John> issue of truth in advertising and integrity.
regards,
Pedro.