home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.dcom.modems
- Path: sparky!uunet!haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!destroyer!terminator!honey
- From: honey@citi.umich.edu (Peter Honeyman)
- Subject: Re: What's a good 14400 modem?? (Intel?)
- Message-ID: <1992Sep2.014327.13420@terminator.cc.umich.edu>
- Sender: news@terminator.cc.umich.edu (Usenet Owner)
- Reply-To: honey@citi.umich.edu
- Organization: Center for Information Technology Integration, Univ of Michigan
- References: <1992Aug24.143532.8721@lowton.rn.com> <PZR7PB2w165w@infopls.chi.il.us> <1992Sep1.122949.3267@terminator.cc.umich.edu> <pa8bl3o@rhyolite.wpd.sgi.com>
- Date: Wed, 2 Sep 1992 01:43:27 GMT
- Lines: 68
-
- Vernon Schryver writes:
- |> Peter Honeyman writes:
- |> > i have a different ping, so please check me on this. isn't the packet
- |> > size ZZZZ + 20 (ip header) + 8 (echo header) + 1 (slip frame)?
- |>
- |>
- |> As I understand it, that omits the ICMP header but counts the 8-byte
- |> ping date.
-
- icmp is a network layer protocol -- it doesn't use ip. however, the
- icmp header is the same size and shape as an ip header. from rfc 792:
- "ICMP messages are sent using the basic IP header."
-
- |> The 4.3BSD ping does
- |> size ZZZZ + 20 (IP header) + 16 (ICMP header) + (MAC header)
- |>
- |> The date used by ping itself is in the first 8 bytes of the ZZZZ data.
-
- not quite, if i read you right. again, from rfc 792:
-
- Echo or Echo Reply Message
-
- 0 1 2 3
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Code | Checksum |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Identifier | Sequence Number |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Data ...
- +-+-+-+-+-
-
- the time is sent in the data field.
-
- looking at the berkeley ping.c (derived from muuss' original code),
- the size is in addition to the eight byte icmp boilerplate (which
- agrees with my formula above).
-
- |> The MAC header is 1 byte with common SLIP and cslip. I sometimes use a
- |> varient header-compressing SLIP which has a 3-byte header (including
- |> checksum and "session ID").
-
- i think the common bsd slip actually uses a two byte frame in this
- case -- from slstart() in if_sl.c:
-
- /*
- * The extra FRAME_END will start up a new packet, and thus
- * will flush any accumulated garbage. We do this whenever
- * the line may have been idle for some time.
- */
- if (tp->t_outq.c_cc == 0) {
- ++sc->sc_bytessent;
- (void) putc(FRAME_END, &tp->t_outq);
- }
-
- so my earlier caluclation was off by one.
-
- |> So you're right that my calculations are a little off. I don't think
- |> it's worth worrying about. My inferences of when the modems stop being
- |> able to keep up are not accurate to more than 10%, the modems
- |> themselves vary by more than 10% from moment to moment, and I don't
- |> care about any modem where my error of 37 bytes is 10% or more of the
- |> modem's through-put.
-
- if you say so. but i like experimental results to be reproducible by
- others, and hold precision to be a virtue.
-
- peter
-