home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / vms / 19940 < prev    next >
Encoding:
Text File  |  1992-12-28  |  4.5 KB  |  98 lines
  1. Newsgroups: comp.os.vms
  2. Path: sparky!uunet!mcsun!news.funet.fi!aton.abo.fi!usenet
  3. From: HEGE@FINABO.ABO.FI (Kaj H{ggman DC)
  4. Subject: Summary: RECNXINTERVAL
  5. Message-ID: <1992Dec28.082250.3770@abo.fi>
  6. Sender: usenet@abo.fi (Usenet NEWS)
  7. Organization: Abo Akademi University, Finland
  8. Date: Mon, 28 Dec 1992 08:22:50 GMT
  9. X-News-Reader: VMS NEWS 1.24
  10. Lines: 86
  11.  
  12. Hi!
  13.  
  14. I sent the following to the net a couple of weeks ago
  15.  
  16. #Every now and then there are som "bursts" on our ethernet.
  17. #The SUN workstations don't give a s*it, but the VAXstations keep shouting
  18. #to each other quite a lot and eventually reboot.
  19. #The value for RECNXINTERVAL is 120 in our cluster. How far up could
  20. #I crank it, i.e. what impact could it have on the MI-cluster?
  21. #Any other "time-out"-parameters that are worth checking out?
  22. #As I'm not responsible for our network I won't go into that (waiting for
  23. #the move towards routing within the net), but I'd really appreciate any 
  24. #ideas concerning the VAXes. Thanx!
  25.  
  26. and got 8 answers. 
  27.  
  28. 6 people had RECNXINTERVAL set to 120 like me, 1 had it set to 180 and
  29. 1 didn't mention any value for it.
  30.  
  31. Here is a short descirption of the impact of raising the value of 
  32. RECNXINTERVAL:
  33.  The effect of a long RECNXINTERVAL is if a node crashes or hangs and it holds
  34.  a lock on a critical resource (the UAF file for example) it will take
  35.  RECNXINTERVAL seconds before the other nodes determine that the failed node
  36.  should be removed from the cluster. Any applications that need the resource
  37.  would hang. This could result in the entire cluster hanging for RECNXINTERVAL.
  38.  But that may be better than having your all your LAVC nodes crash with a
  39.  CLUEXIT during a network storm. 
  40.  
  41. It seems like I've checked out most of the parameters that are worth checking 
  42. out. For those of you who'd like to experiment with cluster parameters, also 
  43. check out QDSKINTERVAL, PRCPOLINTERVAL, PASTIMOUT, PAPOLLINTERVAL (as Ehud
  44. Gavron mentioned).
  45.  
  46. I also got many comments about our net, having it fixed first, and so on. 
  47.  
  48. It seems to be quite common that local area networks built and configured
  49. at the time when there were no workstations around (just a few hosts and
  50. dump terminals) just can't put up with added load. Then the problem just 
  51. gets worse as new hosts are added. Routing seems to be a good solution.
  52.  
  53. Carl Karcher also told me these things about LAT/LAST:
  54.  Careful, the LAVC protocol is not routable. However, the cicso's can be setup
  55.  to selectively bridge protocols that can't be routed (Like LAVC, LAT, MOP and
  56.  LAST). We don't do that here since our network police don't allow selective
  57.  bridging. One more thing, be sure your cisco's have the latest firmware. We
  58.  just discovered a problem where the router pasted corrupted packets as good
  59.  packets which was affecting Novell and NFS traffic. Here's a brief description:
  60.  
  61.  [A bug in the Cisco interface firmware caused it to ignore CRC errors.
  62.  A corrupted packet received on the routers Ethernet interface would
  63.  have it's CRC recomputed and would be forwarded toward it's
  64.  destination.  So the next node receiving the packet would not be able
  65.  to detect the corruption.
  66.  
  67.  Ethernet devices (with the exception of ethernet analyzer equipment)
  68.  are supposed to drop packets containing CRC errors.  Higher layer
  69.  protocols then trigger retransmission of dropped packets.  Some
  70.  protocols like TCP have an end-to-end checksum so that even if a
  71.  corrupted packet manages to get through, the destination machine can
  72.  detect the corruption.  The Netware protocol assumes that corrupted
  73.  packets will be dropped and that errors created by intermediate nodes
  74.  are extremely rare, so it doesn't include an end-to-end checksum.]
  75.  ......
  76.  The infoserver uses LAST protocol which is also not routable. Pathworks
  77.  disk and file services use LAST too (but file services can use decnet). If you
  78.  use infoservers for holding bookreader documentation CD's, decnet can be used
  79.  (to a node that has the DAD disks mounted) instead of mounting DADn disks.
  80.  
  81. I'm not sure if I can say that "nobody uses a default value of 20 for 
  82. RECNXINTERVAL" (based on my own experiences and 7 answers...), but it seems 
  83. like many people has set it a little higher.
  84.  
  85. Many thanks to    George Burns
  86.         Ehud Gavron
  87.                   Carl Karcher
  88.         Tom Miller
  89.         Malcolm Newman
  90.                 Jeff Rossiter
  91.         Frank Shorter
  92.         Erik Sosman
  93.  
  94. Kaj Haggman             Internet: Hege@abo.fi     Phone:   +358-21-654467
  95. Abo Akademi University  Bitnet:   Hege@finabo     FAX:     +358-21-654497
  96. Computing Center        PSImail:  22101410::HEGE
  97. SF-20500 Abo, FINLAND   X.400:    s=hege o=abo prmd=inet admd=fumail c=fi  
  98.