RFC 392 (rfc392) - Page 2 of 6
Measurement of host costs for transmitting network data
Alternative Format: Original Text Document
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
