home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / next / hardware / 1633 < prev    next >
Encoding:
Text File  |  1992-09-08  |  1.7 KB  |  39 lines

  1. Newsgroups: comp.sys.next.hardware
  2. Path: sparky!uunet!spool.mu.edu!sdd.hp.com!think.com!paperboy.osf.org!david
  3. From: david@postman.gr.osf.org (David George)
  4. Subject: Re: Terrible SCSI Transfer
  5. Message-ID: <1992Sep8.081628.21869@osf.org>
  6. Sender: news@osf.org (USENET News System)
  7. Organization: OSF RI Grenoble
  8. References: <1992Sep1.010514.432@leland.Stanford.EDU> <Bu5vq5.3wF@iat.holonet.net>
  9. Distribution: usa
  10. Date: Tue, 8 Sep 1992 08:16:28 GMT
  11. Lines: 26
  12.  
  13. In article <Bu5vq5.3wF@iat.holonet.net>, bwilliam@iat.holonet.net (Bill Williams) writes:
  14.  
  15. I wrote :
  16. |> > These generate a lot of interrupts for each SCSI transaction 
  17. |> 
  18. |> I Believe that NO COMPUTER could efficiently use individual interrupts
  19. |> during the data tranfer phase of a SCSI transaction.
  20.  
  21. You have misunderstood.  On the 5390 (and other simple SCSI chips) an
  22. interrupt is generated for each SCSI phase change.  Processor intervention
  23. is required as a decision has to be made how to proceed depending on the
  24. state.  The 53700 (et al) effectively replace intelligent host adapators (such
  25. as Adaptec) and run simple software (scripts) which allows them to make these
  26. decisions on their own.  The 5390 typically generates 4 or 5 interrupts per
  27. SCSI operation, 53700 1 or 2 and the 53720 1.  Depending on the size of transfer, typically a block of 4 or 8K in a Unix filesystem (BBC), these interrupts can represent a significant overhead (as well as slowing down the system in general).
  28.  
  29. |> The NeXT is fine. Quite bellyaching about SCSI Transfer...
  30.  
  31. Any computer which uses the disk as backing storage can do to have faster 
  32. peripheral I/O, especially when it's as memory hungry as the NeXT.
  33.  
  34. |> you probably don't have either:
  35.  
  36. I probably do, but luckily I don't need to connect a NeXT to any of them.
  37.  
  38. David.
  39.