home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / sgi / 18658 < prev    next >
Encoding:
Text File  |  1993-01-11  |  2.3 KB  |  51 lines
  1. Newsgroups: comp.sys.sgi
  2. Path: sparky!uunet!mcsun!chsun!bernina!hoesel
  3. From: hoesel@igc.ethz.ch (Frans van Hoesel)
  4. Subject: Re: SCSI floppy disk on INDIGO: Why is it so slooow?
  5. Message-ID: <1993Jan11.112716.12929@bernina.ethz.ch>
  6. Sender: news@bernina.ethz.ch (USENET News System)
  7. Organization: University of Groningen, the Netherlands
  8. References: <unepq0o@zuni.esd.sgi.com> <1993Jan11.092139.28106@sol.ctr.columbia.edu>
  9. Date: Mon, 11 Jan 1993 11:27:16 GMT
  10. Lines: 39
  11.  
  12. >Dave Olson (olson@anchor.esd.sgi.com) wrote:
  13. >: 
  14. >: No!  There *are* s/w buffers on the host.  That doesn't help.  You
  15. >: have an embedded drive controller that reads/writes a sector from the
  16. >: drive to/from the controller ram, then the controller turns around
  17. >: and gives the data to the host (for a write), or is ready to accept
  18. >: another command (for a read).  All of that takes time, and by the time
  19. >: the next sector is passed to the drive, the drive has already passed
  20. >: the next sector, so you lose a rev.  This is the case whether you
  21. >: ask for one sector at a time or 1000.  Basicly the embedded controller
  22. >: was designed to be very cheap (as were the 2-3 others available at
  23. >: the time, including NCR's), which translates to slow.
  24. >:
  25.  
  26. If that is the only reason, then msdosd can be expected to be as fst as
  27. mtools, which it is defenitly not!!
  28.  
  29. Because mssing the next sector would be a very important time factor,
  30. maybe it would be nice to have a special format on the floppy that
  31. does not have sequential sector numbers. This would only help for 
  32. newly formatted floppies, not for existing ones.
  33.  
  34. On the other hand... knowing the effect of missing a sector *and* having
  35. softwarebuffers on the host a simple software trick could speed it up.
  36. Imagen a write of a shortfile on sector numbers 1, 2, 3, 4, 5, 6, 7.
  37. These could all be present in the software buffer, but we (in fact
  38. your engineer working on it) could decide to write in the order
  39. 1, 3, 5, 7, 2, 4, 6 which would give a speed up by 350% (for this very
  40. short write, longer writes will speed up even more)
  41. This tricj would work for existing floppies too.
  42.  
  43. --frans
  44.  
  45.  
  46.  
  47. -- 
  48. --    ==============================================================    --
  49. ----  ===  frans van hoesel             hoesel@igc.ethz.ch       ===  ----
  50. --    ==============================================================    --
  51.