From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc594.txt | 171 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 171 insertions(+) create mode 100644 doc/rfc/rfc594.txt (limited to 'doc/rfc/rfc594.txt') diff --git a/doc/rfc/rfc594.txt b/doc/rfc/rfc594.txt new file mode 100644 index 0000000..ca15a61 --- /dev/null +++ b/doc/rfc/rfc594.txt @@ -0,0 +1,171 @@ + + + + + + +Network Working Group J. Burchfiel +Request for Comments: 594 BBN-TENEX +NIC: 20616 December 1973 + + + Speedup of Host-IMP Interface + + + +I. Introduction + + In order to make the full performance capabilities of the subnet + available for interprocess communication, the host's IMP interface + and the IMP's host interface should operate at the highest speed + obtainable. + + First, this high throughput will minimize the latency observed when + RFNM's, control messages, and NVT (network virtual terminal) + characters are queued behind full sized messages. A full-sized + message currently ties up a 100 kb interface for almost 100 Msec. + delaying short messages behind it by 100 Msec. Speeding up the host + interface to 300 kilobaud will shrink this latency to 30 Msec. + + Secondly, this high-speed operation minimizes the time that the IMP + buffer and the host core buffer are locked down during message + transfer. (One being emptied, one being filled). Being able to + dispose of buffers far faster means that many fewer of them will + suffice to carry the communications traffic; each buffer can be + reused far more often. + + Third, high-speed operation makes it possible to improve error + control: currently, a destination IMP returns an RFNM after + transmitting the first packet of a multipacket message to the + destination host. If an error occurs during the transmission of the + (up to seven) other packets into the destination host, the source + host will not be informed of the error: it has already been given a + positive message acknowledgement in the RFNM. The alternative, + holding off the RFNM until all packets have been transmitted into the + destination host, would add another 80 Msec. to the round trip + message - RFNM time with the current 100 kilobaud interface. A + higher speed interface will reduce this delayed - RFNM cost to a more + acceptable value, making it practical to eliminate this source of + undetected message transmission errors. + + + + + + + + +Burchfiel [Page 1] + +RFC 594 Speedup of Host-IMP Interface December 1973 + + + Fourth, a high speed interface will permit greater host + communications bandwidth. (Currently limited to 100 kilobaud). This + increase in bandwidth will be essential for communications between + hosts at a "network-structured" site, where different hosts on the + same IMP are specialized to perform different parts of a computation. + + Clearly, any new or retrofitted host interfaces should be very high + speed, and existing host interfaces should be adjusted to operate at + their maximum speed, which is in excess of 300 kilobaud. + +II. Experimental Results + + In support of the above predictions, the BBN TENEX staff performed an + experiment in cooperation with the BBN IMP group to determine how + fast the System A (BBN-TENEX) and System B (BBNB) distant interfaces + would operate. + + Results are as follows: + + The Host-to-IMP connection is synchronized by a two-way handshake + which has an available burst bandwidth of 1 bit/(2225 nsec + 3 + nsec/ft.*ft) For our cable length, this results in a + bandwidth of 310 kilobaud. + + The IMP-to-Host connection is synchronized by a four-way handshake + which has an available burst bandwidth of 1 bit/(1350 nsec + 6 + nsec/ft.*ft.) which results in a bandwidth of 290 + kilobaud for our installation. + + Both System A and System B are now operating at this higher interface + speed. + + Since the propogation delay time through a distant host driver- + receiver pair amounts to 250 nsec, it is expected that local host + interfaces (<30ft) can be operated at speeds substantially faster + than our 300 kilobaud. + + In addition to the above measurements of hardware speed, new results + were obtained in measurements of file transfer performance, i.e. the + CPU time and real time used per megabit of information transmitted + over the network. + + + + + + + + + + +Burchfiel [Page 2] + +RFC 594 Speedup of Host-IMP Interface December 1973 + + + This experiment involved the movement of one-megabit data files to + and from an FTP User process in System B communicating with the FTP + Server Process in System A. The results are summarized in the + followiing table: + + Operation Byte Size Type Bandwidth User CPU seconds/ + megabit + + Get 8 ASCII 47Kbaud 7.9 + Send 8 ASCII 50Kbaud 7.9 + Get 32 LocalByte 43Kbaud 1.80 + Send 32 LocalByte 38Kbaud 1.70 + Get 36 Image 79Kbaud 1.85 + Send 36 Image 85Kbaud .95 + + The 36-bit bandwidth of around 80Kbaud is a great improvement from + the (typically 25Kbaud measured before the speedup of the interface + hardware. The CPU time use has also decreased somewhat from that + reported in RFC #557 by Barry Wessler: this demonstrates continued + improvement of system efficiency between the TENEX version 1.31 and + TENEX version 1.32. + + In conclusion, the BBN-TENEX staff recommends that all host-IMP + interfaces in the network be speeded up to the fastest operation + obtainable. + + + [This RFC was put into machine readable form for entry] + [into the online RFC archives by Alan Whinery, 1/02] + + + + + + + + + + + + + + + + + + + + + + +Burchfiel [Page 3] + -- cgit v1.2.3