Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!masscomp!peora!tarpit!bilver!jwt!john From: john@jwt.UUCP (John Temples) Newsgroups: comp.benchmarks Subject: Re: v17i065: iozone - sequential file I/O benchmark fo UNIX, VMS & DOS, Part01/01 Message-ID: <1991Mar26.150801.9595@jwt.UUCP> Date: 26 Mar 91 15:08:01 GMT References: <1991Mar22.212846.16835@sparky.IMD.Sterling.COM> <1991Mar25.163527.5052@cs.utk.edu> Organization: Private System -- Orlando, FL Lines: 38 In article <1991Mar25.163527.5052@cs.utk.edu> Dave Sill writes: >This was recently posted to comp.sources.misc. Here are some figures I got: 386/33, Maxtor 15 MHz ESDI, DTC controller, ESIX SVR3.2-D, FFS, 1 MB cache iozone 6: 629145 bytes/second for writing the file 571950 bytes/second for reading the file 386/25, Micropolis 5 MHz ST-506 MFM, 1:1 interleave, ISC 2.0.2, 250K cache iozone 3: 241979 bytes/second for writing the file 285975 bytes/second for reading the file 386/20, Micropolis 5 MHz ST-506 MFM, 2:1 interleave, ISC 2.0.2, 1 MB cache iozone 6: 157286 bytes/second for writing the file 161319 bytes/second for reading the file 386/20, Conner 12 MHz IDE, native controller, ISC 2.0.2, 800K cache iozone 2: 77672 bytes/second for writing the file 87381 bytes/second for reading the file I did notice that the write() statement isn't checked for errors, so you have to watch out for ulimits under System V. I don't know why the IDE drive did so poorly. These drives are becoming more and more popular, but I'm not sure if their performance warrants it. Unfortunately, one of the most popular ways of testing the transfer rate on PC drives is Coretest, which reads the same 64K (or less) block of data continuously. The IDE drives generally have an on board cache of 32-64K bytes, which lets them show impressive performance on this particular "benchmark." They seem to fall flat in "real world" applications. -- John W. Temples -- john@jwt.UUCP (uunet!jwt!john)