home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / biz / sco / general / 4796 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  5.0 KB
  1. Path: sparky!uunet!noc.near.net!hri.com!spool.mu.edu!sol.ctr.columbia.edu!eff!xenitec!news
  2. From: belal@sco.COM (Bela Lubkin)
  3. Newsgroups: biz.sco.general
  4. Subject: Re: Performance issues revisited
  5. Message-ID: <9212221234.aa29754@scoke.sco.COM>
  6. Date: 22 Dec 92 20:34:32 GMT
  7. Sender: news@xenitec.on.ca (xenitec.on.ca News Administrator)
  8. Organization: [resent by] The SCOGEN gateway and Propagation Society
  9. Lines: 81
  10. Resent-From: mmdf@xenitec.on.ca
  11. Submit-To: scogen@xenitec.on.ca
  12. Cc: uunet!consult!bob@sco.COM
  13. Precedence: bulk
  14.  
  15. Bob Willey wrote:
  16.  
  17. > >        time dd if=/dev/rhd0a of=/dev/null bs=2048 count=8192
  18.  
  19. >        OLD MACHINE                             NEW MACHINE
  20. > 386/33 w/8mb memory 64kcache           486/DX266 w/16mb memory 256k cache
  21. > Ultrastor 12F ESDI controller          Adaptec 1542 SCSI controller
  22. > Maxtor 338mb drive (~ 16ms)            HP 667 SCSI-2 drive (~13ms)
  23. > CMS Enhancement 250mb tape             Archive ST-525 mb tape (SCSI)
  24. >                        Results of above command:
  25. > Real 25.3  user 0.3  sys 5.2           real 1:01.6  user 0.3  sys 3.6
  26. >                  Tape backup results when using CTAR
  27. > Typical:  2.3mb/min                    Typical:  5.8mb/min
  28. > 
  29. > While the backup time is noticeable faster, the dd command for disk transfer
  30. > appears noticeable SLOWER on the new machine???  Is there anything obvious
  31. > in the above configuration that can cause problems?  Is there anything
  32. > special that needs to be done to the Adaptec controller to get better
  33. > performance??  This is very uncomforting since we are upgrading to obtain
  34. > more throughput.
  35.  
  36. Even the slower hard disk transferred 16MB/min. in the `dd` test, so
  37. obviously even a fast tape drive is a bottleneck.  Your backup speed
  38. difference is due to the tape drives used, 'nuff sed.  
  39.  
  40. The SCSI disk may have an internal cache which needs special SCSI
  41. commands to enable (get Roy Neece's SCSICNTL.EXE to mess with that, but
  42. be Vewwy Caewful -- write down *everything* about the drive's current
  43. configuration before setting it to a nonfunctional set of parameters!
  44. I've thoroughly toasted myself once with SCSICNTL)  Many SCSI drives
  45. have such caches, and for reasons I've never been able to fathom,
  46. they're usually disabled from the factory.
  47.  
  48. Relative seek times aren't likely to make a noticable difference.  Most
  49. disks spin at 3600rpm (or the same order of magnitude), which is 16.67ms
  50. per revolution.  Obviously you can't get the data off a track faster
  51. than one revolution.  Also, you're reading consecutive tracks, so you're
  52. getting the "track-to-track" (fastest), not the average seek time.  The
  53. drives might be 4ms vs. 3ms in track-to-track, making only a 1ms
  54. difference out of ~20ms per track, optimum.  That's if the drive doesn't
  55. lose revolutions.  Much more important is the number of physical
  56. 512-byte sectors per track on the drive.  Ignore the translated
  57. parameters, get out the drive manuals and look up physical sectors/track
  58. when formatted 512 bytes/sector; and also rotational speed.  From these
  59. you can work out the fastest possible transfer rate off the disk.
  60.  
  61. Transfer rates are extremely sensitive to block sizes, and sometimes to
  62. raw device vs. block device, and (this one is weird) your results may be
  63. VERY different when accessing the whole-partition device (/dev/hd0a) vs.
  64. a division device (/dev/root), which is how you most likely normally
  65. access your data.  So, try the following variations on both machines.
  66. Make a table of the results.  Post it.
  67.  
  68.   time dd if=/dev/rhd0a of=/dev/null bs=2k count=8192 (original flavor)
  69.   time dd if=/dev/hd0a of=/dev/null bs=2k count=8192  (blk device)
  70.   time dd if=/dev/rhd0a of=/dev/null bs=256k count=64 (raw device, large blk)
  71.   time dd if=/dev/hd0a of=/dev/null bs=256k count=64  (blk device, large blk)
  72.  
  73.   time dd if=/dev/rroot of=/dev/null bs=2k count=8192 (divvy device, raw)
  74.   time dd if=/dev/root of=/dev/null bs=2k count=8192  ( ", blk)
  75.   time dd if=/dev/rroot of=/dev/null bs=256k count=64 ( ", raw, large blk)
  76.   time dd if=/dev/root of=/dev/null bs=256k count=64  ( ", blk, large blk)
  77.  
  78.   time dd if=/dev/rhd00 of=/dev/null bs=2k count=8192 (whole-disk, raw)
  79.   time dd if=/dev/hd00 of=/dev/null bs=2k count=8192  ( ", blk)
  80.   time dd if=/dev/rhd00 of=/dev/null bs=256k count=64 ( ", raw, large blk)
  81.   time dd if=/dev/hd00 of=/dev/null bs=256k count=64  ( ", blk, large blk)
  82.  
  83. That's 12 tests * 2 machines, have fun!  ;-}  Note that the third set
  84. will FAIL on the ESDI drive if there are any bad sectors in the first
  85. 16MB of the drive.  To avoid this you could eyeball your badtrk table,
  86. try to figure out where a 16MB swath of good disk exists, then use
  87. "iseek=#", where #=how many 2k or 256k blocks to skip to get to the good
  88. area; or you could reduce the total size and interpolate results, but be
  89. absolutely sure that the total transfer size is at least one block size
  90. larger than your buffer cache.  DO NOT USE "skip=#"!!  That has a
  91. totally different effect: "iseek=" lseek's in the file; "skip=" *reads*
  92. that much data before beginning the transfer, which will 1) still trip
  93. on the bad sectors, and 2) totally hose your timings.
  94.  
  95. >Bela<
  96.