RFC 557 UNKNOWN MEASUREMENT · PERFORMANCE

REVELATIONS IN NETWORK HOST MEASUREMENTS

A follow-up report on measurements of TENEX network-transfer performance.

On rfc-editor.org ↗
PUBLISHED
August 1973
AUTHORS
B.D. Wessler
STREAM
Legacy
CPU TIME AFTER CHANGES
19 seconds per megabit
CPU TIME BEFORE CHANGES
75–85 seconds per megabit
REPORTED IMPROVEMENT
Approximately 400%
DOI
10.17487/RFC0557

RFC text

Original text · RFC Editor View on rfc-editor.org ↗
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 ]

ISO Plain Language

On this page
PROBLEMThe author says RFC 392's measurements were read as criticism of the network, although its purpose was to identify opportunities to improve it. Few other measurement results had been reported.
MECHANISMThe RFC shares BBN's updated TENEX measurements after changes to the RJS program, input/output code and network monitor code.
REPORTED RESULTThe reported CPU time fell from 75–85 seconds per megabit to 19 seconds per megabit. The author asks other systems to measure and share their transfer results.

§1Why the Author Revisits RFC 392

RFC 392 described a problem encountered while using the ARPANET at Utah. Its author says the goal was to point out a place for improvement, but readers seemed to treat it as a claim that the network was poor. RFC 557 also renews the request for measurements on computers and operating systems beyond TENEX.

The earlier report was meant to help improve network use, not simply condemn the network. The author asks people using other computers to measure their own systems too.

§2BBN's Updated TENEX Measurements

BBN updated Don Allen's RJS program to use recent TENEX changes, improved code near the input/output calls and used faster network monitor code. The resulting measurement was about 19 seconds of CPU time per megabit, compared with 75–85 seconds before. The RFC describes this as an approximately 400% improvement.

Of the 19 seconds, 13 were spent in RJS and 6 in TENEX network output. Separate BBN FTP measurements required 8.2 CPU seconds per megabit for 8-bit-byte transfers. The RFC says using 32- or 36-bit bytes improved that figure by a factor of four.

Changes to TENEX and its transfer programs reduced the measured CPU time per megabit. The report separates time spent in the RJS program from time spent in TENEX network output.

§3The Call for More Measurements

The author says the results suggest the network, including the host cost, can be effective. Poor results may follow when monitor and user code are not carefully implemented. The report does not investigate where the remaining 13 seconds in RJS were spent, because RJS was expected to be replaced by an RJE protocol using FTP for transfer.

The author asks sites to measure network transfers and send results, including results they may find embarrassing.

The report says implementation choices affect measured transfer cost, and leaves part of the RJS cost unexplained. It asks other sites to measure their transfers and share what they find.

§4References