From owner-freebsd-questions Wed Dec 22 18: 2:38 1999 Delivered-To: freebsd-questions@freebsd.org Received: from corinth.bossig.com (corinth.bossig.com [208.26.239.66]) by hub.freebsd.org (Postfix) with ESMTP id DBC2314C0E for ; Wed, 22 Dec 1999 18:02:34 -0800 (PST) (envelope-from kstewart@3-cities.com) Received: from 3-cities.com (kenn2053.bossig.com [208.26.242.53]) by corinth.bossig.com (Rockliffe SMTPRA 3.4.5) with ESMTP id ; Wed, 22 Dec 1999 18:09:33 -0800 Message-ID: <386182DA.660B55ED@3-cities.com> Date: Wed, 22 Dec 1999 18:03:06 -0800 From: Kent Stewart Organization: Columbia Basin Virtual Community Project X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathon McKitrick Cc: Dale Hagglund , freebsd-questions@freebsd.org Subject: Re: when is it safe to use the 0xa0ffa0ff disk flags? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jonathon McKitrick wrote: > > On Tue, 21 Dec 1999, Kent Stewart wrote: > >> On 21 Dec 1999, Dale Hagglund wrote: > >> >them during boot up, and then rebuilding the kernel. I went from > >> >about 4.1 MB/s for both reads and writes to 12.3 MB/s for reads and > >> >9.8 MB/s for writes. > > > >When I used iozone, I used "iozone -s 160m" to create 160MB files. You > >can set the file size to what ever you want as long as it is more than > >your memory. What iozone does show you how it handles various size > >reads and writes to get to the specified file size. I think it also > >throws some random I/O in as well. > > Well, i tried this on my laptop, and the best i got was about 4.7 > megs/sec. Can i expect to do any better on my Toshiba ? I don't > know my rpm rating, but i brought it to work so i can get bios > specs. It's running EIDE, AFAIK. It depends on the drive. I have included the response from "iozone -s 160m" on my 3 HD's for your information. random random KB reclen write rewrite read reread read write 163840 4 12441 4420 14734 14690 582 281 163840 4 4252 1469 7175 7278 451 184 163840 4 6122 1532 7669 7669 485 189 bkwd record stride read rewrite read fwrite frewrite fread freread 844 337237 976 14123 4489 14754 14782 859 338592 1186 4310 1961 7300 7300 857 335911 1328 7356 2090 7657 7661 The first drive is a 13.1GB running UDMA33 with UDMA cables. The other two drives are older vintage (Maxtor or WD - I would have to reboot to find out) running PIO Mode 4. The data was accrued while setiathome was running in the background on the 13.1GB drive. So, it represents the throughput of a busy system. The other two drives, if my memory is good are 2.5GB and 3.1GB drives. When I did a number of benchmarks on Control Data Corp.'s CDC-990's and Cray's XM/P's, the throughput of the system varied almost linearly with the speed of the HD's. The benchmarks we used represent a days work on the original slow CDC computer. It had the average number of jobs with the very close to the same aveage cpu and I/O times. The billing system logged all of the jobs for a year and then the daily averages were obtained from that. CDC (now out of the business) had a hard drive called a Hydra. It was a full height 8" HD that ran 9.6MB/s in 1988. It was also very expensive at $250,000 US. Cray striped them together to create what they called a DD40. It had 16 Hydras and had a total of 20GB. By striping 4 together, Cray would get 20MB/s when they were hung on the 100MB/s data channel. When our benchnmark was run on a system with the Hydras for main storage, the throughput basically doubled. The Cray XM/P had 2x the throughput of the CDC-990. The 990 was a dinosaur and represented the end of big iron. It filled the room where as the Cray looked like the what was left of the volcano in "Close Encounters of the Third Kind". I think the 8" FH HD's were all replaced by HH 5.25" HD's, which looked pretty puny mounted in the center of the Hydra's bay. The cooling requirements probably dropped 10KVA :). The effect of the Hydra on the benchmark was enormous. This the benchmark that I told you about writing behind was so important. The benchmark ran almost twice as fast when write behind caching was used. I think SOFTUPDATES produce an imporovement that helps for similar reasons. > > -jm -- Kent Stewart Richland, WA mailto:kstewart@3-cities.com http://www.3-cities.com/~kstewart/index.html FreeBSD News http://daily.daemonnews.org/ SETI(Search for Extraterrestrial Intelligence) @ HOME http://setiathome.ssl.berkeley.edu/ Hunting Archibald Stewart, b 1802 in Ballymena, Antrim Co., NIR http://www.3-cities.com/~kstewart/genealogy/archibald_stewart.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message