*BSD News Article 73177


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mira.net.au!vic.news.telstra.net!act.news.telstra.net!psgrain!usenet.eel.ufl.edu!spool.mu.edu!sgigate.sgi.com!news.msfc.nasa.gov!elroy.jpl.nasa.gov!decwrl!nntp.crl.com!symiserver2.symantec.com!usenet
From: tedm@agora.rdrop.com
Newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,comp.unix.bsd.freebsd.misc
Subject: Re: TCP latency
Date: 9 Jul 1996 04:22:12 GMT
Organization: Symantec Corporation
Lines: 95
Message-ID: <4rsmpk$quj@symiserver2.symantec.com>
References: <4paedl$4bm@engnews2.Eng.Sun.COM> <31D2F0C6.167EB0E7@inuxs.att.com> <4rfkje$am5@linux.cs.Helsinki.FI> <31DC8EBA.41C67EA6@dyson.iquest.net> <4rlf6i$c5f@linux.cs.Helsinki.FI> <31DEA3A3.41C67EA6@dyson.iquest.net> <Du681x.2Gy@kroete2.freinet.de> <31DFEB02.41C67EA6@dyson.iquest.net> <4rpdtn$30b@symiserver2.symantec.com> <31E16AF1.1568F730@lambert.org>
Reply-To: tedm%toybox@agora.rdrop.com
NNTP-Posting-Host: 198.6.34.2
X-Newsreader: IBM NewsReader/2 v1.2
Xref: euryale.cc.adfa.oz.au comp.os.linux.networking:44433 comp.unix.bsd.netbsd.misc:3972 comp.unix.bsd.freebsd.misc:23092

In <31E16AF1.1568F730@lambert.org>, Terry Lambert <terry@lambert.org> writes:
>tedm@agora.rdrop.com wrote:
>] [blah blah deleted]
>] 
>] I have to interject something here on this discussion:
>] 
>] I feel this has gotten so academic that it is meaningless.  Who
>] cares what the latency/throughput figures are or who is winning
>] the current benchmark in vogue!
>
>
>I would have to hazard the guess that people who design before
>they implement, care, since a discussion of the issues is
>important to choosing the correct approach for a design.
>
>It's called "engineering".
>

I have nothing against engineering.  However, I think you missed my point, which is
simply that in a real world network there are many more factors that are
uncontrolled than what are controllable on the server itself.

One of the reasons that I feel this discussion is worthless is that among all the
numbers that people have tossed out no one has mentioned anything about the
network hardware _on the server_ let alone the network hardware on the
network itself. (which I still maintain has a lot more effect on perceived server
performance)

I suppose that the measured latency figures are going to be the same if a ISA
8-bit 3Com card is used, verses a PCI SMC8XXX series card?  Of course not,
you and I both know that the SMC driver under FreeBSD is a lot better than
the 3C503.  At least, the last time I tested it it was.

What good is it if you have wonderful kernel engineering, when the performance
gains are all eaten up by inefficient, unstable drivers and crummy hardware.

I know that anyone setting out to design hardware has a whole raft of tradeoffs
to make, espically network hardware.  Some of the network cards, such as the
3C509, push a little of this off on to the user, with config programs that can
be set to be "server mode" or "dos mode" on the card, however this is not going
to compensate for a hardware design approach that is weighted against the
OS in use.

For example, compare a network card that has no DMA, no busmastering, and
no shared memory available.  The only way to communicate with this card is
through the good, old IN and OUT instructions.  Are you argueing that such a card
is going to have equivalent performance to a network card that has shared
memory and busmastering available?  Well, I suppose so if the driver for the
first card is excellent, and the driver for the second card stank, or perhaps the
busmastering hardware in the second card is broken in some manner.

Even better, the first card may be faster simply because the OS (DOS) is not
capabable of supporting the fancy hardware.  There are companies that are
going to be making and selling such hardware simply because the ignoramuses
don't know any better.

This is exactly what drove the sale of poor-excuse SCSI adapters such as the
Adaptec 1510, the Seagate ST01, the Always IN1000 (or is it 2000) the Future
Domain 950, etc. 

I suppose one can always take the bad excuse that "well, drivers are the
responsibility of the hardware vendor, we have no control if they design crap
hardware and shoddy drivers."  Well, people judge the performance of
the operating system based on what this shoddy hardware is making it appear
to do!  Microsoft learned this long ago, that is why when they release new
OS'es they just say hang it all and go ahead and write a lot of the more common
drivers for the garbage-grade hardware out there.  (or modify buggy-supplied
code)

Now, I know that OS developers walk a thin line, on one hand they don't want
to piss off all the folks that didn't know any better and bought shoddy hardware,
on the other they don't want to encourage people to go out and buy stuff like
IDE, or Sony, or Mitshumi (sp) proprietary CDROMS, floppy-controller tape drives,
non-parity memory, etc. etc.  The README files in FreeBSD alone are an excercise
in politics, go through them and you get the appearance that FreeBSD supports
this vast number of hardware peripherals.  Well, maybe it does, then how come
people always seem to be running NCR or Adaptec SCSI adapters, and SCSI
tapedrives, CD's and disks, and SMC or NE2000 clone network cards ?!?!?

At the least, someone in the FreeBSD camp could put together a "reference"
FreeBSD machine composed of recommended hardware peripherals.  In other
words, "this is what you buy if you intend to run FreeBSD as a serious server"

Theory does indeed have a place in any OS design. Yes, latency issues are
indeed important.  However, attempting to assume that OS design goes on in a
total vacuum, totally and completely unaffected by hardware, is rediculous.
What I am attempting to convey is that the real-world outside forces such
as network latency, efficient/inefficient driver design, and network hardware
performance, affect what your arguing over far more.

I guess it's easy to discuss topics like TCP latency, as long as we don't drag in
all that dirty, impossible-to-control, improbable-to-predict, and messy
things like Network Adapters, Cabling and all that nasty stuff.  After all, the
whole point of this is to see how fast we can drive the loopback device!!! :-)