home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / os / vms / 12672 < prev    next >
Encoding:
Internet Message Format  |  1992-07-22  |  2.9 KB
  1. Path: sparky!uunet!gatech!destroyer!ncar!noao!arizona!arizona.edu!telcom.arizona.edu!leonard
  2. From: leonard@telcom.arizona.edu (Aaron Leonard)
  3. Newsgroups: comp.os.vms
  4. Subject: Re: Vax to Ultrix delay over decnet
  5. Message-ID: <1992Jul22.135053.3523@arizona.edu>
  6. Date: 22 Jul 92 20:50:47 GMT
  7. References: <1992Jul22.170955.22876@macc.wisc.edu>
  8. Reply-To: Leonard@Arizona.EDU
  9. Distribution: usa,local
  10. Organization: University of Arizona Telecommunications
  11. Lines: 54
  12. Nntp-Posting-Host: bugs.telcom.arizona.edu
  13.  
  14. In article <1992Jul22.170955.22876@macc.wisc.edu>, 
  15. stevens@vms.macc.wisc.edu (PAul STevens - MACC - 2-9618) writes:
  16.  
  17. >>    When we dlogin from ultrix to vms, all works well. Going the
  18. >>other way, vms to ultrix (via SET HOST), we experience really long
  19. >>delays [....]
  20. >
  21. >I have found that this happens when an ethernet packet is lost.  The
  22. >decnet timeout value is 6 seconds.  Can't be changed as far as I can
  23. >tell.
  24.  
  25. See the NCP commands SET EXEC DELAY FACTOR and SET EXEC RETRANS
  26. FACTOR.  The DELAY FACTOR is the minimum time (in sec/16) that
  27. DECnet NSP will wait before retransmitting a packet.  By default, it's
  28. set to 80, and so NSP will wait 5 seconds before retransmitting.
  29.  
  30. >Telnet's timeout is generally a few tens of milliseconds.
  31.  
  32. Not true.  If it were, then every high- or variable-delay network
  33. would quickly be destroyed by TELNET.  TCP uses a sophisticated
  34. adaptive retransmission mechanism, but RFC-1122 recommends
  35. beginning with a retransmission timeout of 3 seconds.
  36.  
  37. >Decnet must have been manufactured in a clean-room with three nodes.
  38. >It works rather poorly on busy, noisy networks.  I have fought these
  39. >problems for years and all I can ever get from DEC is advice to make
  40. >the ethernet work better.  IP protocols are much more robust.  I have
  41. >seen cases where over 80 percent of packets sere being lost (no---that
  42. >is not normal, even here!) and telnet users had no complaints.  VAX
  43. >clusters simply crashed.
  44.  
  45. Your TELNET users must have the patience of Job, then.  Performance on
  46. all network protocols that I am familiar with will go right down the 
  47. toilet if you have as much as 2% packet loss, let alone 80%.
  48.  
  49. It is true that LAVc nodes will bugcheck if they can't find the cluster for 
  50. RECNXINTERVAL seconds, which is set by default to 20 (I recommend 
  51. changing this to 120 on a large multipurpose network.)
  52.  
  53. DECnet NSP is a relatively robust transport protocol, although not quite
  54. as massively tweaked as TCP.  However, it performs much better in 
  55. wide-area / lossy networks than, say, NFS, IPX, AppleTalk and many others.
  56.  
  57. A properly configured Ethernet will lose virtually no packets (<0.1%)
  58. until it's grotesquely overloaded (>>90%).  Greater packet loss than
  59. that is sign of electrical misconfiguration or hardware malfunction.
  60. Find someone responsible for your network, and encourage him to
  61. fix it.
  62.  
  63. Aaron
  64.  
  65. Aaron Leonard (AL104), <Leonard@Arizona.EDU>
  66. University of Arizona Network Operations, Tucson AZ 85721
  67. |>   If it ain't broke, break it.
  68.