    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 connection. If the constraint of transmitting only one message at a
    time is observed there is at least some potential for recovery in case of an
    error. 8eing reliability conscious, Multics observes the constraint imposed by
    the old protocol. Following the old protocol introduces delays in the
    transmission of successive messages on the same link and therefore the overall
    bandwidth per connection is reduced.

                                          -1-

    SOLUTION

    At least one method of improving the file transfer bandwidth is obvious.
    Increasing the size of IMP DIM output buffers will allow us to transmit
    significantly larger messages<s1>s This will result in fewer RFNMs and delays and
    improved bandwidth. We have made two assumptions here. The first assumption is
    that the delay introduced by RFNMs does not increase with the size of the
    message.<s2>s Our experience with the network tends to support this assumption.
    The second assumption is that actual time taken to transmit a message increases,
    at best, linearly with the size of message. This second assumption does not
    hold for a heavily loaded network. But for our purpose we may assume it to be
    essentially correct.

    There is another advantage in transmitting large messages. For a given amount
    of data, fewer messages will be transmitted, fewer RFNMs will be read, and
    therefore time spent in the channel driver programs will be reduced. Since the
    channel sits idle during at least some of this time, the idle time for the
    channel will be reduced, resulting in improved channel bandwidth.

    EXPERIMENT

    We changed the IMP DIM to implement two kinds of output buffers. One kind of
    output buffer is short and can hold single packet messages only. The other kind
    of buffer is, naturally enough, large and can hold the largest message allowed
    by the network. If the number of bits to be transmitted is low (this is mostly
    the situation with interactive users,) a small buffer is chosen and if it is
    large (for example, file transfers,) a large buffer is chosen.

    The new IMP DIM was used in an experimental Multics system on the development
    machine at CISL. The service machine at MIT had the old version. Large files
    were transmitted from the development system to the service system and the file
    transfer rate was measured in bits per second ( of real time.) To get an
    estimate of gain in the performance, files were transmitted from the service

    <s1>s In one situation it may not be possible to transmit large messages. The
    number of messages and bits that a host can transmit on a particular connection
    must not exceed the message and bit allocation provided by the receiving host.
    If a receiving host gives very small bit allocation, then the sending host can
    not transmit very large messages. Since Multics always gives out very large
    allocations, there should be no problem in Multics to Multics file transfers.

    <s2>s It should be noted that the size of RFNM is fixed and does not change
    with the size of message.

                                          -2-

    system to the development system and the old file transfer rate was measured.
    The same file, approximately 2.5 million bits long, was used in both
    experiments. The BYTE-SIZE and MODE parameters of the ARPANET File Transfer
    protocol were set to 36 and "image" mode respectively. This implies that no
    character conversion was performed in the file transfer. The following table
    shows the results obtained:

    Service to Development Development to Service
    (old system) (new system)

    average file-
    transfer rate 6,837 27,578
    (bits per second)

    The following information regarding the environment of the experiment is
    supplied for the sake of completeness. At the time of this experiment, the
    service system was lightly loaded (the system load varied between 30.0 and
    35.0). The service system configuration was 2 cpu's and 384 K primary memory.
    The development machine configuration was 1 cpu and 256 K of primary memory.
    The development system load was limited to the file transfer processes and the
    initializer process. The MIT Multics is connected to the IMP number 44 (port 0)
    by a rather short cable (approximately 100 feet long.) The CISL Multics is
    connected to the IMP number 6 (port 0) by an approximately l5OO feet long cable.
    8oth IMPs are in close physical proximity (approximately 2000 feet,) and are
    connected to each other by a 5O kilobits per second line. The results given
    above show considerable improvement in the performance with the new IMP DIM.

    Since there is considerable interest in the Multics development community in
    using the file transfer facility for transmitting Multics System Tapes between
    the two systems, we are providing here an estimate of time that would be taken
    to transmit the current MST. MST 23.4-0A contains 334,231 words. When
    multiplied by 36 (the word length in bits) this yields the total number of bits
    to be approximately 12.5 million. Assuming a file transfer rate of 27,500 bits
    per second, it will take approximately 7 minutes and 30 seconds to transmit the
    system 23.4-0A.

    In the experiment outlined above, there was only one file being transferred at
    any given tine between the two systems. We conducted another experiment to get
    an estimate of performance in the situation of multiple file transfers occurring
    simultaneously. This experiment consisted of first two, and then three,
    simultaneous file-transfers from the development system to the service system.
    These file transfers were started by different processes logged in from separate
    consoles. Because these file-transfers were started manually, we could not
    obtain perfect simultaneity and results obtained for the total bandwidth are
    essentially approximate. For two simultaneous file transfers the total bit rate
    was approximately 40,000 bits per second and bit rate for each file transfer was
    approximately 20,000 bits per second. For three simultaneous file transfers,
    total bit rate remained at approximately 40,000 bits per second and bit rate for
    individual transfers was approximately 13,500 bits per second.

                                          -3-