home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / os / vms / 12718 < prev    next >
Encoding:
Internet Message Format  |  1992-07-23  |  2.8 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!zazen!news
  2. From: stevens@vms.macc.wisc.edu (PAul STevens - MACC - 2-9618)
  3. Newsgroups: comp.os.vms
  4. Subject: Re: Vax to Ultrix delay over decnet
  5. Message-ID: <1992Jul23.174522.7714@macc.wisc.edu>
  6. Date: 23 Jul 92 17:18:41 GMT
  7. Sender: news@macc.wisc.edu (USENET News System)
  8. Distribution: usa,local
  9. Organization: University of Wisconsin Academic Computing Center
  10. Lines: 49
  11.  
  12. In article <1992Jul22.135053.3523@arizona.edu>, leonard@telcom.arizona.edu (Aaron Leonard) writes...
  13.  
  14. >>Telnet's timeout is generally a few tens of milliseconds.
  15. > 
  16. >Not true.  If it were, then every high- or variable-delay network
  17. >would quickly be destroyed by TELNET.  TCP uses a sophisticated
  18. >adaptive retransmission mechanism, but RFC-1122 recommends
  19. >beginning with a retransmission timeout of 3 seconds.
  20.  
  21.  You are probably right.  My information comes from watching what
  22.  happens on the network when a packet is lost.  I see a retransmission
  23.  in only a few tens of milliseconds.  In fact, I have seen them occur
  24.  in only a few milliseconds.  This may have happened after the nodes
  25.  discovered how close together they were.
  26.  
  27. > 
  28. >Your TELNET users must have the patience of Job, then.  Performance on
  29. >all network protocols that I am familiar with will go right down the 
  30. >toilet if you have as much as 2% packet loss, let alone 80%.
  31. > 
  32.  
  33.  Not at all!  This I have seen with my own eyes.  People call me
  34.  to complain that their Novell server is dead and that their
  35.  VAX/VMS nodes are printing adjacency messages and when I arrive with
  36.  a network sniffer I discover that someone has extended their thinwire
  37.  with 75 ohm wire from Radio Shack.  But when I use telnet on a PC,
  38.  I cannot tell that anything is wrong.  And I have *seen* that each
  39.  packet is repeated many times before being acknowledged.  I am pretty
  40.  sure that NCSA telnet is very simple; it has a timeout value in
  41.  CONFIG.TEL that specifies timout in 1/18ths of a second.  Mine came
  42.  with a value of one.
  43. > 
  44. >A properly configured Ethernet will lose virtually no packets (<0.1%)
  45. >until it's grotesquely overloaded (>>90%).  Greater packet loss than
  46. >that is sign of electrical misconfiguration or hardware malfunction.
  47. >Find someone responsible for your network, and encourage him to
  48. >fix it.
  49. > 
  50.  
  51.   I agree with this paragraph 100%.  Unfortunately it is I who am 
  52.   called upon to fix about 60 of the ethernet segments on the
  53.   campus.  But they are always fixable to the standards you suggest.
  54.   In fact, I like to think I can make it much less than 0.1%.  I
  55.   don't think overload should cause packet loss except perhaps
  56.   in software queues on the machines connected to the net.
  57.  
  58.   And thanks to everyone for the hints about the DECNET EXEC parameters
  59.   to adjust retransmission delays.  I will try them and if they don't
  60.   work you will hear from my boys.  ;-)
  61.