Date: Mon, 02 Dec 1996 22:18:47 -0800 From: Jason Thorpe <thorpej@nas.nasa.gov> To: "David S. Miller" <davem@jenolan.rutgers.edu> 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: <199612030618.WAA06227@lestat.nas.nasa.gov>
next in thread | raw e-mail | index | archive | help
On Mon, 2 Dec 1996 21:17:34 -0500 "David S. Miller" <davem@jenolan.rutgers.edu> wrote: > pinhead. If you think it does not, why does the government spec > lmbench numbers for all purchases these days? What concrete numbers We spec NASPAR benchmarks (home-grown, specifically to measure performance of a system under our typical workload). I sort of hold the opinion that "general purpose" benchmarks like lmbench are fun to play with, but I certainly wouldn't claim one OS is better than another based on "general purpose" benchmark numbers. > 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. Load average measures the average number of runnable processes. If everyone's waiting for I/O to complete, well, they're not runnable... Actually, specifically, load average is: load avg = nrunnable + number of processes sleeping in \ uninterruptable sleeps for < 1 second. So, your load average of 4 could be "lots of processes not runnable because they're blocking on I/O" plus "a few process in uninterruptable disk wait" :-) So, maybe you load average is yet another example of a meaningless Linux number :-) My point is that claiming a load average number doesn't really tell us anything. Why don't you tell us exactly what's going on in the system. Then we might be impressed (depending on what you tell us :-). As it stands, your bragging and number flashing is, well, just annoying. IMO, for the kind of work I do (kernel development), a much better `benchmark' is to run a profiling kernel and then do a "make build" (which is what NetBSD uses to build releases). With the profile data, you can find places where you actually spend a significant amount of time, and improve them. Sometimes the profiling results are surprising. I see Larry's on the Cc: now (amazing how these explode so we can all prove our manlyness to an audience :-)... I saw him at SC'96, and tried to bump into him a couple of times... never got a chance to hook up with him... I was rather looking forward to arguing about benchmarks :-) Jason R. Thorpe thorpej@nas.nasa.gov NASA Ames Research Center Home: 408.866.1912 NAS: M/S 258-6 Work: 415.604.0935 Moffett Field, CA 94035 Pager: 415.428.6939
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612030618.WAA06227>