de5@ornl.gov (Dave Sill) (03/26/91)
This was recently posted to comp.sources.misc. In article <1991Mar22.212846.16835@sparky.IMD.Sterling.COM>, norcott@databs.enet.dec.com (Bill Norcott) writes: >Submitted-by: Bill Norcott <norcott@databs.enet.dec.com> >Posting-number: Volume 17, Issue 65 >Archive-name: iozone/part01 > >Attached is a benchmark called IOzone which I have written. It was inspired >by Alvin Park's IOstone benchmark (which tests random access I/O). IOzone >tests sequential file I/O using the C language. It writes, then reads, a >sequential file of fixed length records, and measures the read & write >rates in bytes per second. The default is to create a 1 megabyte file >consisting of 2048, 512-byte records -- however, these parameters can be >changed from the command line. On UNIX systems, the results will be influenced >by the effect of the buffer cache -- however, we can largely negate the >effect of caching by using a file size greater than twice the size of the >cache. This will allow a fairer comparison between various disk drives >attached to the system. IOzone IS NOT a direct test of disk performance. Its >results are a combination of disk speed, CPU speed, amount of cache, and the >efficiency of the C compiler & runtime library. This is also true of IOstone, >in fact I intend this program as a companion piece to IOstone. > >This benchmark is portable and has been tested on these operating systems: > > VAX/VMS V5.4 > Ultrix V4.1 > MS-DOS V3.1 > OSF/1 > >IOZONE.C is free and in the public domain. I would appreciate your >comment and test results. > >Bill Norcott (Bill.Norcott.nuo.mts.dec.com) > >[source code deleted] -- Dave Sill (de5@ornl.gov) It will be a great day when our schools have Martin Marietta Energy Systems all the money they need and the Air Force Workstation Support has to hold a bake sale to buy a new bomber.
john@jwt.UUCP (John Temples) (03/26/91)
In article <1991Mar25.163527.5052@cs.utk.edu> Dave Sill <de5@ornl.gov> 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)