home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / dcom / modems / 12850 < prev    next >
Encoding:
Text File  |  1992-09-01  |  3.2 KB  |  81 lines

  1. Newsgroups: comp.dcom.modems
  2. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!destroyer!terminator!honey
  3. From: honey@citi.umich.edu (Peter Honeyman)
  4. Subject: Re: What's a good 14400 modem?? (Intel?)
  5. Message-ID: <1992Sep2.014327.13420@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: <1992Aug24.143532.8721@lowton.rn.com> <PZR7PB2w165w@infopls.chi.il.us> <1992Sep1.122949.3267@terminator.cc.umich.edu> <pa8bl3o@rhyolite.wpd.sgi.com>
  10. Date: Wed, 2 Sep 1992 01:43:27 GMT
  11. Lines: 68
  12.  
  13. Vernon Schryver writes:
  14. |> Peter Honeyman writes:
  15. |> > i have a different ping, so please check me on this.  isn't the packet
  16. |> > size ZZZZ + 20 (ip header) + 8 (echo header) + 1 (slip frame)?
  17. |> 
  18. |> 
  19. |> As I understand it, that omits the ICMP header but counts the 8-byte
  20. |> ping date.
  21.  
  22. icmp is a network layer protocol -- it doesn't use ip.  however, the
  23. icmp header is the same size and shape as an ip header.  from rfc 792:
  24. "ICMP messages are sent using the basic IP header."
  25.  
  26. |> The 4.3BSD ping does
  27. |>     size ZZZZ + 20 (IP header) + 16 (ICMP header) + (MAC header)
  28. |> 
  29. |> The date used by ping itself is in the first 8 bytes of the ZZZZ data.
  30.  
  31. not quite, if i read you right.  again, from rfc 792:
  32.  
  33. Echo or Echo Reply Message
  34.  
  35.    0                   1                   2                   3
  36.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  37.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  38.    |     Type      |     Code      |          Checksum             |
  39.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  40.    |           Identifier          |        Sequence Number        |
  41.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  42.    |     Data ...
  43.    +-+-+-+-+-
  44.  
  45. the time is sent in the data field.
  46.  
  47. looking at the berkeley ping.c (derived from muuss' original code),
  48. the size is in addition to the eight byte icmp boilerplate (which
  49. agrees with my formula above).
  50.  
  51. |> The MAC header is 1 byte with common SLIP and cslip.  I sometimes use a
  52. |> varient header-compressing SLIP which has a 3-byte header (including
  53. |> checksum and "session ID").
  54.  
  55. i think the common bsd slip actually uses a two byte frame in this
  56. case -- from slstart() in if_sl.c:
  57.  
  58.         /*
  59.          * The extra FRAME_END will start up a new packet, and thus
  60.          * will flush any accumulated garbage.  We do this whenever
  61.          * the line may have been idle for some time.
  62.          */
  63.         if (tp->t_outq.c_cc == 0) {
  64.                 ++sc->sc_bytessent;
  65.                 (void) putc(FRAME_END, &tp->t_outq);
  66.         }
  67.  
  68. so my earlier caluclation was off by one.
  69.  
  70. |> So you're right that my calculations are a little off.  I don't think
  71. |> it's worth worrying about.  My inferences of when the modems stop being
  72. |> able to keep up are not accurate to more than 10%, the modems
  73. |> themselves vary by more than 10% from moment to moment, and I don't
  74. |> care about any modem where my error of 37 bytes is 10% or more of the
  75. |> modem's through-put.
  76.  
  77. if you say so.  but i like experimental results to be reproducible by
  78. others, and hold precision to be a virtue.
  79.  
  80.     peter
  81.