REVELATIONS IN NETWORK HOST MEASUREMENTS
Follow-up on network host performance measurements
Wessler, B.D., "REVELATIONS IN NETWORK HOST MEASUREMENTS", RFC 557, DOI 10.17487/RFC0557, August 1973, <https://www.rfc-editor.org/info/rfc557>.
@misc{rfc557,
series = {Request for Comments},
number = 557,
howpublished = {RFC 557},
publisher = {RFC Editor},
doi = {10.17487/RFC0557},
url = {https://www.rfc-editor.org/info/rfc557},
author = {B.D. Wessler},
title = {{REVELATIONS IN NETWORK HOST MEASUREMENTS}},
pagetotal = 2,
year = 1973,
month = aug,
} RFC text
Network Working Group B. Wessler Request for Comments: 557 Telenet Communications NIC: 18457 30 August 1973 References: RFC 392, 415 REVELATIONS IN NETWORK HOST MEASUREMENTS The purpose of RFC 392 was to identify a problem we had encountered in using the ARPANET at Utah. The primary thrust of the paper was supposed to be: "Here is a place to make the Network better" rather than: "Look, isn't the Network terrible." The accepted use of 392 seems to be the latter rather than the former. A second purpose of 392 was to stimulate the undertaking of measurement experiments on other computers and operating systems in addition to TENEX. Very little in the way of measurements has been reported (other than Hal Murray's RFC 415 measuring TENEX). Since the Publication of RFC 392, BBN has done a considerable amount of work to improve Host-Net performance on TENEX. They reported new measurement results in their April 1973 Quarterly Progress Report No. 10. I feel it is important to circulate those results to the RFC community. Don Allen at BBN borrowed Greg Hicks' RJS program and 1) updated it to take advantage of recent changes in TENEX, 2) improved the code near the input/output JSYs and 3) used considerably faster network monitor code. The result was approximately 400% improvement from 75-85 seconds of CPU time per megabit (~$10) to 19 seconds per megabit (~$2.50). Of the 19 seconds, 13 were spent in the RJS program and 6 in TENEX network output. The six seconds seem to relate very well to BBN FTP requirements where 8.2 cpu seconds per megabit were required (~$1.08) for 8 bit byte transfers. (Going to 32 or 36 bit bytes improves this figure by a factor of 4, resulting in a cost of $.33 per megabit.) Of the 13 seconds left in RJS no attempt was made to improve or even discover where the time was spent. This extra effort was not expended because RJS is soon to be replaced by the RJE protocol which uses FTP as its transfer mechanism. In summary, I believe that the original RFC #392 and the recent BBN results show that the Network including the Host cost, is intrinsically effective. If care is not taken in monitor and user code the system may not look very attractive. I hope everyone now goes out and measures how good (or bad) they are doing vis a vis network transfers. Please send me the results personally if they are too embarrassing to distribute via RFC. It would be nice to hear from all systems. All the data is courtesy of Don Allen and Jerry Burchfiel at BNN. [ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Lorrie Shiota ]
AI ELI5
On this page
§1Clarifying the Original Measurement Report
RFC 392 published network performance measurements from the University of Utah that found poor transfer speeds: 75 to 85 seconds of CPU time per megabit (approximately ten dollars per megabit). The RFC author clarifies that the intent was not to criticize the network as broken, but to identify areas for improvement. However, the message was largely received as criticism rather than a call for optimization work.
An earlier report showed bad network numbers and everyone thought that meant the network was bad. The author wanted to say the network could be better, not that it was broken.
§2Results After Optimization
BBN subsequently improved the TENEX host implementation significantly. By updating code to take advantage of recent TENEX changes, improving input/output handling, and using faster network monitor code, they achieved approximately 400 percent performance improvement: from 75 to 85 seconds per megabit down to 19 seconds per megabit (about two dollars and fifty cents per megabit). Of these 19 seconds, 13 seconds were spent in the application program (RJS) and 6 in the TENEX operating system. The 6 seconds in TENEX aligns well with separate FTP measurements at 8.2 CPU seconds per megabit, and improves further to 0.33 cents per megabit when using 32 or 36-bit bytes instead of 8-bit bytes.
The team rewrote the software and made it four times faster. Some of the slowness was the application program, some was the operating system, and it got even better when using bigger data chunks.
§3The Network Is Efficient
The results demonstrate that the ARPANET and its host software, including the host cost, are intrinsically efficient. Poor measured performance stems from careless implementation rather than fundamental network inefficiency. The author urges all sites to measure their own network transfer performance and share results, whether favorable or not. This benchmarking culture would help identify where optimization effort is needed and prevent unsupported claims about network quality.
The network is actually fast. If transfers are slow, it means your code is slow. Everyone should measure their own results so we know where to fix things.