From owner-freebsd-hackers Wed Dec 4 15:55:17 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.8.3/8.7.3) id PAA23138 for hackers-outgoing; Wed, 4 Dec 1996 15:55:17 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA23131 for ; Wed, 4 Dec 1996 15:55:13 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.3/CET-v2.1) with SMTP id XAA22362; Wed, 4 Dec 1996 23:53:46 GMT Date: Thu, 5 Dec 1996 08:53:46 +0900 (JST) From: Michael Hancock Reply-To: Michael Hancock To: Larry McVoy cc: davem@jenolan.rutgers.edu, FreeBSD Hackers , torvalds@cs.helsinki.fi, lm@relay.engr.SGI.COM, iain@sbs.de, sparclinux@vger.rutgers.edu Subject: New benchmarks to design In-Reply-To: <199612032219.OAA22523@neteng.engr.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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