home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / dcom / modems / 11267 < prev    next >
Encoding:
Internet Message Format  |  1992-07-27  |  3.2 KB
  1. Xref: sparky comp.dcom.modems:11267 can.uucp:181
  2. Path: sparky!uunet!wupost!cs.utexas.edu!torn!cunews!revcan!ecicrl!eci386!woods
  3. From: woods@eci386.uucp (Greg A. Woods)
  4. Newsgroups: comp.dcom.modems,can.uucp
  5. Subject: Re: UUCP 'g' vs. MNP & V.42
  6. Message-ID: <1992Jul27.193824.3733@eci386.uucp>
  7. Date: 27 Jul 92 19:38:24 GMT
  8. References: <1992Jul23.180658.20724@eci386.uucp> <mN8FoB2w164w@zswamp.UUCP>
  9. Organization: Elegant Communications Inc.
  10. Lines: 54
  11.  
  12. In article <mN8FoB2w164w@zswamp.UUCP> geoff@zswamp.UUCP (Geoffrey Welsh) writes:
  13. > Just the facts so's the folks make the best decisions:
  14.  
  15. Remember that unless you understand the relationships between
  16. different protocols being used (i.e. how they interact), and the
  17. effects that may be due to particular implementations or due to
  18. parameters set in particular connections, you cannot use "common
  19. sense" in making statements about communications issues, even if you
  20. know many of the details about each protocol.
  21.  
  22. > woods@eci386.uucp (Greg A. Woods) writes:
  23. > > MNP-4 is link-layer protocol that retries erroneous packets.  UUCP 'g'
  24. > > is a link-layer protocol that retries erroneous packets.  Guess what
  25. > > -- the don't get along very well!
  26. > 
  27. >    This is *completely* untrue!  While MNP may increase latency compared to a 
  28. > normal link, it does not in any way interfere with the data being sent.
  29.  
  30. Except where that latency will cause problems with some other file
  31. transfer or error correcting protocol that's being encapsulated by MNP-4.
  32.  
  33. We're talking about UUCP 'g' here, and with "normal" parameters,
  34. uucico will often wait (and sometimes timeout while waiting) for
  35. ACKs.  This degrades throughput.  It is effectively a loss of ~15%
  36. when MNP-4 and UUCP 'g' are used over V.22bis, and as much as 50% when
  37. used over V.32.  These are measured results.
  38.  
  39. >    There is no harm in using an error-correcing protocol over an 'error-free' 
  40. > link (I put that in quotes because MNP guarantees no errors between the 
  41. > modems, not no errors between the computers), unless the protocol imposes a 
  42. > significant overhead.  Since, in this case, the overhead is more than made up 
  43. > for by start and stop bit removal, there is no reason not to use MNP under 
  44. > UUCP-g, at least not at 2400 bps where the increased latency should not push 
  45. > past the window size.
  46.  
  47. Sorry, but that is *NOT* the case, as measured in actual connections
  48. with UUCP 'g' window size at both 3 and 7.  Even the 20% gain in
  49. efficiency courtesy of MNP-4 is still not sufficient to overcome
  50. timing problems.
  51.  
  52. [No, at 2400 bps the increased latency of MNP-4 without spoofing does
  53. not usually cause *timeouts* with UUCP 'g' at a window size of 3,
  54. packet size of 64, but will cause delays.  Note however that line
  55. noise will immediately increase the latency, and thus the chance of a
  56. timeout.  So, spoofing is a double win -- 1) the host-to-modem link is
  57. guaranteed error free; 2) the DCE-DCE link latency does not affect the
  58. file transfer protocol.]
  59.  
  60. So, any other questions about why UUCP sites everywhere use Telebits?  :-)
  61. -- 
  62.                         Greg A. Woods
  63. woods@Elegant.COM, woods@robohack.UUCP  VE3TCP    ECI & UniForum Canada
  64. +1-416-443-1734 [h]  +1-416-595-5425 [w]    Toronto, Ontario; CANADA
  65. Political speech and writing are largely the defense of the indefensible-ORWELL
  66.