home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / vmsnet / internal / 1209 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  4.7 KB
  1. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!gatech!ukma!cs.widener.edu!iggy.GW.Vitalink.COM!pacbell.com!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: <9208281401.AA18734@sndsu1.sinet.slb.com>
  6. Date: Fri, 28 Aug 92 14:01:37 GMT
  7. Organization: Macro32<==>Vmsnet.Internals Gateway
  8. X-Gateway-Source-Info: Mailing List
  9. Lines: 84
  10.  
  11. Somebody (looks like gjc@mitech.com) says:
  12. >This talk about FPL etc has reminded me to ask a question
  13. >about VAXCLUSTER (LAVC) behavior.
  14. >
  15. >The behavior of the VMS memory management with respect to the FPL
  16. >and installed images is said to reduce the amount of disk activity
  17. >required when activating commonly used images, as long
  18. >as the amount of free pages available allows pages from your favorite image
  19. >to remain in the FPL.
  20. >
  21. >Correct?
  22. >
  23. >Now. My question is, what good does this do in a VAXCLUSTER environment,
  24. >specifically a LAVC environment? Here a page fault consists
  25. >of both a trip over the ethernet and a trip to disk.
  26. >
  27. >Obviously if a satelite has the pages of an image already in memory,
  28. >then you will winning big, avoiding a trip across the ethernet and everything.
  29. >
  30. >But what about the trip to disk? Is there a way to avoid that?
  31.  
  32. I'm having a hard time understanding your question.  Please elaborate...
  33.  
  34. >The LAVC server node may have plenty of free memory, but it may have *never*
  35. >activated any of the images that people on the LAVC's are interested in.
  36. >
  37. >Even if it had activated those images, would there be any optimization
  38. >available? (That is, does the vaxcluster lavc disk server -know- that
  39. >pages from a disk file may already be available in memory?)
  40. >
  41. >My current situation is that I have a VAXSTATION-3200 with plenty
  42. >of free memory serving as a LAVC boot node, and I'm interested in
  43. >any hacks available to speed things up.
  44.  
  45. Increasing the size of the file system caches on the 3200 would probably do
  46. something for you.  Sysgen parameters ACP_*.
  47.  
  48. >In VMS 5.4-3 I was using the hack of having all images from SYS$SYSTEM
  49. >and SYS$SHARE also available on the local hard disk. That is a bit hackish,
  50. >so I didn't bother re-doing that for VMS 5.5.
  51.  
  52. I'll bet that your V5.4-3 optimization was actually slowing things down.  My
  53. unproven contention is that paging (and image activation) through ethernet is
  54. actually faster than to a local disk (assumption: disks on a local workstation
  55. are slower than on the boot server).
  56.  
  57. Really the only things that the NI port driver does is the same things that
  58. the CI port driver does.  And all that CI driver does (for this purpose) is
  59. talk to an HSC-xx device through the CI.  When the CPU makes a request for
  60. disk information, the HSC is really a disk block server, not a file server.
  61. The logic on a boot server turns it into a file server.  The major 'smarts'
  62. are in VMS, not the HSC.  MSCP is some of these 'smarts'.  Seems to me that
  63. paging from a satellite shows up on the boot node as [MSCP?] requests for
  64. particular disk blocks, not as requests for file 'x' in directory 'y'.  I
  65. don't think the NI port driver on the boot node does any translation (Can
  66. somebody with source listings confirm or deny this?).  But I believe if the
  67. boot node gets 2 subsequent requests for block 'n', it can pull the second one
  68. from cache.  Correct?
  69.  
  70. Disk access times (read/write) are measured in milliseconds. Ethernet
  71. transactions are on a microsecond level.   When a satellite pages onto its
  72. local disk, it is doing I/O's of probably 20-40 milliseconds average (depends
  73. on a number of things).  When a satellite pages through ethernet to another
  74. system, the data is seen as MSCP info (?) on the boot node and (1) write times
  75. are essentially the speed of the boot server disk, (2) reads are considered
  76. user data on the boot server and are cached.  Therefore a page read request
  77. from a workstation for data that is cached on the boot node could be on the
  78. order of several hundred microseconds, significantly faster than a disk access
  79. to the local disk.
  80.  
  81. My claim is that paging through [an unloaded] ethernet is faster than to a
  82. local disk.  Of course if a lot of systems page this way, you will have a
  83. network contention problem which will slow things down.  [By the way, this
  84. assumes paging to another VMS system.  Paging to an Infoserver, as per the
  85. VXT2000 workstation is essentially the speed of the disk on the infoserver,
  86. plus you are generating ethernet traffic.  There is no caching on an
  87. Infoserver.]
  88.  
  89. Any disagreements with the above?  Anybody do any quantitative testing on
  90. this?
  91. _______________________________________________________________
  92. Harvey Brydon         | Internet:   brydon@dsn.SINet.slb.com
  93. Dowell Schlumberger   | P.O.T.S.:   (918)250-4312
  94. I bought my VAXstation from my uncle on his deathbead - I wrote him a check.
  95.