Date: Thu, 17 Feb 2000 21:52:51 +0100 From: Brad Knowles <blk@skynet.be> To: Tom <tom@uniserve.com> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: Initial performance testing w/ postmark & softupdates... Message-ID: <v0422082db4d20b7b0d63@[195.238.1.121]> In-Reply-To: <Pine.BSF.4.05.10002171205530.1712-100000@shell.uniserve.ca> References: <Pine.BSF.4.05.10002171205530.1712-100000@shell.uniserve.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
At 12:27 PM -0800 2000/2/17, Tom wrote: > Not really. You could just use async updates instead of softupdates. > Or an OS that uses async updates. Write caching metadata is always faster > than re-ordering it intelligently. We're getting several steps away from the primary reason I originally decided to run these benchmarks -- to get an idea of what kind of performance increase you might be able to expect if you got rid of synchronous meta-data operations altogether. Using async writes is not something I will be testing (or am interested in testing) except on OSes that do it by default. In fact, so far as I know, Linux is the only OS that does this by default, and I can't think of too many OSes that are capable of doing it at all. > Perhaps. Or it was the rather new SmartRAID V driver. Or it was the > card (there are many different SmartRAID V) models. Or the array was > optimized for sequentional io, instead of random io, not that RAID5 is > ever optimal for random io to begin with. Perhaps. That machine still isn't being used for much, so I could fire off another test that used the internal drive, and see what that gets me. I'd be willing to bet that softupdates still beats Linux ext2fs+async. > The rates reported by postmark are aggregates. I've noticed that > actually throughput over the tests to vary by a 100% or more during the > tests. They may vary by 100%, but as an average, these numbers should not be too high nor too low, and the peaks shouldn't be all that much above nor should the valleys be all that much below. However, let's assume that the average is low, and that we should increase it by 100% -- double it, in other words. Well, if we double the numbers they got, 800KBps read and 1.2MBps write still isn't anywhere close to 12.5MBps available. Unless you're telling me that the inherent problem with NFS is that it can't sustain anything more than 1/20th of the available bandwidth due to protocol and other network issues, and if that's the case then things are *far* worse for NetApp and the other NFS vendors than even I think (used to think?). If that's the case, then as far as I'm concerned we can stop the conversation right here, since I know damn good and well that I can get ~18MBps on a four-way vinum striped volume with 10kRPM disks on a AIC-7890 controller, because I did it. And even this isn't enough for the kinds of applications I have in mind. > Besides, latency of 100BaseT is rather poor too. Latency, now that's something I won't try to argue, especially when it comes to really chatty protocols like NFS. However, I see this as just one more strike against NetApp (and NFS in general), and not something to be considered in their favour. > Not just their (NetApp) performance. Disks and controllers in general > are a lot faster than they were two years ago. As I recall, the Adaptec 2940U2W and AIC-7890 controllers are pretty old themselves (the 3950U2 came after it, and now we have the Ultra3 controllers). In addition, this disk isn't coming anywhere close to what this controller is capable of -- the Quantum Atlas IV drive is several years old, old enough that I almost got one years ago for my PCI PowerMac 7200/90, which was the second generation of PowerMacintosh computers (we're now in the fifth generation). Even then, it wasn't the fastest around -- we have some ancient 4GB Seagate "Cheetah" drives that are in Sun Ultra 1 and 2 servers that we are pulling out of production because the machines are just too old and creaky (Solaris 2.5.1? Give me a break...). The machine I'm using for the tests is nowhere near top-of-the-line, either. Again, it might have been top-of-the-line two years ago, but then NetApp was building "screamers" on Alpha EV4 hardware, and with that kind of power, it should run rings around my older hardware. Let's not talk about old unless we consider that I'm using some pretty old stuff myself. > Please forget all those > old results. My point here is not to defend NetApp, but to say that old > results are meaningless. I could have put together a system like this two years ago, and then the results would have been immediately comparable. If they would have been immediately comparable then, I submit that they are immediately comparable now -- with the exception of the software improvements that have occurred in the last two years. > Big deal. You managed to exceed some results > published over two years ago. I bet my TV can exceed the postmark scores > you published today, two years from now. Perhaps. But take a top-of-the-line TV that exists today, and try to exceed the scores I published. Heck, wait two years and take a TV that was top-of-the-line two years ago, and try to exceed the results I published. I dare you. ;-) -- These are my opinions and should not be taken as official Skynet policy _________________________________________________________________________ |o| Brad Knowles, <blk@skynet.be> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v0422082db4d20b7b0d63>