From owner-freebsd-current Fri Sep 17 16:15:41 1999 Delivered-To: freebsd-current@freebsd.org Received: from proxy2.ba.best.com (proxy2.ba.best.com [206.184.139.14]) by hub.freebsd.org (Postfix) with ESMTP id DFAF115AF5 for ; Fri, 17 Sep 1999 16:15:35 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com ([209.157.86.2]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id QAA04243 for ; Fri, 17 Sep 1999 16:12:33 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA53751; Fri, 17 Sep 1999 09:58:10 -0700 (PDT) (envelope-from dillon) Date: Fri, 17 Sep 1999 09:58:10 -0700 (PDT) From: Matthew Dillon Message-Id: <199909171658.JAA53751@apollo.backplane.com> To: current@FreeBSD.ORG, Brad Knowles Subject: 2xPIIIx450 results & NFS results (was More benchmarking stuff...) References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok, these are on duel P3 450 boxes running -CURRENT, with the NFS performance enhancements. Local disk is an 18G seacrate on an LVD/W scsi bus. UFS tests: on 1G duel P3-450 machine, 1x18G seagate SCSI-LW bus NFS tests: 1G duel P3-450 client, 512M duel P3-450 server, 100BaseTX, nfsd -n 4, nfsiod -n 4. Heh heh I accidently left my UFS/NFS-client box configured for 32M of memory and had gotten through the 1000/50000 tests before I realized it! So I might as well give you the results: 1000/50000 trans read write (client with 32M of ram) UFS+SOFT 264/s 841K/s 860K/s NFS 84/s 270K/s 276K/s 1000/50000 trans read write (client with 1G of ram) UFS+SOFT 1515/s 4.7M/s 4.8M/s NFS 107/s 344K/s 352K/s 20000/50000 trans read write (client with 1G of ram) UFS+SOFT 162/s 366K/s 663K/s NFS 50/s 125K/s 226K/s Both the client and server systems were 90%+ *IDLE* during all tests. The network was operating at 1-2 MBytes/sec through the 1000/50000 tests and from 0.6MB to 1.2MB/sec through the 20000/50000 test. This isn't surprising since the test is performing essentially random seek I/O's from a single process. The benchmark has a number of problems. The 'postmark' program isn't forking at all, so there is a serious bottleneck in the process itself, especially whenever a read is issued. It doesn't really give us an accurate representation of a multi-tasking load. Most NFS servers have a multitasking load so it isn't really a fair test. The benchmark shows pretty clearly the inefficiency of large UFS directories. Putting 20000 files in a single directory is not fun, and it seriously skews the test results considering what the benchmark is supposed to be testing. It seems pretty clear to me that this benchmark has been designed to show-off the netapp in the best possible light and its competitors in the worst possible light. Well, ok, that may be an overly-harsh assessment, but it is still true to some degree. The benchmark is seriously flawed. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message