home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / dcom / modems / 11081 < prev    next >
Encoding:
Internet Message Format  |  1992-07-23  |  1.8 KB
  1. Xref: sparky comp.dcom.modems:11081 can.uucp:168
  2. Newsgroups: comp.dcom.modems,can.uucp
  3. Path: sparky!uunet!uunet.ca!wildcan!sq!chance!john
  4. From: john@chance.gts.org (John R MacMillan)
  5. Subject: Re: UUCP 'g' vs. MNP & V.42
  6. Message-ID: <1992Jul24.034646.26340@chance.gts.org>
  7. Organization: Reverse - esreveR :noitazinagrO
  8. References: <1qX7NB1w164w@beltrix.guild.org> <1992Jul20.052318.29102@zooid.guild.org> <1992Jul23.180658.20724@eci386.uucp>
  9. Date: Fri, 24 Jul 1992 03:46:46 GMT
  10. Lines: 27
  11.  
  12. |Anybody running MNP at any level with UUCP 'g' should have their modem
  13. |and UUCP configurations examined!  :-)
  14.  
  15. I don't know, I use MNP-5 (and hence 4) on two of my mostly-mail (ie.
  16. uncompressed) connections and I see much improved throughput.  Even on
  17. much of the compressed stuff there is some improvement, though there
  18. is sometimes also degradation.
  19.  
  20. |MNP-4 is link-layer protocol that retries erroneous packets.  UUCP 'g'
  21. |is a link-layer protocol that retries erroneous packets.  Guess what
  22. |-- the don't get along very well!
  23.  
  24. Why not?  The 'g' protocol would just never (or very rarely; only in
  25. modem-to-computer failures) see failures.  In my case, where the 'g'
  26. protocol isn't spoofed at the modem, and has to go all the way to the
  27. computer, that's a win.
  28.  
  29. |...  [V.42bis, MNP-5, and LZ are all variants of the Lempel-Ziv
  30. |compression algorithm, though most implementations of MNP-5 *reduce*
  31. |throughput with pre-compressed data, and each have varying degrees of
  32. |efficiency and ratios of compression.]
  33.  
  34. It's my understanding that all MNP-5 implementations will sometimes
  35. reduce throughput of some pre-compressed data because the compression
  36. is always done; it's not dependent on the implementation, but on the
  37. data.  This is unlike V.42bis, where if the compressed block is larger
  38. than the original, the uncompressed block is sent.
  39.