22 May
2017
22 May
'17
9:28 a.m.
I had somehow convinced myself that Ultrix-11 needed split I/D, but indeed it does not:
# file unix
unix: (0450) pure overlay executable not stripped
# size unix
14784+(8192,8000,8064,8000,8064,8128,8000,7808,7936,7936,7680,7360,1344)+3524+13500 =
31808b = 076100b (111296 total text)
With only 16KB of permanent kernel there will be a lot of overlay switching. I'm not
entirely sure why bss could not be 1KB smaller, enabling 8KB more of permanent kernel. The
loss of performance from 2 disk buffers less really outweighed less overlay switching?
If I understand correctly, the network code continuously switches around segment 5 to
access the right mbuf.
According to the notes in the TUHS archive
(http://www.tuhs.org/Archive/Distributions/DEC/Ultrix-11/Fred-Ultrix3/setup-…)
running Ultrix-11 with networking on a 11/40 class machine is borderline workable:
"I have personally tested it on a 23+, 53 and 83. I know it runs
fine on the 73. The smaller machines (34, 40 etc) should work
akin to the 23, meaning using overlays and be very tight on RAM
for the drivers. TCP/IP is a biiiiig load for those systems!"
There are two other routes to TCP/IP on a PDP11 without split I/D:
- 3COM's TCP/IP package (initially an overlay over V7, soon after also over 2BSD); I
believe the source to this is lost.
- DCEC's adaptation of the Wingfield TCP/IP library, designed to work with V6. It is
mostly a user space daemon, but requires some kernel enhancements. The Wingfield code is
in the TUHS archive, but that version has a modified V6 kernel that also supports NCP
networking and requires split I/D. If used with a minimally enhanced V6 kernel, it would
easily fit in 64KB, without overlays.
Note that these last two options have very different API's and would not be so easy
to work with.
Paul
22 May
22 May
2:09 p.m.
New subject: Unix with TCP/IP for small PDP-11s
On Mon, May 22, 2017 at 5:28 AM, Paul Ruizendaal <pnr(a)planet.nl> wrote:
There are two other routes to TCP/IP on a PDP11
without split I/D:
- 3COM's TCP/IP package (initially an overlay over V7, soon after also
over 2BSD);
It's called UNET
I believe the source to this is lost.
So far that is true, there are a couple of leads including a couple of
unread tapes in my own basement. The original authors and I have been in
touch. Assuming we can find and recover it, there is still an open issue
of copyright.
.....
Note that these last two options have very different API's
Indeed...
and would not be so easy to work with.
Mumble ... it just means post-Joy sockets code does not 'just work.'
UNET
uses the Rand interface, which is similar to the interface MIT used for
Chaos and Chesson used for the ARPAnet code at UofI, so there are programs
that talk to it. We had mail, ftp and telnet working just fine.
Back in the day and IIRC we were playing with a port of the MIT SUPDUP
code but I do not remember if that ever worked on the small address
machines.
2:51 p.m.
New subject: Unix with TCP/IP for small PDP-11s
hi Clem,
do you have pointers to any documentation on the rand/MIT network API?
-Steve
On 22 May 2017, at 15:09, Clem Cole
<clemc(a)ccc.com> wrote:
On Mon, May 22, 2017 at 5:28 AM, Paul Ruizendaal
<pnr(a)planet.nl> wrote:
There are two other routes to TCP/IP on a PDP11 without split I/D:
- 3COM's TCP/IP package (initially an overlay over V7, soon after also over 2BSD);
It's called UNET
I believe the source to this is lost.
So
far that is true, there are a couple of leads including a couple of unread tapes in my own
basement. The original authors and I have been in touch. Assuming we can find and
recover it, there is still an open issue of copyright.
.....
Note that these last two options have very different API's
Indeed...
and would not be so easy to work with.
Mumble ... it just means post-Joy sockets code does not 'just work.' UNET uses
the Rand interface, which is similar to the interface MIT used for Chaos and Chesson used
for the ARPAnet code at UofI, so there are programs that talk to it. We had mail, ftp
and telnet working just fine. Back in the day and IIRC we were playing with a port of
the MIT SUPDUP code but I do not remember if that ever worked on the small address
machines.
4:29 p.m.
New subject: Unix with TCP/IP for small PDP-11s
The Rand API is documented in a couple of papers that have been discussed
here previously. I'll have to do a little googling to find them. The
ChaosNET docs are the best MIT docs.
The API pretty much worked this way... there was one simple kernel hook.
A small mod was done to the old nami routine (what modern UNIX calls
'lookup'), as a path was being parsed, the rest of the path was left in
place made available to other routines.
Thus you could open: /dev/tcp/xxx and the string xxx was available in
call that was implementing tcp and was then able to be passed xxx as a
parameter. Hence, the traditional open/close/read/write was all that was
needed.
Joy codified a new API that was supposed to be more network centric and map
to different network protocols - the thinking being that
open/close/read/write were insufficient semantics for network operations.
Also, the only other issue at the time was that BSD's select(2) did not
exist, and the UNIX I/O were 100% synchronous. So some other mechanism
(also discussed here) needed to be created to avoid blocking in the
application. There were a couple of different schemes with V7's
multiplexor call was created by Chesson for DataKit (which was similar to
was used in the UofI code Arpanet code). Rand, UNET & Chaos had something
else that gave the save async function, who's name I've forgotten at the
moment, but I believe Noel posted the code for same in the last year from
one of the MIT kernels - we had used it at CMU that we had gotten from Rand.
On Mon, May 22, 2017 at 10:51 AM, Steve Simon <steve(a)quintile.net> wrote:
hi Clem,
do you have pointers to any documentation on the rand/MIT network API?
-Steve
On 22 May 2017, at 15:09, Clem Cole <clemc(a)ccc.com> wrote:
On Mon, May 22, 2017 at 5:28 AM, Paul Ruizendaal <pnr(a)planet.nl> wrote:
There are two other routes to TCP/IP on a PDP11
without split I/D:
- 3COM's TCP/IP package (initially an overlay over V7, soon after also
over 2BSD);
It's called UNET
I believe the source to this is lost.
So far that is true, there are a couple of leads including a couple of
unread tapes in my own basement. The original authors and I have been in
touch. Assuming we can find and recover it, there is still an open issue
of copyright.
.....
Note that these last two options have very different API's
Indeed...
and would not be so easy to work with.
Mumble ... it just means post-Joy sockets code does not 'just work.'
UNET uses the Rand interface, which is similar to the interface MIT used
for Chaos and Chesson used for the ARPAnet code at UofI, so there are
programs that talk to it. We had mail, ftp and telnet working just fine.
Back in the day and IIRC we were playing with a port of the MIT SUPDUP
code but I do not remember if that ever worked on the small address
machines.
4:35 p.m.
New subject: Unix with TCP/IP for small PDP-11s
Gak, the days before select. I remember writing some terminal programs where I had to
fork and do the synchronous read in each direction separately.
10:07 p.m.
New subject: Unix with TCP/IP for small PDP-11s
Clem,
You've got me confused.
The API pretty much worked this way... there was one
simple kernel hook. A small mod was done to the old nami routine (what modern UNIX calls
'lookup'), as a path was being parsed, the rest of the path was left in place
made available to other routines.
The UoI Arpanet code did not use the partial path parsing that you describe.
The namei() routine is unchanged (see
http://www.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/ken/nami.c)
The code recognizes a network open, because the open() is of a special character file with
major number 255;
the minor number would be the remote address (1974 arpanet used 8 bit network addresses -
6 bits IMP, 2 bits host).
If the 'mode' parameter to open() is 0, 1 or 2, then a NCP/telnet connection
would be made to that host. If the mode parameter was anything else, it was a pointer to a
data block with the full specification of the connection to be made. See:
http://www.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/ken/sys2.c - open1()
http://www.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/ncpk/nopcls.c - netopen()
The data block contained all the parameters that are set via calls to connect/bind/listen
in the BSD sockets API.
There were a couple of different schemes with
V7's multiplexor call was created by Chesson for DataKit (which was similar to was
used in the UofI code Arpanet code).
You've lost me here.
Paul
On 22 May 2017, at 18:29 , Clem Cole wrote:
> The Rand API is documented in a couple of papers that have been discussed here
previously. I'll have to do a little googling to find them. The ChaosNET docs are
the best MIT docs.
>
>
The API pretty much worked this way... there was one
simple kernel hook. A small mod was done to the old nami routine (what modern UNIX calls
'lookup'), as a path was being parsed, the rest of the path was left in place
made available to other routines.
>
> Thus you could open: /dev/tcp/xxx and the string xxx was available in call that was
implementing tcp and was then able to be passed xxx as a parameter. Hence, the
traditional open/close/read/write was all that was needed.
>
> Joy codified a new API that was supposed to be more network centric and map to
different network protocols - the thinking being that open/close/read/write were
insufficient semantics for network operations.
>
> Also, the only other issue at the time was that BSD's select(2) did not exist,
and the UNIX I/O were 100% synchronous. So some other mechanism (also discussed here)
needed to be created to avoid blocking in the application. There were a couple of
different schemes with V7's multiplexor call was created by Chesson for DataKit
(which was similar to was used in the UofI code Arpanet code). Rand, UNET & Chaos
had something else that gave the save async function, who's name I've forgotten
at the moment, but I believe Noel posted the code for same in the last year from one of
the MIT kernels - we had used it at CMU that we had gotten from Rand.
>
> On Mon, May 22, 2017 at 10:51 AM, Steve Simon <steve(a)quintile.net> wrote:
> hi Clem,
>
> do you have pointers to any documentation on the rand/MIT network API?
>
> -Steve
11:25 p.m.
New subject: Unix with TCP/IP for small PDP-11s
We'll have to do some digging. And having too been part of too many, but
similar of different implementations. The Chaos code used the partial
parsing as did a few others. IIRC: That's the same trick Apollo used with
Domain too. I had thought I had remember that Chesson and the UofI folks
used the same trick with the Arpanet code, but I have not looked at it in
years and clearly as you point out he did not.
As for DataKit et al.. Greg Chesson was a grad student at UoI. The UoI
folks did the original V6 Arpanet for UNIX code and Greg was the one of
the primary developers same. What I do not remember is who came first, the
Rand networking work for the UoI work. Rand did the the ports (later
called named pipes) and a few other things pretty early. But again all
those dates sort of mix together in the early middle 70s. USENIX was not
yet publishing proceedings so it's hard to keep straight. It pretty much
just email and memories of those of us that were sharing things at the time.
Anyway, when Greg graduated, he was hired by Ken when he finished and
developed DataKit at Bell labs. One of the pieces of datakit that was
released as part of V7 was Greg's mpx(2) code - which was the multiplexer.
The legend is that on is way to UCB for his sabbatical, Ken was checking in
Greg and the infamous v6 patches tape was left behind at UoI. Greg used to
deny all knowledge of same, but smiled all the time he said it.
Clem
On Mon, May 22, 2017 at 6:07 PM, Paul Ruizendaal <pnr(a)planet.nl> wrote:
Clem,
You've got me confused.
The API pretty much worked this way... there was
one simple kernel
hook. A small mod was done to the old nami routine (what modern
UNIX
calls 'lookup'), as a path was being parsed, the rest of the path was left
in place made available to other routines.
The UoI Arpanet code did not use the partial path parsing that you
describe.
The namei() routine is unchanged (see http://www.tuhs.org/cgi-bin/
utree.pl?file=SRI-NOSC/ken/nami.c).
The code recognizes a network open, because the open() is of a special
character file with major number 255;
the minor number would be the remote address (1974 arpanet used 8 bit
network addresses - 6 bits IMP, 2 bits host).
If the 'mode' parameter to open() is 0, 1 or 2, then a NCP/telnet
connection would be made to that host. If the mode parameter was anything
else, it was a pointer to a data block with the full specification of the
connection to be made. See:
http://www.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/ken/sys2.c - open1()
http://www.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/ncpk/nopcls.c -
netopen()
The data block contained all the parameters that are set via calls to
connect/bind/listen in the BSD sockets API.
There were a couple of different schemes with
V7's multiplexor call was
created by Chesson for DataKit (which was similar to
was used in the UofI
code Arpanet code).
You've lost me here.
Paul
On 22 May 2017, at 18:29 , Clem Cole wrote:
The Rand API is documented in a couple of papers
that have been
discussed here previously. I'll have to do a little googling
to find
them. The ChaosNET docs are the best MIT docs.
>
>
The API pretty much worked this way... there was
one simple kernel
hook. A small mod was done to the old nami routine (what modern
UNIX
calls 'lookup'), as a path was being parsed, the rest of the path was left
in place made available to other routines.
Thus you could open: /dev/tcp/xxx and the string xxx was available in
call that
was implementing tcp and was then able to be passed xxx as a
parameter. Hence, the traditional open/close/read/write was all that was
needed.
Joy codified a new API that was supposed to be more network centric and
map to
different network protocols - the thinking being that
open/close/read/write were insufficient semantics for network operations.
Also, the only other issue at the time was that BSD's select(2) did not
exist, and the UNIX I/O were 100% synchronous. So some other mechanism
(also discussed here) needed to be created to avoid blocking in the
application. There were a couple of different schemes with V7's
multiplexor call was created by Chesson for DataKit (which was similar to
was used in the UofI code Arpanet code). Rand, UNET & Chaos had something
else that gave the save async function, who's name I've forgotten at the
moment, but I believe Noel posted the code for same in the last year from
one of the MIT kernels - we had used it at CMU that we had gotten from Rand.
On Mon, May 22, 2017 at 10:51 AM, Steve Simon <steve(a)quintile.net>
wrote:
hi Clem,
do you have pointers to any documentation on the rand/MIT network API?
-Steve
23 May
23 May
12:36 a.m.
New subject: Unix with TCP/IP for small PDP-11s
On 23 May 2017, at 1:25 , Clem Cole wrote:
As for DataKit et al.. Greg Chesson was a grad
student at UoI. The UoI folks did the original V6 Arpanet for UNIX code and Greg was the
one of the primary developers same. What I do not remember is who came first, the Rand
networking work for the UoI work. Rand did the the ports (later called named pipes) and
a few other things pretty early. But again all those dates sort of mix together in the
early middle 70s. USENIX was not yet publishing proceedings so it's hard to keep
straight. It pretty much just email and memories of those of us that were sharing things
at the time.
These dates I can fill in:
- UoI Arpanet Unix was initially done between December 1974 and March 1975, building on
the experience gained with the earlier ANTS I and II projects.
- Rand ports were done in 1977, under contract to the air force (report dated June
'77).
Anyway, when Greg graduated, he was hired by Ken when
he finished and developed DataKit at Bell labs. One of the pieces of datakit that was
released as part of V7 was Greg's mpx(2) code - which was the multiplexer.
Interesting. I always thought that mpx files were driven by the work on the Blit terminal,
the link to networking is new to me.
I'm looking into the history of Spider and early Datakit. Sandy Fraser was kind
enough to send me the 1974 report on Spider and it already mentions actual usage for
remote printing, remote login and a central 'file store'. Spider was an
interesting bit of technology, essentially it linked a dozen or so computers over a
1.5Mb/s shared link (a daisy chained twisted pair cable) to a central router/switch. There
was only ever one Spider router, but the design allowed for multiple routers to be
connected over T1 long distance lines.
Does anybody know of surviving v5/v6/v7 code for Spider networking (e.g. the
'tiu' device driver, the 'nfs' file transfer package, etc.)?
3000
days inactive
3001
days old
7 comments
4 participants
participants (4)
-
Clem Cole -
Paul Ruizendaal -
Ron Natalie -
Steve Simon