home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!olivea!decwrl!sgi!rhyolite!vjs
- From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
- Newsgroups: comp.dcom.modems
- Subject: Re: What's a good 14400 modem?? (Intel?)
- Message-ID: <pa8bl3o@rhyolite.wpd.sgi.com>
- Date: 1 Sep 92 14:21:29 GMT
- References: <1992Aug24.143532.8721@lowton.rn.com> <PZR7PB2w165w@infopls.chi.il.us> <1992Sep1.122949.3267@terminator.cc.umich.edu>
- Organization: Silicon Graphics, Inc. Mountain View, CA
- Lines: 31
-
- In article <1992Sep1.122949.3267@terminator.cc.umich.edu>, honey@citi.umich.edu (Peter Honeyman) writes:
- > Vernon Schryver writes:
- > |> My "throughput test" consist of `ping -c ZZZZ remote`, increasing the
- > |> value of ZZZZ until the line stops keeping up, as observed for 20 to 60
- > |> seconds. That forces the modems to process ZZZZ*2 bytes.
- >
- > 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.
-
- 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.
-
- 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").
-
- 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.
-
-
- Vernon Schryver, vjs@sgi.com
-