As per Relevance of the word experiment, we have this rfc below:
Network Working Group Raj
Request for Comments: 662 Project MAC,
NIC #31386 Nov. 1974
PERFORMANCE IMPROVEMENT IN ARPANET FILE TRANSFERS FROM
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
exists a need to improve the situation. Even within Project MAC there are
who regularly ship files back and forth between Multics and other Project
computer systems. Recently the Cambridge Information Systems Laboratory (CISL
development Multics system was connected to the ARPA Network. This
generated considerable interest among the members of the CSR (Computer
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
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
in the Multics IMP DIM (IMP Device Interface Manager.) With the hope of
a significant performance improvement, we recently changed the IMP DIM buffer
ing strategy. To assess the effects of this change an experiment was
between the service machine (MIT Multics) and the development machine (
Multics.) This memo reports the experiment and its results
Due to reasons that are of historical interest only, the output buffers in
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
length of 1012 bits, which in the Network terminology is a single
message. Due to this buffer size limit, Multics can transmit single
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
number of bits
An old version of the IMP-to-Host protocol requires that a host may not
another message on a network connection unless a Request-for-Next-Message (RFNM
has been received in response to the previous message. Even though
restriction has now been relaxed, the protocol does not specify any way
recover from transmission errors that occur while more than one RFNM is
on the same connection. If the constraint of transmitting only one message at
time is observed there is at least some potential for recovery in case of
error. 8eing reliability conscious, Multics observes the constraint imposed
the old protocol. Following the old protocol introduces delays in
transmission of successive messages on the same link and therefore the
bandwidth per connection is reduced
-1-
At least one method of improving the file transfer bandwidth is obvious
Increasing the size of IMP DIM output buffers will allow us to
significantly larger messagess This will result in fewer RFNMs and delays
improved bandwidth. We have made two assumptions here. The first assumption
that the delay introduced by RFNMs does not increase with the size of
message.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
hold for a heavily loaded network. But for our purpose we may assume it to
essentially correct
There is another advantage in transmitting large messages. For a given
of data, fewer messages will be transmitted, fewer RFNMs will be read,
therefore time spent in the channel driver programs will be reduced. Since
channel sits idle during at least some of this time, the idle time for
channel will be reduced, resulting in improved channel bandwidth
We changed the IMP DIM to implement two kinds of output buffers. One kind
output buffer is short and can hold single packet messages only. The other
of buffer is, naturally enough, large and can hold the largest message
by the network. If the number of bits to be transmitted is low (this is
the situation with interactive users,) a small buffer is chosen and if it
large (for example, file transfers,) a large buffer is chosen
The new IMP DIM was used in an experimental Multics system on the
machine at CISL. The service machine at MIT had the old version. Large
were transmitted from the development system to the service system and the
transfer rate was measured in bits per second ( of real time.) To get
estimate of gain in the performance, files were transmitted from the
s In one situation it may not be possible to transmit large messages.
number of messages and bits that a host can transmit on a particular
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
not transmit very large messages. Since Multics always gives out very
allocations, there should be no problem in Multics to Multics file transfers
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
experiments. The BYTE-SIZE and MODE parameters of the ARPANET File
protocol were set to 36 and "image" mode respectively. This implies that
character conversion was performed in the file transfer. The following
shows the results obtained
Service to Development Development to
(old system) (new system
average file
transfer rate 6,837 27,578
(bits per second
The following information regarding the environment of the experiment
supplied for the sake of completeness. At the time of this experiment,
service system was lightly loaded (the system load varied between 30.0
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
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
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
connected to each other by a 5O kilobits per second line. The results
above show considerable improvement in the performance with the new IMP DIM
Since there is considerable interest in the Multics development community
using the file transfer facility for transmitting Multics System Tapes
the two systems, we are providing here an estimate of time that would be
to transmit the current MST. MST 23.4-0A contains 334,231 words.
multiplied by 36 (the word length in bits) this yields the total number of
to be approximately 12.5 million. Assuming a file transfer rate of 27,500
per second, it will take approximately 7 minutes and 30 seconds to transmit
system 23.4-0A
In the experiment outlined above, there was only one file being transferred
any given tine between the two systems. We conducted another experiment to
an estimate of performance in the situation of multiple file transfers
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
consoles. Because these file-transfers were started manually, we could
obtain perfect simultaneity and results obtained for the total bandwidth
essentially approximate. For two simultaneous file transfers the total bit
was approximately 40,000 bits per second and bit rate for each file transfer
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
individual transfers was approximately 13,500 bits per second
-3-
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
