RFC 113

Network activity report: UCSB Rand

πŸ“… published April 1971, from ietf

πŸŽ€ NETWORK ACTIVITY REPORT: UCSB <- -> RAND πŸŽ€

Network Working Group πŸ’– 5 April 1971 Request for Comments: 113 ✨ NIC 5820

Written by E. F. Harslem, J. F. Heafner and J. E. White 🫢. The header doesn't list a category, an obsoletes line or an updates line, so there's nothing to report on those 🧚.

UCSB RJE/RJOR πŸ’…

okay so the UCSB Remote Job Entry (RJE) and Remote Job Output Retrieval (RJOR) Systems from NWG/RFC #105 have been used and validated from Rand πŸ¦‹. The facility is now a production tool on a limited basis for another research group at Rand, and that's giving real-world proof πŸ”₯.

Access to the UCSB facility from Rand goes through the Network Service Program (NSP) 🌈. NSP is driven by Rand Video-Graphic consoles, so a console user can reach both local file storage (at Rand) and 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 were input decks of 800 to 2800 80-character card images and output files of about 30 pages of printer listings πŸ“„βœ¨.

NETWORK OBSERVATIONS πŸ‘‘

ngl this section is where it gets juicy 😭. When we sent files to UCSB, we ran a timing study over several transmissions of the 2800 record file mentioned above. On average, that file went through at a rate of 250 80-character cards per minute 🌸. (Each 80-character card was its own separate Network message.) Obviously that's way less than the advertised 30 kilobit rate πŸ’€. But remember that the path from Rand to UCSB runs through at least one intermediate IMP, so that's part of it 🫢. 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 blocking the card images before sending them over the network πŸš€.

In the last two months of networking, we noticed about five serious failures in transmitted messages 😳. Twice, the RFNM on the control link from UCSB to Rand was lost. That loss wasn't reported with a type 9 IMP-to-Host message, which is what we'd have expected πŸ™ˆ. We haven't been able to make the problem happen on purpose, so we can't tell whether it's an IMP problem or a problem with the UCSB Host Interface πŸ•΅οΈβ€β™€οΈ.

The other three errors were garbled data messages between the Rand NSP and UCSB RJE πŸ’”. In all three cases, it was the second card image transferred to RJE πŸ₯Ί. We couldn't trigger this at will, so we haven't been able to track it down yet 🧐. Unfortunately, the HASP system at UCSB just ignored that image instead of printing it, so we don't know the nature or source of the garbling 😀. It could be anywhere from the disk file storage at Rand on down the line 🎯. The problem showed up sporadically in our early transmissions to UCSB and then disappeared ✨. Still, we feel pretty confident that our Host software on either end wasn't at fault 🫑.

Lest those last two figures seem too terrifying πŸ˜…, we've run over 100 jobs at UCSB from Rand, and each job was made of many Network transmissions πŸ†πŸŽ‰.

[ This RFC was put into machine readable form for entry into the online RFC archives by Simone Demmel 4/97 ]

πŸ“¦ where this page comes from