home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / vmsnet / internal / 1233 < prev    next >
Encoding:
Internet Message Format  |  1992-08-31  |  2.9 KB
  1. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!news.acns.nwu.edu!network.ucsd.edu!mvb.saic.com!macro32
  2. From: <brydon@dsny25.sinet.slb.com>
  3. Newsgroups: vmsnet.internals
  4. Subject: RE: VMS tuning for a vaxcluster (LAVC)
  5. Message-ID: <9208311910.AA15058@sndsu1.sinet.slb.com>
  6. Date: Mon, 31 Aug 92 19:10:38 GMT
  7. Organization: Macro32<==>Vmsnet.Internals Gateway
  8. X-Gateway-Source-Info: Mailing List
  9. Lines: 44
  10.  
  11. Bob George (BOB@AENEAS.IMS.DISA.MIL) sez:
  12. >#Nope.  The local disk's still faster.  When I and a friend did VMS tuning
  13. >#studies for <a former employer> we found that even on an unloaded net the
  14. >#local disk was faster.  Mind you, this was using VAXstation IIs with between
  15. >#5 and 16MB and RD54s.  Mileage on newer systems may vary, but I'd bet that
  16. >#the local disk still beats Ethernet traffic.
  17. >
  18. >[lots of interesting stuff deleted]
  19. >
  20. >Am I missing something fairly obvious in this thread or on the nonlocal
  21. >paging, don't you still have to wait for a disk I/O to occur.  On top of
  22. >the overhead of setting up the ethernet packet(s), when it gets to the
  23. >node where it was going, there is still a disk I/O that needs done.  On
  24. >a page write, this activity could be buffered.  But on a page read, the
  25. >process would still be hung up until the actual disk gets read and the data
  26. >returned.  For at least moderately similar disks, this would give the
  27. >advantage to the local disks.
  28.  
  29. To restate several points I was trying to make:
  30.  
  31. (1) What is considered page/swap data on the satellite may (or may not?) be
  32. considered cache-able data on the boot node.  Reads will probably show
  33. different numbers from writes any way you look at it.  In a previous message
  34. in this thread, somebody (from DEC?) indicated that there could be no caching
  35. on either reads or writes for some reason...what is the explanation for that?
  36.  
  37. (2) Yes it takes ethernet processing, but even on a slow VMS system, this will
  38. be on the order of a few microseconds.  Okay, say it is 100 microseconds.  One
  39. millisecond of disk controller latency (or any other delay) is 1000
  40. microseconds.  Access times on disks are typically 20000 to 50000 microseconds
  41. (remember the difference between 'average access time' and 'maximum access
  42. time' and 'typical access time').
  43.  
  44. (3) In many cases, the hardware technology on the boot node is much better
  45. (eg. faster) than that on the satellite node.  This goes back to the birth of
  46. the technology with 45 msec RD53/RD54s on VAXstation 2000's and 25 msec DSA
  47. drives on an 86xx boot node.  Assume 1 millisecond for ethernet overhead and
  48. processing.  With this configuration, 25 + 1 is much less than 45.  The access
  49. time numbers for boot nodes versus satellites is getting closer but a
  50. difference (based on technology) still seems to be the case.
  51. _______________________________________________________________
  52. Harvey Brydon         | Internet:   brydon@dsn.SINet.slb.com
  53. Dowell Schlumberger   | P.O.T.S.:   (918)250-4312
  54.    Reality is for those that can't handle simulation.
  55.