home *** CD-ROM | disk | FTP | other *** search
/ Monster Media 1994 #1 / monster.zip / monster / UTILS2 / PDB001.ZIP / PDB.DOC < prev    next >
Text File  |  1994-03-09  |  4KB  |  89 lines
  1. Portable Disk Benchmark (PDB) V0.01  03/09/94
  2.  
  3. PDB is written to be a simple Disk Benchmark test for testing disk AND
  4. cache performance across different platforms.  The code should compile
  5. with most C compilers.  I've enclosed precompiled versions for DOS,
  6. OS/2 16-bit and OS/2 32-bit.  The compiler I used are MSC 6.0a and IBM
  7. C Set++ 2.0.  Care has been taken to minimize compiler dependency so
  8. the results should be accurate enough for cross platform comparison.
  9. When compiling, try to use the most aggressive compiler optimization
  10. options.  This will help eliminate overhead in the compiled code.  Also
  11. note that the Large memory model should be used when you're using a 16-bit
  12. compiler.
  13.  
  14. PDB uses open/read/write calls.  These are unbuffered I/O calls and are
  15. available to all C compilers.  I've done some tests, and the program
  16. appears to have consistent result whether I compile it with 16-bit or
  17. 32-bit OS/2 compiler (MSC 6 vs IBM C Set++).  The only function I used
  18. which may not be available on some UNIX platforms is ftime (and the timeb
  19. struct).  The reason I use this is because it provides a millisecond
  20. timer accuracy, and I don't know of any other portable way of doing
  21. it (under the PC, this is only good to the hundredth of a sec accuracy).
  22. Since the calls are unbuffered, the disk cache must work hard to keep
  23. things fast.
  24.  
  25. The test is divided into 2 parts:
  26.  
  27. Part 1:
  28. Sequential write to create the file
  29. Random read
  30. Random write with the same data
  31.  
  32. Part 2:
  33. Sequential read of the entire file
  34. Random read
  35. Random write of changed data
  36.  
  37. There should be a disk cache flush between part 1 and 2, but I haven't
  38. found a way to do this, and in most case, this is not under the program's
  39. control.  Because of this, the sequential read time will be much higher
  40. for large file size due to cache flushing.
  41.  
  42. The random read/write is restricted to only 1MB of data regardless of
  43. file size or block size.  The random seed is set to a known state before
  44. each random read/write sequence, and the seed is different for read and
  45. write.  Also, I have coded the ANSI standard random number generator in
  46. PDB instead of using the C library version to eliminate further compiler
  47. dependency.
  48.  
  49. PDB has 2 arguments: file size in MB, and number of blocks per call in
  50. 512-byte increment.  Specifying PDB 1 4 means 1MB file size, and 2048
  51. bytes block size per call.  There is a limit of maximum block size of
  52. 65024 bytes.  This is a limitation of 16-bit systems, such as DOS, and OS/2
  53. 1.x.  I do not plan to remove this, as many hardware devices may have
  54. 64K DMA transfer limit, so the driver may split a transfer into multiple
  55. 64K chunks.
  56.  
  57. Here is the help screen of PDB:
  58.  
  59. Portable Disk Benchmark  V0.01  03/08/94
  60.  
  61. usage: PDB [File size] [Blocks]
  62.   File size - File size in MB.  Allowable range: 1 to 32MB.
  63.   Blocks    - Number of blocks to read/write per I/O call.
  64.               Each block is 512 bytes.  Allowable range: 1 to 127.
  65.  
  66. example: pdb 2 4
  67.  
  68.  
  69. The benchmark test should be run from the root directory of the drive
  70. under test.  This may not be possible under UNIX systems depending on
  71. your account access level.
  72.  
  73. Since this is preliminary code, I'm not providing any test results for
  74. comparison, so you will have to play with you own.  If you have any
  75. suggestion, bug report, etc. just put a message on Fidonet OS2 conference,
  76. or send me email:
  77.  
  78. CompuServe ID: 70730,401
  79. Internet:      70730.401@compuserve.com
  80.  
  81. Good luck in benchmarking!
  82. Albert Shan
  83.  
  84. =============================================================================
  85. Work in progress/wish list:
  86. - Part 3 of the benchmark will be testing massive amount of files.  I'm
  87.   planning to use 512 files of 32K each for a total of 16MB.  Will test
  88.   files creation time, read/write time, and deletion time.
  89.