SRI ARC-NIC status (RFC0153)
Original Publication Date: 1971-May-15
Included in the Prior Art Database: 2001-Sep-21
Internet Society Requests For Comment (RFCs)
J.T. Melvin: AUTHOR [+2]
Computer and Network Status
Network Working Group J. Melvin Request for Comments: 153 R. Watson NIC: 6758 SRI-ARC
15 May 1971
SRI ARC-NIC Status
Computer and Network Status
The conversion to the DEC PDP 10, running the BBN operating system Tenex, has just about been completed. We have had a number of obscure bugs which caused delays recently. Several symptoms were traced to bad data being written into memory. This problem was diagnosed as a noisey ground on a chip in the drum-disk memory bus access control. With the problem fixed our reliability has improved significantly to about one crash every day or two. System attention has now been turned to system measurement and tuning and to bringing up an NCP and Telnet.
We have been working to bring up the BBN NCP of Doc. #1 NIC (5143,) and BBN's Telnet. Because of our different configuration from BBN's and slightly different system we have not yet removed all the bugs caused by these differences. As of May 14 we estimate that we are only a few hours away from completing this task. We need more testing before we can provide network service. We will bring up the NCP of RFC 107 NIC (5806) when we can obtain it from BBN and the official Telnet when it is specified and BBN can provide it to us.
At present our local connect capacity allows for 12 displays and 24 typewriter terminals. With about 10 displays and 6 typewriter terminals running NLS, response is satisfactory, but marginal for display users. The delivery in June of new Bryant drums and the measurement and tuning in progress should increase capacity and response. How much improvement to expect is not known.
The system processing required to support a network user is heavier than that required to support a local typewriter user. Therefore we are not sure how many network users we will be able to support without degrading response seriously or requiring us to limit local loading by administrative restrictions. Our guess at the moment is that we can handle 6 network users by middle summer with an optimistic expectation that we might be able to handle closer to 12.
As there is only limited interactive experience over the network, we do not know what its response characteristics will be like. We may find that the delays caused by two timesharing systems and the network transmission may allow us to support the higher number of
Melvin. et. al. [Page 1]
RFC 153 Computer and Network Status 15 May 1971
network users without adding serious incremental response delays. The loading caused by parallel processes controlling intersite file transfers is also an unknown factor at this point.
We are pushing to increase our capacity by providing deferred execution facilities which will allow NLS compatible file preparation and editing offline or in local hosts and then will allow entry of the files so created into NLS for further manipulation.
File capacity is also going to be a scarce resource and we are studying ways of using tape or the facilities at UCSB to give us an integrated auxiliary facilities.