RFC 153 (rfc153) - Page 1 of 4

SRI ARC-NIC status

Alternative Format: Original Text Document
Next >
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.
Next >