home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / unix / ultrix / 9506 < prev    next >
Encoding:
Text File  |  1993-01-27  |  3.0 KB  |  67 lines
  1. Newsgroups: comp.unix.ultrix
  2. Path: sparky!uunet!europa.eng.gtefsd.com!emory!swrinde!elroy.jpl.nasa.gov!usc!howland.reston.ans.net!spool.mu.edu!uwm.edu!grc!joe
  3. From: joe@grc.genroco.com (Joe Nordman)
  4. Subject: Re: Recommendations for high disk throughput
  5. Message-ID: <1993Jan27.205507.13234@grc.genroco.com>
  6. Sender: joe@genroco.com
  7. Organization: GENROCO, Inc.
  8. References: <THOMSON.93Jan22073952@zarda.macc.wisc.edu> <1993Jan23.002725.7620@nntpd2.cxo.dec.com> <C1BFFz.EEr@news.iastate.edu>
  9. Date: Wed, 27 Jan 1993 20:55:07 GMT
  10. Lines: 55
  11.  
  12. In article <C1BFFz.EEr@news.iastate.edu> john@iastate.edu (John Hascall) writes:
  13. >alan@nabeth.enet.dec.com (Alan Rollow) writes:
  14. >}thomson@zarda.macc.wisc.edu (Don Thomson) writes:
  15. >}>We are looking at upgrading our campus Usenet News server from a hopelessly
  16. >}>overburdened DECstation 3100 to a DECstation 5000/240.  The biggest bottleneck
  17. >}>for handling news has been disk access time, so we're looking at options that
  18. >}>will allow us the highest disk throughput possible to a disk with a capacity
  19. >}>of at least a gigabyte.  I'm looking for advice on an optimal configuration
  20. >}>for these needs, including:
  21. > ...
  22. >}Most of the I/O was 8 KB, but the next biggest chunk was 1 KB.
  23. >
  24. >}An IPI subsystem will probably help, but it seems a bit overkill...
  25. >
  26. >Perhaps not.  A fairly recent Usenix Paper, "Why SCSI is better than IPI
  27. >for NFS" (or something like that), held that IPI was really only a win
  28. >for large sequential I/Os, for the NFS I/O mix (generally 8KB and all
  29. >over the disk [sound familiar?]) SCSI was a win.
  30. >
  31. >John
  32.  
  33. Actually on Ultrix systems this is not true.  IPI will still win.  The
  34. paper uses a couple of arguments which are either outdated, or don't
  35. apply to these systems:
  36.  
  37. 1) SCSI should do better for random I/O since it has a buffer and IPI
  38.    doesn't.
  39.  
  40.    The newest IPI drives now have buffers just like SCSI drives (Seagate's
  41.    Elite-3 IPI drive has a .5 MB buffer).  Even when using non-buffered
  42.    drives on DECsystems, this argument still fails since the IPI
  43.    **controllers** extensively buffer and cache the data.  The paper
  44.    compared a situation where the IPI drive was connected to the system
  45.    with a much less sophisticated IPI **adapter**.
  46.  
  47. 2) SCSI optimizes multiple drives by placing a lot of intelligence on the
  48.    drive.
  49.  
  50.    Again newer IPI drives also have this increased intelligence built in.
  51.    Also, the IPI controllers for DECsystems provides a much higher level
  52.    of optimization than the SCSI adapters.  The IPI controllers can do
  53.    overlapped seeks, command queueing, command ordering, rotational latency
  54.    optimization, and command consolidation - all controlled by an on-board
  55.    microprocessor which is running at 10 Million instructions per second.
  56.  
  57. Now as Alan Rollow points out, this may well be overkill for the original
  58. requirement.  But even for random I/O or NFS; on DECsystems, IPI is much
  59. faster than SCSI.  BTW, all the above remains true for TURBOchannel based
  60. Alpha systems (DEC 3000/500 and DEC 3000/400) running OSF/1.
  61.  
  62.  
  63. --
  64. Joe Nordman, V.P. of R&D                 joe@genroco.com 
  65. GENROCO, Inc.           
  66.  
  67.