Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 2 Dec 1996 21:17:34 -0500
From:      "David S. Miller" <davem@jenolan.rutgers.edu>
To:        jkh@time.cdrom.com
Cc:        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:  <199612030217.VAA18178@jenolan.caipgeneral>
In-Reply-To: <7184.849578160@time.cdrom.com> (jkh@time.cdrom.com)

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?199612030217.VAA18178>