home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / dcom / modems / 11238 < prev    next >
Encoding:
Internet Message Format  |  1992-07-27  |  2.5 KB
  1. Xref: sparky comp.dcom.modems:11238 can.uucp:178
  2. Path: sparky!uunet!utcsri!utgpu!attcan!ncrcan!becker!bdb
  3. From: bdb@becker.GTS.ORG (Bruce Becker)
  4. Newsgroups: comp.dcom.modems,can.uucp
  5. Subject: Re: UUCP 'g' vs. MNP & V.42
  6. Message-ID: <1992Jul27.045202.14224@becker.GTS.ORG>
  7. Date: 27 Jul 92 04:52:02 GMT
  8. References: <1992Jul20.052318.29102@zooid.guild.org> <1992Jul23.180658.20724@eci386.uucp> <1992Jul24.034646.26340@chance.gts.org>
  9. Organization: G. T. S., Toronto, Ontario
  10. Lines: 52
  11.  
  12. In article <1992Jul24.034646.26340@chance.gts.org> john@chance.gts.org (John R MacMillan) writes:
  13. ||Anybody running MNP at any level with UUCP 'g' should have their modem
  14. ||and UUCP configurations examined!  :-)
  15. |
  16. |I don't know, I use MNP-5 (and hence 4) on two of my mostly-mail (ie.
  17. |uncompressed) connections and I see much improved throughput.  Even on
  18. |much of the compressed stuff there is some improvement, though there
  19. |is sometimes also degradation.
  20. |
  21. ||MNP-4 is link-layer protocol that retries erroneous packets.  UUCP 'g'
  22. ||is a link-layer protocol that retries erroneous packets.  Guess what
  23. ||-- the don't get along very well!
  24. |
  25. |Why not?  The 'g' protocol would just never (or very rarely; only in
  26. |modem-to-computer failures) see failures.  In my case, where the 'g'
  27. |protocol isn't spoofed at the modem, and has to go all the way to the
  28. |computer, that's a win.
  29. |
  30. ||...  [V.42bis, MNP-5, and LZ are all variants of the Lempel-Ziv
  31. ||compression algorithm, though most implementations of MNP-5 *reduce*
  32. ||throughput with pre-compressed data, and each have varying degrees of
  33. ||efficiency and ratios of compression.]
  34. |
  35. |It's my understanding that all MNP-5 implementations will sometimes
  36. |reduce throughput of some pre-compressed data because the compression
  37. |is always done; it's not dependent on the implementation, but on the
  38. |data.  This is unlike V.42bis, where if the compressed block is larger
  39. |than the original, the uncompressed block is sent.
  40.  
  41.  
  42.     I've turned MNP off on all my modems because
  43.  
  44.  
  45.     1. it seems inefficient to have it on top of
  46.        uucp frames;
  47.  
  48.  
  49.     2. I can't turn on V.42bis compression indep-
  50.        endently from MNP-5 compression;
  51.  
  52.  
  53.     3. the telebits bid V.42 first, then if it is
  54.        enabled, MNP.  By the time the modems have
  55.        gone thru all the tones etc., uucico might
  56.        have given up in disgust 8^)
  57.  
  58.  
  59. -- 
  60.   ,u,     Bruce Becker            Toronto, Ontario
  61. a /i/     Internet: bdb@becker.gts.org    Uucp: ...!web!becker!bdb
  62.  `\o\-e     -=[ ]=-=[ ]=-=[ ]=-=[ ]=-=[ ]=-=[ ]=-=[ ]=-=[ ]=-=[ ]=-
  63.  _< /_     "Usenet is never having to say you're sorry" - Handy Andy
  64.