1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
|
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]
^L
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.
Our plans for providing online service to the network are briefly
given below. There are intermediate stages possible. For example,
if all goes well in the early part of Stage 0 we can probably allow
more sites to participate in Stage 0.
Stage 0 (June 18):
Stage 0 is to provide experimental access to the NIC for a
limited number of West Coast sites (these sites provide a
variety of hosts and having them on the west coast simplifies
communications for this initial trial period) so that we can
learn how to handle any problems which may come up in actual
network operation.
Stage 0 will allow access to the Tenex Executive. NICTNLS (NIC
Version of Typewriter On Line System), an initial Network
Dialog Support System-NICDSS (which will allow online creation
and submission of messages and documents, with hardcopy mail
delivery), and the first release of our users manual.
We will allow an initial maximum of two network users on at
once.
There will be a two day NICTNLS course at SRI June 16-17 for
the initial sites.
Stage 1 (August 2):
Stage 1 is to provide access to the NIC from any site in the
network having the appropriate access software.
Melvin. et. al. [Page 2]
^L
RFC 153 Computer and Network Status 15 May 1971
Stage 1 will allow access to a self contained version of
NICTNLS not requiring access to the Tenex Executive, the NICDSS
of Stage 0 with online access to documents and messages created
online, online access of network related files such as the NIC
Catalog, ARPA Network Resource Notebook and NIC documentation.
We expect to provide training to sites desiring access. We
will allow as many network users simultaneous access as we can,
depending on initial success with system tuning. A reasonable
guess is 4-8.
Stage 2 (September 6):
Stage 2 will provide message delivery to files at remote sites
(assuming the NWG establishes file transfer protocols soon and
sites implement them), an initial deferred execution mode
allowing users to prepare files on their systems and then have
them entered into NICTNLS for further work, and improved query
facilities of network online files.
We hope to have improved Tenex-NLS performance so as to allow
more network users simultaneous access than allowed in Stage 1.
Offline System Status
Mailing: We mail RFC's and other material going to Liaison people as
soon as we can get the material duplicated, which is usually within
24-48 hours after we receive it. We mail material to station agents
once each week, usually on Fridays.
When people do their own direct mailing to the Liaison list, please
send us a good copy, preferably the original, for duplication and
sending to the stations.
Document Numbering: It is important for citation and cataloging
purposes that each document created have a unique number. Even if a
document is just an update of one previously issued, one should use a
new NIC number and RFC number and indicate which document(s) it
supercedes. There are lots of numbers so feel free to use them.
Site Documentation: Our recommendations on how we would like to
handle this type of document and the type of information these
documents should contain are described in RFC's 115 NIC (5822) and
118 NIC (5830). We urge each Liaison person and station agent to
read these carefully.
Melvin. et. al. [Page 3]
^L
RFC 153 Computer and Network Status 15 May 1971
Catalog: Our biggest problem caused by the computer transfer has
been getting out an up-to-date catalog. We apologize for the
inconvenience this has caused. Producing the catalog has turned out
to be a good debugging tool, however. The most recent catalog,
containing citations through 23 March, was mailed 13 May. This
catalog contains an RFC index through 5 May. Currently a catalog is
being produced to bring us up-to date. With the issuing of this
catalog around the end of the month, we expect to produce an up-to-
date catalog on a monthly basis.
General: If there are any problems a station may be having in
organizing or handling their collection which we could help with,
please let our Information and Agent Coordinator Jeanne North know.
If anyone has any suggestions for how we could improve our service or
has any suggestions for services we should perform please let us
know.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Ryan Kato 6/01 ]
Melvin. et. al. [Page 4]
^L
|
