home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / dcom / modems / 12431 < prev    next >
Encoding:
Text File  |  1992-08-23  |  3.0 KB  |  66 lines
  1. Newsgroups: comp.dcom.modems
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!destroyer!terminator!honey
  3. From: honey@citi.umich.edu (Peter Honeyman)
  4. Subject: Re: Modems, compression, and SLIP or PPP (was Re: Using Telebit PEP with SLIP)
  5. Message-ID: <1992Aug23.202309.22443@terminator.cc.umich.edu>
  6. Sender: news@terminator.cc.umich.edu (Usenet Owner)
  7. Reply-To: honey@citi.umich.edu
  8. Organization: Center for Information Technology Integration, Univ of Michigan
  9. References: <3619@randvax.rand.org> <BOB.92Jul21000352@volitans.MorningStar.Com> <BOB.92Jul28004244@volitans.MorningStar.Com>
  10. Date: Sun, 23 Aug 1992 20:23:09 GMT
  11. Lines: 53
  12.  
  13. Bob Sutterfield writes:
  14. |> Whether you use V.42bis depends upon your application.  It will only
  15. |> very rarely (if at all) decrease your throughput, likewise latency, so
  16. |> it's probably safe to turn it on and leave it on for most purposes.
  17.  
  18. in experiments run here, we have seen very high latencies due to v.42
  19. and v.42bis.  (but since we use the network more for file transfer
  20. than interactive traffic, we do leave them on, as bob suggests.)
  21.  
  22. |> A typical PPP frame is exactly three bytes larger than a typical SLIP
  23. |> frame.  This expands a typical VJ-compressed telnet packet from five
  24. |> bytes to eight.  So far as I can tell, the difference is unmeasurable
  25. |> and imperceptible.
  26.  
  27. a typical vj-compressed telnet packet is four bytes, not five -- here
  28. are three quotes from rfc 1144, "compressing tcp/ip headers for
  29. low-speed serial links", by van jacobson:
  30.  
  31. from section 1 (introduction): the average compressed header is 3 bytes
  32.  
  33. from section 3.1 (the basic idea): Recognizing a couple of special
  34. cases special cases will get us three byte headers for the two most
  35. common cases---interactive typing traffic and bulk data transfer
  36.  
  37. from section 3.2.2 (compressed packet format): compressed terminal
  38. traffic usually looks like (in hex):  0B c c d, where the 0B indicates
  39. case (1), c c is the two byte TCP checksum and d is the character
  40. typed.
  41.  
  42. |> Few connections are error-free.  A V.32bis/V.42/V.42bis modem, clocked
  43. |> at 38400 or better, can easily deliver bits fast enough to overwhelm
  44. |> primitive serial I/O interfaces such as are found in many popular UNIX
  45. |> systems.  Those UART overruns are manifested as line errors, which
  46. |> PPP's 16-bit CRC (not a checksum!) will almost always catch, so that
  47. |> the PPP can drop the damaged packet before passing it up to IP.  This
  48. |> will save your bacon if you're running non-UDP-checksummed NFS, even
  49. |> over a V.42 or MNP4 modem.
  50.  
  51. many errors here.
  52.  
  53. my home computer is an ibm rt, three or so mips, with a run of the
  54. mill 16550 async card.  i run the interface at 57,600.  uart overruns
  55. are infrequent -- way less than 1%.
  56.  
  57. crc *is* a checksum -- that's what the second c stands for.
  58.  
  59. what
  60. |> 
  61. |>    But there are other aspects of PPP which makes it useful...
  62. |> 
  63. |> Right.  You may find some useful tidbits for comparison in the paper I
  64. |> presented at last December's Sun User Group in San Jose.  Get it from
  65. |> ftp.uu.net:vendor/MorningStar/papers/sug91-cheapIP.ps.Z.
  66.