RFC 392 (rfc392) - Page 2 of 6

Measurement of host costs for transmitting network data

RFC 392        Measurement for Transmitting Network Data  September 1972


   felt a re-write of the transmitting and receiving portions of the
   program was needed.  In order that the program receive the best
   service from the system, these portions optimized so that they each
   occupied a little over half of a page.  As we now had so few pages in
   core at any one time, the TENEX scheduler could give the program
   preference over larger working set jobs. (As an aside, because of our
   limited core, we have written a small (one and one half pages) editor
   in order to provide an interactive text editing service.)

   The mechanism to access the network under TENEX is file oriented.
   This means byte-in (BIN) and byte-out (BOUT) must be used to
   communicate with another host.  The basic timing of these two
   instructions (in the fast mode) is 120 us per byte to get the data
   onto or off of the network[3].  A distinction was made because the
   TENEX monitor must do some "bit shuffling" to ready the users bytes
   to be transmitted or it must put the network messages into some form
   that is convenient for the user.  This is the "slow bin, bout" and
   occurs once per message.  If the users bytes are 36 bits long then it
   will take an average of 500 us per message.  If the bytes have to be
   unpacked from the message to be usable, then it may take up to a
   milli-second depending on the size of the message[3].

II.  Measurements and Results

   We found by timing various portions of the program that the RJS
   program was using 600 to 700 us per bit byte or between 75 and 85
   micro-seconds of chargeable cpu time per bit. (See tables 1 and 2 for
   actual results).  A short discussion of how these figures were
   obtained is now in order.  NOTE! We have not been trying to measure
   network transmission rates; Rather, how much it costs us to take a
   program (data) from our disk and send it to another host to be
   executed (processed).

   Column 1 is the clock time (real-time) from when the first byte was
   brought in from the disk until the last byte had gone onto the
   network. (Or from the time we received the first byte from the
   network until the disk file was closed).

   Column 2 is computed in the same manner as column 1 except that it is
   the chargeable runtime for the process.

   Column 3 is the actual number of bytes that went onto or came from
   the network.  The letter that follows this column indicates the
   direction.  E.G. s for sending to UCLA, r for receiving from UCLA).

   Column 4 was calculated by the following formula:
   Bits per second = (real-time)/((number of bytes)*8)




Hicks & Wessler