From owner-freebsd-stable Thu Feb 17 11:35:34 2000 Delivered-To: freebsd-stable@freebsd.org Received: from trinity.skynet.be (trinity.skynet.be [195.238.2.38]) by hub.freebsd.org (Postfix) with ESMTP id 32C5137B7AF for ; Thu, 17 Feb 2000 11:35:25 -0800 (PST) (envelope-from blk@skynet.be) Received: from [195.238.1.121] (brad.techos.skynet.be [195.238.1.121]) by trinity.skynet.be (Postfix) with ESMTP id EAA551232C; Thu, 17 Feb 2000 20:35:05 +0100 (MET) Mime-Version: 1.0 X-Sender: blk@pop.skynet.be Message-Id: In-Reply-To: References: Date: Thu, 17 Feb 2000 20:33:28 +0100 To: Tom From: Brad Knowles Subject: Re: Initial performance testing w/ postmark & softupdates... Cc: freebsd-stable@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 10:37 AM -0800 2000/2/17, Tom wrote: > Uhhh... the paper says that an Ultra 1/170 running Solaris 2.5. That is > an old system. I've run tmpfs tests with postmark on Ultra 2 and Ultra 5 systems with faster CPUs and newer versions of the OS, and they didn't run anywhere *NEAR* that fast (I've got an Ultra 5 I'm testing right now). Heck, one person told me he had an older laptop running Linux with ReiserFS and he was getting better throughput going to disk than Sun did with tmpfs! Again, I have to seriously wonder what they were really testing on. > I'm not sure how comparing benchmark results from 1998 with current > hardware is relevant at all. Postmark is performance is influenced more > by the disk & controller used, rather than the OS. In fact, CPU is not > much of any issue either. In fact, SMP is probably slowing the results > down! My results clearly show that there is a huge filesystem effect, and anything that could prevent operations from getting put into the queue to be flushed to disk would have a similar effect. OS/filesystem implementation efficiency could not *help* but have a huge impact on this. > You also compare results versus a NetApp F630. I hope you realize that > these are VERY old units. Yes, I know that they are the previous generation devices, I've been told as much by folks from NetApp, when I was previously posting results from testing with postmark. I also know just how incredibly bloody expensive these things are, and how I did quite a good job of coming pretty close to their level of performance on a pretty low-end FreeBSD server with a *SINGLE* low-speed Quantum Atlas IV, and all I had to do was turn on softupdates. I also notice that softupdates on a slow disk beat out Linux/ext2fs+async on a single CPU system that was otherwise similarly configured, except for the DPT SmartRAID V controller that the Linux server had to it's advantage, and the 5-way RAID-5 volume that it was writing to. > They came with Wide SCSI disks (not Ultra, not > Ultra2) for instance. It doesn't mention, but I expect the test was only > done over 100BaseT. In that case, the 100BaseT network would have been > the limiting factor. Yes, it was 100BaseT, but I don't see anything in any of these tests that should have come anywhere close to pushing the limits of 100BaseT for speed -- ~400KBps read and ~600KBps write, with ~170 TPS shouldn't come anywhere close to network bottlenecks of 12.5MBps capacity. > Also, the existing base model NetApp, the F720 has > over twice the performance of the F630! And I've been told that NetApp > doesn't really sell anything but the high-end F760, which has over twice > the performance of the F720. The entire F700 is already pretty old, and > is scheduled to be replaced by a new series this year. "Twice the performance." I'm sorry, that term is just a little too vague for me. Can you quantify these numbers in terms of transactions per second, data read per second, and data written per second? > So please, postmark is a useful tool. See my previous e-mails about > postmark+softupdates. But comparing results when a two year old document > is meaningless. Especially with disk/controller performance doubling > every year or so. Their performance may theoretically be doubling every year or so, but the machine I tested with is not anywhere close to what I would consider to be a high-end server, and it definitely did not have the advantage of a vinum nine-way striped filesystem on 10kRPM disks or anything like that, and yet I still came pretty close to their level of performance. Let me get rawio working on this machine, and we can compare the low-level hardware performance of this disk device to the previous four-way 10kRPM vinum striped device I used for my previous benchmarking, and then we can extrapolate as to what might happen on that system if we enabled softupdates on it. I'd be willing to bet that it would beat the crap out of the F630, and if I was allowed to do that on a nine-way striped 10kRPM volume, I could do some pretty good damage against the current crop of NFS servers. Take a look at what Joe Greco is talking about doing for his next-generation USENET news spool server (see message-id <38ac286b$0$86644@news.execpc.com> in news.software.nntp), and tell me that this wouldn't beat the crap out of NetApp as an NFS server. -- These are my opinions and should not be taken as official Skynet policy _________________________________________________________________________ |o| Brad Knowles, Belgacom Skynet NV/SA |o| |o| Systems Architect, Mail/News/FTP/Proxy Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.13.11/726.93.11 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message