Date: Thu, 5 Dec 1996 08:53:46 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: Larry McVoy <lm@neteng.engr.sgi.com> Cc: davem@jenolan.rutgers.edu, FreeBSD Hackers <hackers@freebsd.org>, torvalds@cs.helsinki.fi, lm@relay.engr.SGI.COM, iain@sbs.de, sparclinux@vger.rutgers.edu Subject: New benchmarks to design Message-ID: <Pine.SV4.3.95.961204161549.17926B-100000@parkplace.cet.co.jp> In-Reply-To: <199612032219.OAA22523@neteng.engr.sgi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I'd be interested in the following: fragStone: A benchmark that does file operations designed to fragment the hell out of a file system and then measures fragmentation and its effect on performance. ftp-uptimeStone: Accepts n connections and an optional t stop time and tries to maximize transfer volume. An interesting variation would be a entropic version that puts some jitter into the number of connections and the transfer bytes requested. This would require client and server software. This would probably be marginally more interesting than crashme but at least more realistic. worldStone: cd /usr/src; make world. This is important to people who build world a lot. In observing, results posted on this list there's a big difference when going from 486's to P5's and then to P6's. However, it does have to move memory around and read and write temp files, object files, and binaries, etc. I think Staelin paper said that performance will be limited by (1+c/i) where c is compute seconds and i is io seconds. If i is significant then improvements to c will have little effect. I think we're approaching this. Regards, Mike Hancock
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.95.961204161549.17926B-100000>