Network activity report: UCSB Rand
A 1971 field report on using UCSB's remote job service from Rand, with timings and a few failures.
Harslem, E., Heafner, J.F., and J.E. White, "Network activity report: UCSB Rand", RFC 113, DOI 10.17487/RFC0113, April 1971, <https://www.rfc-editor.org/info/rfc113>.
@misc{rfc113,
series = {Request for Comments},
number = 113,
howpublished = {RFC 113},
publisher = {RFC Editor},
doi = {10.17487/RFC0113},
url = {https://www.rfc-editor.org/info/rfc113},
author = {E. Harslem and J.F. Heafner and J.E. White},
title = {{Network activity report: UCSB Rand}},
pagetotal = 2,
year = 1971,
month = apr,
} RFC text
Network Working Group 5 April 1971
Request for Comments: 113 E. F. Harslem
NIC 5820 J. F. Heafner
J. E. White
NETWORK ACTIVITY REPORT: UCSB <- -> RAND
UCSB RJE/RJOR
The UCSB Remote Job Entry (RJE) and Remote Job Out- put
Retrieval (RJOR) Systems described in NWG/RFC #105 have been used and
validated from Rand. The facility is now being used on a limited
basis as a production tool by another research group at Rand.
Access to the UCSB facility from Rand is through the Network
Service Program (NSP). This program is driven by Rand Video-Graphic
consoles and allows a console user access to both local file storage
(at Rand) and to the Network. A small module (UCSBMGR) was added to
NSP to handle the UCSB RJE and RJOR protocols and data formats.
In exercising the RJE/RJOR facility over the past two months,
typical job sizes included input decks of 800 to 2800 80-character
card images and output files of about 30 pages of printer linstings.
NETWORK OBSERVATIONS
In sending files to UCSB we did a timing study over several
transmissions of the above mentioned 2800 record file. On the average
this file was transmitted at a rate of 250 80-character cards per
minute. (Each 80-character card was a separte Network message.) This
is, of course, much less than the advertised 30 kilobit rate; however,
it should be remembered that the path from Rand to UCSB is through at
least one intermediate IMP. On the other hand, the processes at each
end of the connection were running at maximum priority with very small
loads on either machine. An obvious area for speed-up would be the
blocking of card images for network transmission.
In the course of the last two months of networking, we have
noticed approximately five serious failures in transmitted messages.
In two instances, the RFNM on the control link from UCSB to Rand was
lost. Its loss was not reported via a type 9 IMP-to-Host message as
would be expected. We have not been able to cause the problem to
occur; hence we are unable to ascertain whether it is an IMP problem
or a problem with the UCSB Host Interface.
The other three errors were related to the garbling of a data
message between the Rand NSP and UCSB RJE. In all three instances, it
was the second card image trans- ferred to RJE. We were unable to
cause this problem at will; hence have been unable to track it down.
Unfortun- ately the HASP system at USCB merely ignored this image
rather than printing it so we are not aware of the nature nor source
of the garbling. It could be anywhere from the disk file storage at
Rand on down the line. This problem was observed sporadically in our
early trans- missions to UCSB and has disappeared. We feel relatively
confident, however, that our Host software on either end was not at
fault.
Lest these last two figures seem too terrifying, it should be
noted that we have run over 100 jobs at UCSB from Rand, each job
consisting of many Network transmissions.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Simone Demmel 4/97 ]
AI ELI5
On this page
§1UCSB RJE/RJOR From Rand
The UCSB Remote Job Entry (RJE) and Remote Job Output Retrieval (RJOR) systems, described in RFC 105, were used and validated from Rand. Another research group at Rand was by then using the facility on a limited basis as a production tool.
Rand reached UCSB through its Network Service Program (NSP), driven by Rand Video-Graphic consoles. A small module, UCSBMGR, was added to NSP to handle the RJE and RJOR protocols and data formats. Typical jobs were input decks of 800 to 2800 80-character card images and output files of about 30 pages of printer listings.
Rand's computer learned how to send big stacks of work to a computer at UCSB and get the printed answers back.
§2Speed of Transfer
A timing study of a 2800 record file showed an average rate of 250 80-character cards per minute, with each card sent as a separate network message. The authors note this is much less than the advertised 30 kilobit rate, although the path from Rand to UCSB passes through at least one intermediate IMP.
The processes at each end ran at maximum priority with very small loads, so the slowness was not due to busy machines. The authors suggest blocking card images together for transmission as an obvious area for speed-up.
Sending each card as its own little package was slow, like mailing every page of a book in its own envelope. Putting pages together would be faster.
§3Failures Observed
Over about two months the authors saw approximately five serious failures. In two cases the RFNM on the control link from UCSB to Rand was lost, and the loss was not reported by a type 9 IMP-to-Host message as expected. They could not reproduce it, so they could not tell whether the IMP or the UCSB host interface was at fault.
The other three were garbled data messages, each time the second card image sent to RJE. The HASP system at UCSB ignored the image instead of printing it, so the cause stayed unknown. This problem appeared in early transmissions and then disappeared. The authors were fairly confident their own host software was not at fault, and note that over 100 jobs had been run at UCSB from Rand.
A few times a message got lost or scrambled and nobody could work out why. But over a hundred jobs went through fine.