home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / vmsnet / internal / 1247 < prev    next >
Encoding:
Internet Message Format  |  1992-09-01  |  4.3 KB
  1. Path: sparky!uunet!usc!sdd.hp.com!caen!kuhub.cc.ukans.edu!husc-news.harvard.edu!husc10.harvard.edu!joltes
  2. Newsgroups: vmsnet.internals
  3. Subject: Re: VMS tuning for a vaxcluster (LAVC)
  4. Message-ID: <1992Sep1.120713.15272@husc3.harvard.edu>
  5. From: joltes@husc10.harvard.edu (Richard Joltes)
  6. Date: 1 Sep 92 12:07:12 EDT
  7. References: <9208311910.AA15058@sndsu1.sinet.slb.com>
  8. Organization: Harvard University Science Center
  9. Nntp-Posting-Host: husc10.harvard.edu
  10. Lines: 68
  11.  
  12. <brydon@dsny25.sinet.slb.com> writes:
  13.  
  14. >(2) Yes it takes ethernet processing, but even on a slow VMS system, this will
  15. >be on the order of a few microseconds.  Okay, say it is 100 microseconds.  One
  16. >millisecond of disk controller latency (or any other delay) is 1000
  17. >microseconds.  Access times on disks are typically 20000 to 50000 microseconds
  18. >(remember the difference between 'average access time' and 'maximum access
  19. >time' and 'typical access time').
  20. >
  21. >(3) In many cases, the hardware technology on the boot node is much better
  22. >(eg. faster) than that on the satellite node.  This goes back to the birth of
  23. >the technology with 45 msec RD53/RD54s on VAXstation 2000's and 25 msec DSA
  24. >drives on an 86xx boot node.  Assume 1 millisecond for ethernet overhead and
  25. >processing.  With this configuration, 25 + 1 is much less than 45.  The access
  26. >time numbers for boot nodes versus satellites is getting closer but a
  27. >difference (based on technology) still seems to be the case.
  28.  
  29. "In many cases."  Yes, this is true.  However, when I was conducting my tests
  30. our boot node was a 3600 with an RA81.  The satellites were VSIIs using RD54s
  31. (and occasionally a lonely VS2000 with an RD53 stuffed in).  Our tests still
  32. showed that the diskless satellites were slower.  This may change with the
  33. newer disks (esp the HP2247 with 9ms access time!), but I think it's still
  34. better to test rather than rely on theory, which is what you're doing in (3)
  35. above.  Adding up the milliseconds is fine, but you've missed some bits.
  36. Try this:
  37.  
  38. Local delays                           Remote delays
  39. -----------------------------------------------------------------
  40. QIO to controller                      QIO thru cluster s/w
  41. disk latency, seek, etc                assemble ethernet packet
  42. process polling by VMS                 transmit packet to server
  43. QIO returned from disk                 disassembly of packet by server
  44. process polling by VMS                 QIO to server disk
  45. return to calling process              disk latency, seek, etc.
  46.                                        process polling by VMS
  47.                                        QIO returned from disk
  48.                                        assemble ethernet packet
  49.                                        even more process polling
  50.                                        transmit ethernet packet to satellite
  51.                                        [potential delays on the wire...]
  52.                                        satellite disassembles ethernet packet
  53.                                        yet more process polling
  54.                                        return to calling process
  55.  
  56. Some of my steps and nomenclature may be debatable (I'm trying to illustrate
  57. the difference in number of steps, not teach how it's done) but my point is
  58. fairly clear.  In the case of the local disk you're relying only on the h/w
  59. and local VMS overhead.  With LAVC traffic, there are many additional steps
  60. required to perform the same task.  With only one or two satellites there
  61. won't be too much delay at the server (but still an appreciable amount, esp.
  62. if the server isn't just doing disk accesses), but as the number of satellites
  63. grows, so does resource contention.
  64.  
  65. Sure, there will be case-by-case variations (like the example of an RF35-
  66. equipped server talking to RD-based satellites), but overall I still think
  67. it's better to keep as much processing as possible local to the satellite.
  68. Disks are cheap, overall.  Performance tuning on systems that have gone to
  69. production work is more expensive, IMHO, in lost time and user frustration.
  70.  
  71. Polemic ended...hopefully helpful!
  72.  
  73. --------------------------------------------------------------------------------
  74. Dick Joltes                        joltes@husc.harvard.edu
  75. Hardware & Networking Manager, Computer Services     joltes@husc.bitnet 
  76. Harvard University Science Center
  77.  
  78. "Mind you, not as bad as the night Archie Pettigrew ate some
  79. sheep's testicles for a bet...God, that bloody sheep kicked him..."
  80.