home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / dcom / modems / 12851 < prev    next >
Encoding:
Text File  |  1992-09-01  |  3.3 KB  |  79 lines
  1. Newsgroups: comp.dcom.modems
  2. Path: sparky!uunet!sun-barr!ames!sgi!rhyolite!vjs
  3. From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
  4. Subject: Re: What's a good 14400 modem?? (Intel?)
  5. Message-ID: <pavp9v8@rhyolite.wpd.sgi.com>
  6. Organization: Silicon Graphics, Inc.  Mountain View, CA
  7. References: <1992Aug24.143532.8721@lowton.rn.com> <PZR7PB2w165w@infopls.chi.il.us> <1992Sep2.014327.13420@terminator.cc.umich.edu>
  8. Date: Wed, 2 Sep 1992 03:41:06 GMT
  9. Lines: 68
  10.  
  11. In article <1992Sep2.014327.13420@terminator.cc.umich.edu>, honey@citi.umich.edu (Peter Honeyman) writes:
  12. > ...
  13. > i think the common bsd slip actually uses a two byte frame in this
  14. > case -- from slstart() in if_sl.c:
  15. > 
  16. >         /*
  17. >          * The extra FRAME_END will start up a new packet, and thus
  18. >          * will flush any accumulated garbage.  We do this whenever
  19. >          * the line may have been idle for some time.
  20. >          */
  21. >         if (tp->t_outq.c_cc == 0) {
  22. >                 ++sc->sc_bytessent;
  23. >                 (void) putc(FRAME_END, &tp->t_outq);
  24. >         }
  25. > 
  26. > so my earlier caluclation was off by one.
  27.  
  28.  
  29. No, as the comment says, the extra delimiter should only be emitted
  30. when the line was previously more or less idle.
  31. Consecutive SLIP frames should have 1-byte each of SLIP "header".
  32.  
  33. This is what a netsnoop on `ping -s 10` on a SLIP line terminating
  34. about 16 inches from my right knee says:
  35.  
  36. 0002:   len   38   time 21:28:35.799
  37.     ip:     v 4       hl 5      tos 0     len 38    id 19099  off 0
  38.             ttl 255   p icmp    sum 0x65d0
  39.             src rhyolite.wpd.sgi.com      dst dataserv.denver.sgi.com  
  40.     icmp:   type ECHO           code 0    cksum 0x1c66        id 16127
  41.             seq 11   
  42.     00028:                                      2a a4 34 e3              *.4.
  43.     00032:  00 0c 34 f3 08 09                                ..4...
  44.  
  45. 0003:   len   38   time 21:28:35.929
  46.     ip:     v 4       hl 5      tos 0     len 38    id 24932  off 0
  47.             ttl 255   p icmp    sum 0x4f07
  48.             src dataserv.denver.sgi.com   dst rhyolite.wpd.sgi.com     
  49.     icmp:   type ECHOREPLY      code 0    cksum 0x2466        id 16127
  50.             seq 11   
  51.     00028:                                      2a a4 34 e3              *.4.
  52.     00032:  00 0c 34 f3 08 09                                ..4...
  53.  
  54. The total packet length is 36 bytes excluding SLIP header.
  55. However you want to divide it, that's
  56.   (28 bytes of IP stuff) + (1 byte for SLIP) + (ping command line value)
  57.  
  58.  
  59. > |> So you're right that my calculations are a little off.  I don't think
  60. > |> it's worth worrying about.  My inferences of when the modems stop being
  61. > |> able to keep up are not accurate to more than 10%, the modems
  62. > |> themselves vary by more than 10% from moment to moment, and I don't
  63. > |> care about any modem where my error of 37 bytes is 10% or more of the
  64. > |> modem's through-put.
  65. > 
  66. > if you say so.  but i like experimental results to be reproducible by
  67. > others, and hold precision to be a virtue.
  68.  
  69.  
  70. Reproducibility is the main reason I report so called "throughput" as I
  71. do.  The numbers are straight from the ping command line.  They do not
  72. require any problematical adjustments.  As I noted recently, I even
  73. ignore the fact that the real throughput value is in some sense twice
  74. the command line value because data is flowing at that rate in both
  75. directions.
  76.  
  77.  
  78. Vernon Schryver,  vjs@sgi.com
  79.