home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / dcom / modems / 12954 < prev    next >
Encoding:
Text File  |  1992-09-04  |  2.9 KB  |  64 lines
  1. Newsgroups: comp.dcom.modems
  2. Path: sparky!uunet!stanford.edu!ames!sgi!rhyolite!vjs
  3. From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
  4. Subject: Re: Latency Question
  5. Message-ID: <pea6luk@rhyolite.wpd.sgi.com>
  6. Organization: Silicon Graphics, Inc.  Mountain View, CA
  7. References: <1992Sep2.034404.18553@wdl.loral.com> <BOB.92Sep4104913@volitans.MorningStar.Com>
  8. Date: Fri, 4 Sep 1992 16:13:31 GMT
  9. Lines: 53
  10.  
  11. In article <BOB.92Sep4104913@volitans.MorningStar.Com>, bob@MorningStar.Com (Bob Sutterfield) writes:
  12. > In article <1992Sep3.003250.14571@zip.eecs.umich.edu> dmuntz@quip.eecs.umich.edu (Daniel A Muntz) writes:
  13. >    Latency hasn't changed at all between my WB's after upgrading to
  14. >    5.01.  Ping settles to ~200ms (56 data bytes).
  15. > 
  16. > That packet is so big (~88 octets, counting ICMP headers) that it's a
  17. > better measure of in-modem data compression (V.42bis) than of
  18. > modem-induced latency, or of the responsiveness that the user feels
  19. > when typing in a telnet session that crosses the link.
  20. > 
  21. > To test modem-induced latency, you want the smallest packet possible.
  22. > ...
  23.  
  24. > These interactive latencies are far better than what you see with ICMP
  25. > pings, and they better represent the type of latency that matters:
  26. > what a user feels.  It's encouraging that they're generally below the
  27. > magical 200ms perceptibility threshhold.
  28. > ...
  29.  
  30. That's true if you want to measure the latency associated with
  31. keystroke echos during dumb-terminal telnet sessions.
  32.  
  33. If you want to measure the latency of keystroke echos with xterm, you
  34. want to use something with the much larger than 1-byte of payload.  X
  35. is not like telnet.  Non-host-compressed pings with a small "-s size"
  36. are probably a lot closer to what you'll see with xterm.
  37.  
  38. If you really care about typing latency latency, the best thing to do
  39. is get rid of all of that telnet/TCP/IP/{PPP,SLIP} nonsense, and use a
  40. simple, dumb-terminal protocol directly over the modem.
  41.  
  42.  
  43. It seems to me that the premise that single data-byte latency is all
  44. that matters with telnet is wrong.  I use `rlogin` over compressing
  45. SLIP and v.32bis/v.42/v.42bis a lot.   For for many hours/day and many
  46. days/week.  The single character latency is not what really hurts,
  47. whether it is 10 or 100 ms.  What is noticable is the latency to `vi`
  48. edits or `ls`, when the answer is 1KBytes or even 100Bytes.
  49.  
  50. FDX character echo times have been perfectly fine for 25 years, since
  51. the days of 110 baud 10 Bytes/sec FSK 103/113's, except for short-lived
  52. oddities like putting 42 byte rlogin/TCP/IP/SLIP packets over 2400
  53. bit/sec modems.  (That particular scenario was the genisis of cslip.)
  54. Compare reading netnews over a modem with looking at the local disk.
  55. The latency that matters is not the time to echo characters, but the
  56. time to respond to a command.
  57.  
  58. Finally, anyone concerned with character echos over telnet who cannot
  59. dump the TCP stuff should should use the Cray inspired telnet line
  60. modes.
  61.  
  62.  
  63. Vernon Schryver,  vjs@sgi.com
  64.