home *** CD-ROM | disk | FTP | other *** search
/ Garbo / Garbo.cdr / mac / util / accel.sit / Accelerator.doc.bin / Accelerator.doc
Encoding:
Text File  |  1989-03-15  |  6.5 KB  |  121 lines  |  [TEXT/MPS ]
  1. WHAT SCSI-ACCELERATOR IS ALL ABOUT.
  2.  
  3. The accelerator works only on a MacPlus! It enhances the throughput of I/O
  4. operations for so called blind read and write operations. Nothing else is
  5. affected.
  6.  
  7. The reason that the performance of these operations can be enhanced is
  8. that Apple's code to do these operations is (and must be) suited to handle
  9. a variety of disk types. Some of these are slower than others. In the following
  10. discussion we will talk about read operations only, but the discussion applies
  11. just as well to write operations.
  12. When transfering data to or from a SCSI device, there is no support for hardware
  13. handshake on the MacPlus (there is some on the other Macintoshes). Because of this,
  14. the only really safe way to do the I/O is to poll the SCSI chip for the arrival of
  15. a new byte each time you need one. Of course this is slow. Therefore Apple
  16. introduced the "blind" operations. For blind operations, the system only waits for
  17. the arrival of the first byte, the rest of them are read in a small loop which looks
  18. like this:
  19.     @1    move.b    (a1),(a2)+
  20.         dbra    d6,@1
  21.  
  22. This means that after every transfer of a single byte, the Macintosh waits at least
  23. the time to execute the DBRA (about 10 cycles) before fetching the next byte. This
  24. is long enough for even the slowest hard disk that Apple anticipated to have the
  25. next byte ready. In fact, most hard disk can deal with a lot less! Reduction of
  26. this "dead" time can be achieved by unfolding the loop, i.e. reducing the loop
  27. trip count and putting more than a single move.b instruction in the loop body.
  28. Of course, if we put two moves right next to each other, we get the fastest
  29. transfer that is possible (knowing that we do not have a DMA controller). This
  30. might be too fast for some hard disks, so it may well be that we have to put one
  31. or more NOP instructions between each two move.b instructions. The execution time
  32. of a NOP is only 4 cycles however, much less than for the DBRA and thus, throughput
  33. can be increased even if we need 2 NOPs per move.b. By increasing the number of
  34. move.b instructions in the loop body, we further decrease the looping overhead,
  35. leading to increased performance, but of course, also to more use of memory for
  36. the code.
  37. Since the loop illustrated is 6 code bytes long, there is just enough place to
  38. replace the loop with a JSR instruction to a patched version of the loop that applies
  39. these techniques. This is exactly what the SCSI-Accelerator does. The reason that
  40. this does not improve performance on the Mac SE or II/IIx is that those machines
  41. support a sort of pseudo DMA transfer mode that already takes care of getting in
  42. the bytes as soon as they arrive. For this reason, the accelerator init refuses
  43. to install itself on anything other than a Mac Plus.
  44.  
  45. HOW TO USE IT.
  46.  
  47. As said before, if you do not operate a Mac Plus, forget it, it will not install!
  48. If you are using a MacPlus, the thing to do is to find out what kind of unfolded
  49. loop will still work for your configuration. This depends mainly on two things:
  50. disk type(s) and processor (in case you operate an accelerator board). For this
  51. reason, several variants of the init code have been provided. They are all named
  52. SCSI-Accel-r<x>w<y>s<z>. Here the <x>, <y> and <z> are single digits meaning:
  53. <x>        The number of NOPs inserted after each move.b in the loop body for reading.
  54. <y>        The number of NOPs inserted after each move.b in the loop body for writing.
  55. <z>        The number of move.b instructions in the loop body is equal to 2^<z>
  56. This means that in general you should use the init with the lowest <x> and <y>
  57. that still works with your configuration. Once you know which one to use, the next
  58. thing to do is to decide how you want to trade of memory and speed by choosing
  59. the <z> that you want to use. In general z=5 works quite well.
  60. You find out which <x> and <y> version to use by putting one of the INITs in
  61. your system folder and rebooting. If the boot works it is quite likely that that
  62. version works for you. Test this by duplicating a file with the finder.
  63. You should start to test this with a variant with <x> and <y> large. If it works
  64. you can progressively try out lower numbers. Don't worry, during boot the disk
  65. is only read and even if the Mac crashed (which is the usual symptom of a <x>,<y>
  66. which is too low), no real harm will be done.
  67.  
  68. The code in this patch should work with all disks (providing you choose the
  69. right <x> and <y>. Disks with block sizes that are a multiple of 2^<z> work
  70. fastest, but any other block size will be handled correctly (for those of you
  71. that have disks that operate with tags). The original accelerator worked only
  72. with 512 bytes/block disks.
  73.  
  74. HOW GOOD DOES IT WORK?
  75.  
  76. Since the SCSI manager read and write blind operations are patched, you will not
  77. get improved performance if your disk's driver does not use the SCSI manager. In
  78. that case it is quite likely that the driver will already do the same kind of
  79. optimalization as suggested here, so there won't be much to gain here.
  80. Supposing your driver *does* use the SCSI manager, performance will improve,
  81. depending on the type of disk you have. An example:
  82. Using a HD SC80 (Quantum Q280) disk with my own custom driver that *does* use
  83. the SCSI manager we get the following DiskTimer II results:
  84.  
  85. Variant        Reads    Writes    Seeks
  86. none        106        105        18
  87. r0w0s5        63        67        18
  88. r1w1s5        83        82        18
  89.  
  90. The SC 80 is a disk which is formatted with a 1:1 interleave. Its controller
  91. caches a complete disk track though, hence the almost twofold improvement.
  92. For a Rodime RO632 (Some Apple HD 20's) and the same driver we get:
  93.  
  94. Variant        Reads    Writes    Seeks
  95. none        160        161        52
  96. r0w0s5        109        107        52
  97. r1w1s5        110        108        52
  98.  
  99. This disk is quite a bit slower, but still there is improvement. What I have not
  100. yet tested is what happens if, in addition to using r0w0s5, I also reformat the
  101. disk with a lower interleave factor. It might very well be that because of
  102. the improved data transfer rate, the Mac Plus can keep up with an interleave that
  103. is one lower. In that case, performance would improve even more.
  104.  
  105. Apple's drivers also use the SCSI manager, so the INIT should at least work with
  106. that software. It is known that some Rodime drivers bypass the SCSI manager. You
  107. will have to try and measure to see wether or not the INIT works for you. In general:
  108. just try and see. Included in this package is disktimer II so that you can check
  109. the results yourself.
  110.  
  111. Have fun, Dolf
  112.  
  113. Dolf Starreveld
  114. Department of Mathematics and COmputer Science
  115. University of Amsterdam
  116. Kruislaan 409
  117. 1098 SJ  Amsterdam
  118. The Netherlands
  119. Phone: +31 20 592 5022
  120. E-mail: dolf@uva.UUCP (...!uunet!mcvax!hp4nl!uva!dolf for oldies)
  121.