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!!! :-)