home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / dcom / modems / 17206 < prev    next >
Encoding:
Text File  |  1992-11-24  |  2.9 KB  |  62 lines
  1. Newsgroups: comp.dcom.modems
  2. Path: sparky!uunet!cis.ohio-state.edu!mstar!mstar!bob
  3. From: bob@MorningStar.Com (Bob Sutterfield)
  4. Subject: Re: PEP over SLIP?
  5. In-Reply-To: vjs@rhyolite.wpd.sgi.com's message of 19 Nov 92 06: 31:49 GMT
  6. Message-ID: <BOB.92Nov23235837@volitans.MorningStar.Com>
  7. Sender: news@MorningStar.Com
  8. Nntp-Posting-Host: volitans.morningstar.com
  9. Organization: Morning Star Technologies
  10. References: <1992Nov16.213034.27895@eos.arc.nasa.gov>
  11.     <BOB.92Nov18175532@volitans.MorningStar.Com>
  12.     <shvdb6c@rhyolite.wpd.sgi.com>
  13.     <sjsv1fo@rhyolite.wpd.sgi.com>
  14. Date: Tue, 24 Nov 1992 04:58:42 GMT
  15. Lines: 45
  16.  
  17. In article <shvdb6c@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
  18.    In article <BOB.92Nov18175532@volitans.MorningStar.Com>, bob@MorningStar.Com (Bob Sutterfield) writes:
  19.       Even with only a single FTP stream traversing the link in one
  20.       direction, the returning TCP ACKs (even VJ-compressed) usually
  21.       require a large PEP packet,
  22.  
  23.    Are you sure?  I thought the magic number was 12 bytes.  12 is much
  24.    larger than any reasonable VJ-compressed ACK.
  25.  
  26. As it was explained to me by a protocol engineer at Telebit, who had
  27. talked to the modem engineers, packets are sent when a timer ticks,
  28. not when "enough" bytes arrive.  If few enough bytes are awaiting
  29. transmission, they'll go in a micropacket (11 bytes), which doesn't
  30. require that the line be turned around.  If more bytes than will fit
  31. in a micropacket are awaiting transmission, they'll be sent in a large
  32. packet (340 bytes), which requires a longer line turnaround process.
  33. I even tried using their magical undocumented micro packet disabler
  34. switch (AT~D1S500=12), which should instruct the modem to always use
  35. small (43 bytes) packets, into which an ACK is more likely to fit, but
  36. that only decreased throughput and increased latency.
  37.  
  38.       Performance (both throughput and latency) degrades under
  39.       increased offered load much more catastrophically with PEP than
  40.       with V.32bis.
  41.  
  42.    Are you sure?  From my experience, PEP does best when loaded.  It
  43.    does worst with light traffic, such as interactive stuff.
  44.  
  45. I was thinking of simultaneous FTPs in both directions.  Both
  46. throughputs suffer more than either of them does over a V.32bis
  47. carrier.
  48.  
  49. In article <sjsv1fo@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
  50.    These kinds of latencies happen in other circumstatnces.  For
  51.    example, take a pair of Cisco routers and a 56K line.  Run a TCP
  52.    based file transfer over the link between a pair of computers with
  53.    60K TCP windows.  At the same time, try to do some interactive
  54.    stuff.
  55.  
  56. I think cisco implements TOS queueing, but to get any benefit, you
  57. need to run with small MTUs (thus sacrificing some throughput) so that
  58. your high-priority interactive packets can squeeze ahead of the batch
  59. stuff that's waiting to go.  If you have large MTUs, you won't be able
  60. to get an interactive packet on the wire until the next moby FTP
  61. packet is flying.
  62.