Data transfer rates (Rand/UCLA)
Measured file-transfer rates between Rand and UCLA, with a note on blocking.
Heafner, J.F. and E. Harslem, "Data transfer rates (Rand/UCLA)", RFC 227, DOI 10.17487/RFC0227, September 1971, <https://www.rfc-editor.org/info/rfc227>.
@misc{rfc227,
series = {Request for Comments},
number = 227,
howpublished = {RFC 227},
publisher = {RFC Editor},
doi = {10.17487/RFC0227},
url = {https://www.rfc-editor.org/info/rfc227},
author = {J.F. Heafner and E. Harslem},
title = {{Data transfer rates (Rand/UCLA)}},
pagetotal = 2,
year = 1971,
month = sep,
} RFC text
Network Working Group J. Heafner Request for Comments: 227 E. Harslem NIC: 7631 September 17, 1971 Updates: RFC 113 DATA TRANSFER RATES (RAND/UCLA) The attached memo indicates data rates typical of our use of RJS at UCLA CCN. Earlier timing tests (similar but more detailed) with UCSB showed that most of the time was lost because of: (1) channel contention with our disk drive access; (2) our NCP runs at a higher priority than batch jobs but lower than text editing and interactive graphics; (3) OS interrupt handling is very slow on both ends; (4) spooling time of the remote system. MEMORANDUM TO: John Heafner FROM: Bob Hoffman COPIES: Bob Mobley, Herb Shukiar Here are some of the transmission rates I have noted over the network between Rand and UCLA. These were all taken at night when little else was happening on our 65. SEND TO UCLA # Cards Blocksize (bytes) Time (secs) Rate (bits/secs) 642 80 50 8218 375 80 30 8000 509 800 20 16288 RECEIVE FROM UCLA For all figures below, the receiving file has blocksize of 1330 bytes, and each line is assumed to contain 100 bytes. This last assumption is fairly accurate, since most of the lines were from PL/I for which this is a very good number. Thus, for each rate, the number of bytes is the # Lines * 100. # Lines Time (secs) Rate (bits/secs) 4900 200 19600 872 47 14843 3900 185 16865 As you can see from the send figures, blocking makes about a 2:1 difference. Memory also recalls a 2 or 3 to 1 advantage for blocking on receive when we were getting unblocked files from UCSB. REH:gb [This RFC was put into machine readable form for entry] [into the online RFC archives by Kelly Tardif, Viag�nie 10/99]
ISO Plain Language
On this page
§1Reported Causes of Delay
The opening note says earlier, more detailed tests with UCSB lost time to disk-channel contention, NCP priority below text editing and interactive graphics, slow operating-system interrupt handling at both ends, and remote spooling time.
The attached measurements were taken at night, when little else was happening on the Rand system.
Earlier tests found that busy disks, program scheduling, interrupt handling and remote spooling could all slow transfers. The measurements here were taken at night to reduce other activity.
§2Transfer Measurements
For sends to UCLA, the memo records three tests: 642 cards of 80 bytes in 50 seconds at 8218 bits per second; 375 cards of 80 bytes in 30 seconds at 8000 bits per second; and 509 cards with an 800-byte block size in 20 seconds at 16288 bits per second.
For receives, the file used a 1330-byte block size, and each line was treated as 100 bytes. The reported rates were 19600, 14843 and 16865 bits per second for the three tests.
The memo lists the amount sent or received, the time it took and the resulting rate. For the receive figures, it assumes each line contains 100 bytes.
§3Effect of Blocking
Based on the send figures, the authors say blocking makes about a 2:1 difference. The memo also recalls a two- or three-to-one advantage for blocking on receive when unblocked files came from UCSB.
The unit metadata says this RFC updates RFC 113.
The authors report that sending data in blocks made a substantial difference in their tests. They also recall a similar advantage for receiving blocked data.