Date: Mon, 2 Dec 1996 21:28:42 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: davem@jenolan.rutgers.edu (David S. Miller) Cc: jkh@time.cdrom.com, dyson@FreeBSD.org, dennis@etinc.com, kpneal@pobox.com, hackers@FreeBSD.org, torvalds@cs.helsinki.fi, lm@engr.sgi.com, iain@sbs.de, sparclinux@vger.rutgers.edu Subject: Re: TCP/IP bandwidth bragging Message-ID: <199612030228.VAA01336@dyson.iquest.net> In-Reply-To: <199612030217.VAA18178@jenolan.caipgeneral> from "David S. Miller" at Dec 2, 96 09:17:34 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Date: Mon, 02 Dec 1996 17:56:00 -0800 > From: "Jordan K. Hubbard" <jkh@time.cdrom.com> > > Which is a rather porous argument, to say the least. > > Morons: "We've proven that our car goes much faster than the > competition's does when we have all 4 doors open, due to the > superior wind-resistance characteristics of our door design." > > Competition: "Why in god's name would you want to optimize for that? > Who in their right mind would drive with all the doors open?" > > Morons: "You're just jealous. Beat our open-door numbers or shut up." > > The situation is not the same. > > Likewise, testing things like loopback vs actual transmission > performance or no-load machine response is just as silly as optimizing > for the corner case of driving with your doors open. Who bloody > *cares* what the results of a meaningless benchmark are, and why would > you ever want to get "better numbers" in an area of trivial > measurement where the only real result is to look better on some > marketdroid's tally sheet, no doubt obfuscating the code in question > and perhaps even degrading performance for the cases your users > actually *do* care about. > > You assertion poorly assumes that all of us agree that the benchmarks > in question are in fact meaningless. Many people (people in the "real > world") will disagree with you. > > And as for the marketdroid's tally sheet, that sells machines > pinhead. If you think it does not, why does the government spec > lmbench numbers for all purchases these days? What concrete numbers > are you able to put on that tally sheet? None, because whatever > benchmarks the freebsd people are using to perform their improvements > are under lock and key, most likely because once the Linux crowd had > these at their disposal, we'd fix the problems they show because > they'd be trivial. I'm not concerned. > > I think it is funny how the Linux crowd brags about numbers that > anyone can grab the sources for and run for themselves. Whereas the > freebsd people brag about performance characteristics that they claim > _they_ can test and get numbers for, but the rest of the world has to > wonder whether such benchmarks even exist. > > Those tactics might sound good to Microsoft or (though I hope not) > Linux, but the fact that many people use FreeBSD in *real world* > situations where performance under extreme load (>1000 users) is > paramount means that optimizing for these scenarios counts for far > more than chasing some micro-benchmark, and this is what has led John > to focus on specific types of performance over others. We wouldn't > have it any other way, and you tell me - which is better for us, > making thousands of simultaneous TCP/IP connections work properly or > shaving another microsecond off a meaningless latency benchmark? > > I'll give you an hour to answer that question, and you may use a > calculator. > > I prefer the abacus, but thanks. > > As for scalability. I have numbers (available upon request) where I > ran 100 streaming tcp connections between two (very low end) machines > in parallel, and the bandwidth and latency numbers scaled very nicely > with a variance that was all lost in the noise. Perhaps I should post > those results to usenet as well. > > Also, SparcLinux pushes ~17MB/s over _software_ RAID, thats close to > the theoretical maximum for 16-bit synchronous WIDE scsi. > > I'll be running numbers with 50 or so workstations pummeling a web > server over 3 or 4 100baseT lines and 4 10baseT lines, we'll see if > your arguments hold. And if they do, I have to thank you, because you > have shown me a way in which my system can be improved. > > And my systems are used in real world high stress situations as well > mind you. High load news servers run SparcLinux with zero problems, > and performance that blows SunOS/Solaris out of the arena (I can put > people in touch with the people who are running these systems if they > want verification). > > So my performance translates into real world, so I don't want to hear > your whining over this matter any more. > > Oh yes, and our main Linux mail server btw runs SparcLinux, over a 100 > lists, the most active ones (say 10 or so) have many thousands of > subscribers. It is multiuser, holds all my CVS sources, has a full > FTP archive, and runs an actively used web server. Oh and btw, this > is a dinky 40MHz SparcClassic (4k I and D caches, thats it) with 40MB > of ram and two SCSI disks. The load never goes over 4. > > ---------------------------------------------//// > Yow! 11.26 MB/s remote host TCP bandwidth & //// > 199 usec remote TCP latency over 100Mb/s //// > ethernet. Beat that! //// > -----------------------------------------////__________ o > David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ >< > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612030228.VAA01336>