>> There are two other routes to TCP/IP on a PDP11 without split I/D:
>> ...
>> 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.
>
> I wonder what the performance would be like, since the TCP is in a user
> process (a different one from the application), i.e. there's a process switch
> every time the application goes to send or receive data. This wouldn't have
> been such an issue when the code was written, since ARPANet-type networks
> were not very fast, but with a better network, it would have been limiting.
IEN98 (http://www.rfc-editor.org/rfc/ien/ien98.txt, page 2) has the answer: about 10kb/s.
The DCEC version used shared memory instead of rand ports and was claimed to be
a bit more performant, but I have no number. I'd be surprised if it was twice as fast,
so perhaps 15kb/s.
Paul
> From: Clem Cole
> So some other mechanism (also discussed here) needed to be created to
> avoid blocking in the application.
> ...
> Rand, UNET & Chaos had something else that gave the save async function,
> who's name I've forgotten at the moment
I don't think the RAND code had the non-blocking stuff; AFAICR, all it had was
named pipes (effectively). Jack Haverty at BBN defined and implemented two new
calls (IIRC, 'capac()' and 'await()') to do non-blocking I/O. The
documentation for that is in the 'BBN' branch at TUHS:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-V6/doc/ipc/awaithttp://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-V6/doc/ipc/ipc
My memory might be incorrect, but I don't think it was asynchronous (i.e. a
process issued a read() or write(), and that returned right away, before the
I/O was actually done, and the system notified the process later when the I/O
actually completed).
I actually did implement asyn I/O for an early LAN device driver - and just to
make it fun, the device was a DMA device, and we didn't want the overhead of a
copy, so the DMA was direct to buffers in the process - i.e. 'raw' I/O. So
that required some major system tweaks, to keep the process from being swapped
out - or moved around - while the I/O was pending.
> I believe Noel posted the code for same in the last year from one of the
> MIT kernels
I found it on the dump of an MIT machine, but it was never run on any machine
at MIT - we just had the source in case we had any use fot it.
Noel
> From: Paul Ruizendaal
> There are two other routes to TCP/IP on a PDP11 without split I/D:
> ...
> 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.
I wonder what the performance would be like, since the TCP is in a user
process (a different one from the application), i.e. there's a process switch
every time the application goes to send or receive data. This wouldn't have
been such an issue when the code was written, since ARPANet-type networks
were not very fast, but with a better network, it would have been limiting.
> From: Steve Simon
> do you have pointers to any documentation on the rand/MIT network API?
There was no 'MIT' network API. He was talking about the CHAOSNet API. The
TCP/IP done in the CSR group at MIT used a totally different API.
The various Unix systems at MIT were pretty well out of touch with each other,
and did not exchange code. The only exceptions were the DSSR (later RTS) and
CSR groups in Tech Sq, who used pretty much the same system.
Noel
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
-----Original Message-----
From: pechter(a)gmail.com
To: arnold(a)skeeve.com
Sent: Sat, 20 May 2017 16:41
Subject: Re: [TUHS] Unix with TCP/IP for small PDP-11s
Missed the reply all on the phone. Phil Karn had KA9Q in the 80s... It is mentioned on Wikipedia... Don't know much more. PPP might be better than slip.
Bill
-----Original Message-----
From: arnold(a)skeeve.com
To: pechter(a)gmail.com
Sent: Sat, 20 May 2017 16:12
Subject: Re: [TUHS] Unix with TCP/IP for small PDP-11s
Yes! Do you want to follow up to the list please?
Thanks,
Arnold
William Pechter <pechter(a)gmail.com> wrote:
> KA9Q sound right?
>
> -----Original Message-----
> From: arnold(a)skeeve.com
> To: imp(a)bsdimp.com, bqt(a)update.uu.se
> Cc: tuhs(a)minnie.tuhs.org
> Sent: Sat, 20 May 2017 15:06
> Subject: Re: [TUHS] Unix with TCP/IP for small PDP-11s
>
> Warner Losh <imp(a)bsdimp.com> wrote:
>
> > I read the sources to see the TCP/IP support was there (that's the bit
> > about adding Berkeley Sockets). I see nowhere that it's excluded for the
> > non I/D machines, but haven't tried it first hand. I got interested not
> > because of the PDP-11, but because I have an old Rainbow that recently
> > started running Venix (v7-based version) and was trolling around for some
> > way to do TCP/IP to it (though w/o readily available ethernet cards, I'm
> > not sure it is a viable project).
>
> Boy is the memory going. What was the TCP/IP implementation people
> ran on DOS to do connections over serial lines? Could that be found
> and revived for such a system?
>
> Thanks,
>
> Arnold
On 2017-05-21 23:27, Clem Cole <clemc(a)ccc.com> wrote:
> Actually, the 11/60's main claim to fame was it supposed to be a
> 'commercial' PDP-11 and was built for the small business market. The WCS
> was a side effect.
As you mentioned in another mail, it's main claim to fame was probably
the short time it actually existed in the market. DEC seriously did some
things wrong on it, such as only 18-bit address, and no split I/D space,
at a time when pretty much any other PDP-11 was going there.
But it was also one of a couple of -11 models where you had the ability
to write your own microcode. But I've never heard of anyone who had the
WCS option. (But at one point, I was playing with four 11/60 machines in
a computer club.)
I don't remember if it was you or someone else who said that there were
several microcode bugs in the 11/60. It ran the DEC OSes, but there were
some issues with Unix. I seem to also remember seeing some special code
in the RSX kernel for some 11/60 oddity, but I would have to search
through the code to remember exactly what that was about.
> It was to built to run RSTS and RSX and had a commercial instruction set
> exten *etc.*. Somebody had written a 'dentist office' package for it and a
> 'car dealership package' IIRC. And was physically packaged a tad
> differently than the other 11's as it was trying to be marketing to places
> that might want to show it off instead of hiding it in a computer room.
Uh? I have not seen any plans ever mentioning CIS for the 11/60, but I
guess it's possible it was considered at some point. But I can assure
you no CIS ever existed for the 11/60.
The only machines that ever had the CIS option was the 11/44 and
11/23,11/24.
But I have no idea how many machines ever actually had the option installed.
One nice detail of the 11/60 is that it had the FPP build in. But there
was also an optional hardware FPP accelerator available.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
I'm trying to find out if there is any existing Unix for the PDP-11
which supports TCP/IP on /40-/34-23 class machines (i.e. non-I+D
machines)?
Does 2.9 BSD with TCP/IP (assuming such a thing exists) fit on those
machines? (I know 2.9 does run on them, but I don't know about the TCP/IP
part.)
The reason I ask is that MIT did a TCP/IP for V6 which would run on them
(only incoming packet de-mux is in the kernel - the TCP is in with the
application, in the user process), which has recently been recovered from a
backup tape.
I'm trying to figure out if there is any use for it, as it would take some
work to make it usable (I'd have to write device drivers for available
Ethernet cards, and adapt an ARP implementation for it).
Noel
On 2017-05-20 04:00, Warner Losh <imp(a)bsdimp.com> wrote:
> https://ia601901.us.archive.org/10/items/bitsavers_decpdp11ulLTRIX112.0SPDS…
>
> Looks like it requires MMU, but not split I/D space as it lists the
> following as compatible: M11, 11/23+, 11/24, 11/34, 11/40 and 11/60. It
> does require 256kb of memory. See table 2, page 6 for details.
Uh...? Where do you see that there is any TCP/IP support in Ultrix-11?
If any was done by someone else, there is no saying that it would be
usable on a machine without split I/D. To be honest, I've never seen any
mention of TCP/IP on any machine without split I/D space. I guess it
could be done, but it would be a rather big headache...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
At Celerity we were porting Unix to a new NCR chipset for our washing machine sized Workstation.
We had a VAX 750 as the development box and we cross compiled to the NCR box. We contracted
out the 750 maintenance to a 3rd party and had no problems for a couple of years. Then one day I
came in to work to find the VAX happy consuming power and doing nothing. Unix wasn’t running and
nothing I could do would bring it back. After about 2 hours I got my boss and we contacted the maintenance
company. They guy they sent did much what I’d done and then went around the back. He pushed on the
backplane of the machine and Lo, it started working. He then removed the pressure and it failed quite
immediately. Turns out the backplane had a broken trace in it. We had done no board swaps in many
months and the room had had no A/C faults of any kind.
The company got a new backplane and had it installed in 2 days. Being 3rd party we couldn’t get it
replaced any quicker. After that it worked like a champ.
Celerity eventually became part of Sun as Sun Supercomputer.
David
OK, I'll kick it off.
A beauty in V6 (and possibly V7) was discovered by the kiddies in Elec
Eng; by sending a signal with an appropriately-crafted negative value (as
determined from inspecting <user.h>) you could overwrite u.u_uid with
zero... Needless to say I scrambled to fix that one on my 11/40 network!
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
