Return to BSD News archive
#! rnews 3166 bsd Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!qns3.qns.net!imci4!newsfeed.internetmci.com!in2.uu.net!zdc!zdc-e!szdc-e!news From: "John S. Dyson" <toor@dyson.iquest.net> Newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,comp.unix.freebsd.misc Subject: Re: TCP latency Date: Sat, 06 Jul 1996 13:17:56 -0500 Organization: John S. Dyson's home machine Lines: 52 Message-ID: <31DEADD4.41C67EA6@dyson.iquest.net> References: <4paedl$4bm@engnews2.Eng.Sun.COM> <4pf7f9$bsf@white.twinsun.com> <31D2F0C6.167EB0E7@inuxs.att.com> <4rf4me$nve@hpindda.cup.hp.com> NNTP-Posting-Host: dyson.iquest.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0b5Gold (X11; I; FreeBSD 2.2-CURRENT i386) Xref: euryale.cc.adfa.oz.au comp.os.linux.networking:44215 comp.unix.bsd.netbsd.misc:3949 Rick Jones wrote: > > TCP is indeed a streaming protocol, the performance of which is bound > by several things. One is how many CPU cycles it takes to send/recv a > packet. Another is the window size divided by the end-to-end latency > (W/RTT). > >.... > The greater the latency, the larger the window you need to overcome > it. > > It isn't all just mbit/s. think of an NFS server - lots and lots of > little requests like getattrs and lookups and such. That performance > will be bound more my the latency of the system(s) than the bandwidth > of the link. > I agree with you, and my statement about "streaming protocol" and other comments have been try to direct the discussion to all of the other issues in the communications path (from the process in one machine to the process in the other machine) and also the overheads associated with the operations in the machines. Note that the results that had been presented show that there is a performance difference between the driver in Linux and the driver in FreeBSD. That needs to be investigated. However the basic network performance doesn't appear to be so great. (Note that FreeBSD is usually compiled with more conservative compile options, and the difference shown for the network code itself is about the amount that I would expect for compiler options.) My other point is that there are factors that affect latency, and the benchmark results being talked about are only a small part of the picture. (It is essentially a benchmark testing one connection being made sequentially, with the rest of the machine doing unspecified things, (probably nothing.)) I would like to see a benchmark with many active connections and (perhaps if desired) several concurrent connection requests. That would simulate more closely the environment in an active server. As I know that you already know, there are serious scalability issues in TCP code. The lat_connect and lat_tcp benchmarks appear to show only a very small part of the picture. They only show the results given a single connection. Scalability does not appear to be shown at all. Also, I agree that "latency" is important; But the kind of latency being talked about in the lmbench benchmarks isn't a very complete picture. John