Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Performance improvement in ARPANET file transfers from Multics (RFC0662)

IP.com Disclosure Number: IPCOM000003720D
Original Publication Date: 1974-Nov-26
Included in the Prior Art Database: 2000-Sep-13
Document File: 3 page(s) / 9K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R. Kanodia: AUTHOR

Abstract

With the growth of Multics usage in the ARPA Network community, users often need to transfer large amounts of data from Multics to other systems. However, Multics performance in this area has been less than optimal and there clearly exists a need to improve the situation. Even within Project MAC there are users who regularly ship files back and forth between Multics and other Project MAC computer systems. Recently the Cambridge Information Systems Laboratory (CISL) development Multics system was connected to the ARPA Network. This has generated considerable interest among the members of the CSR (Computer Systems Research) and CISL groups in using the Multics file transfer facility for tran- smission of Multics system tapes (MST) from one Multics system to the other. At currently realizable data transfer rates, transmission of a typical MST, (approximately 12 million bits), takes about half an hour. The usefulness of the present file transfer system is severely limited by its low bandwidth.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 31% of the total text.

Network Working Group Raj Kanodia

Request for Comments: 662 Project MAC, MIT

NIC #31386 Nov. 1974

PERFORMANCE IMPROVEMENT IN ARPANET FILE TRANSFERS FROM MULTICS

With the growth of Multics usage in the ARPA Network community, users often

need to transfer large amounts of data from Multics to other systems. However,

Multics performance in this area has been less than optimal and there clearly

exists a need to improve the situation. Even within Project MAC there are users

who regularly ship files back and forth between Multics and other Project MAC

computer systems. Recently the Cambridge Information Systems Laboratory (CISL)

development Multics system was connected to the ARPA Network. This has

generated considerable interest among the members of the CSR (Computer Systems

Research) and CISL groups in using the Multics file transfer facility for tran-

smission of Multics system tapes (MST) from one Multics system to the other.

At currently realizable data transfer rates, transmission of a typical MST,

(approximately 12 million bits), takes about half an hour. The usefulness of

the present file transfer system is severely limited by its low bandwidth.

One of the reasons for such a poor performance is the output buffering strategy

in the Multics IMP DIM (IMP Device Interface Manager.) With the hope of making

a significant performance improvement, we recently changed the IMP DIM buffer-

ing strategy. To assess the effects of this change an experiment was conducted

between the service machine (MIT Multics) and the development machine (CISL

Multics.) This memo reports the experiment and its results.

PROBLEM

Due to reasons that are of historical interest only, the output buffers in the

IMP DIM have been very small; each buffer can accommodate up to 940 bits only.

With the addition of a 72 bit long header, the resulting message has a maximum

length of 1012 bits, which in the Network terminology is a single packet

message. Due to this buffer size limit, Multics can transmit single packet

messages only, even though the network can accept up to 8096 bit long messages.

This results in increased overhead in the set up time for transmission of large

number of bits.

An old version of the IMP-to-Host protocol requires that a host may not transmit

another message on a network connection unless a Request-for-Next-Message (RFNM)

has been received in response to the previous message. Even though this

restriction has now been relaxed, the protocol does not specify any way to

recover from transmission errors that occur while more than one RFNM is pending

on the same...