[TUHS] Unix V8 Chaosnet, any takers?

[TUHS] Unix V8 Chaosnet, any takers?

[Lars Brinkhoff]

Hello,

Unix V8 has some code for Chaosnet support.  There is a small hobbyist
Chaos network going with Lispm, PDP-10, PDP-11, and Berkeley Unix nodes.
Is there anyone who would be interested in trying to see if the V8 code
is in a workable state, and get it running?

Best regards,
Lars Brinkhoff

[TUHS] Re: Unix V8 Chaosnet, any takers?

[John Floren]

On 7/14/22 04:08, Lars Brinkhoff wrote:
> Hello,
>
> Unix V8 has some code for Chaosnet support.  There is a small hobbyist
> Chaos network going with Lispm, PDP-10, PDP-11, and Berkeley Unix nodes.
> Is there anyone who would be interested in trying to see if the V8 code
> is in a workable state, and get it running?
>
> Best regards,
> Lars Brinkhoff

A network of lisp machines and PDP-10/11 systems seems pretty cool... is
there a web site for the network?

john

[TUHS] Re: Unix V8 Chaosnet, any takers?

[Lars Brinkhoff]

John Floren wrote:
> A network of lisp machines and PDP-10/11 systems seems pretty
> cool... is there a web site for the network?

Yes, it's here:
https://chaosnet.net/

And there's a GitHub organization:
https://github.com/Chaosnet/

To keep this on topic, known Unix implementations of Chaosnet include
4.1BSD (up and running), V8 (available but not running), and V7 (not
found yet).

[TUHS] Re: Unix V8 Chaosnet, any takers?

[segaloco via TUHS]

Given V8 being rebased on 4(.1?)BSD, I suspect the path of least resistance would be to just start grafting V8 code onto the working 4.1BSD.

What sort of help are you looking for? I've got idle fingers in the evenings lately, if you just need some code junkies to work on things I'm happy to throw my hat in the ring.

- Matt G.

------- Original Message -------
On Thursday, July 14th, 2022 at 10:00 AM, Lars Brinkhoff <lars@nocrew.org> wrote:


> John Floren wrote:
>
> > A network of lisp machines and PDP-10/11 systems seems pretty
> > cool... is there a web site for the network?
>
>
> Yes, it's here:
> https://chaosnet.net/
>
> And there's a GitHub organization:
> https://github.com/Chaosnet/
>
> To keep this on topic, known Unix implementations of Chaosnet include
> 4.1BSD (up and running), V8 (available but not running), and V7 (not
> found yet).

[TUHS] Re: Unix V8 Chaosnet, any takers?

[Ron Natalie]

Note, I don’t know what you’re planning, but Chaos couldn’t take any 
propagation delay.   It’s really limited to a LAN implementation as 
originally designed.

[TUHS] Re: Unix V8 Chaosnet, any takers?

[Lars Brinkhoff]

segaloco wrote:
> What sort of help are you looking for? I've got idle fingers in the
> evenings lately, if you just need some code junkies to work on things
> I'm happy to throw my hat in the ring.

I'm mainly curious if the V8 code works.  I haven't examined it at all,
so I have no idea.

For reference, I have a disk image with 4.1BSD patched and ready to
run with SIMH here:
http://lars.nocrew.org/tmp/Chaotic-4.1BSD.tar.bz2

I collected all the bits and pieces here and intended to make
an expect script to install, patch, and build everything.  I didn't
the script but all the stuff should be here:
https://github.com/Chaosnet/Chaosnet-for-4.1BSD

[TUHS] Re: Unix V8 Chaosnet, any takers?

[Tom Teixeira]

On 7/14/22 2:19 PM, Ron Natalie wrote:
> Note, I don’t know what you’re planning, but Chaos couldn’t take any 
> propagation delay.   It’s really limited to a LAN implementation as 
> originally designed.
>
It definitely had subnet routing, and as I recall, the KL10's and other 
machines with front end I/O processors generally used chaosnet routing 
between the host itself and the rest of the network. i.e. the I/O 
processor was on one subnet, the host on a second subnet and the rest of 
the "LAN" was on the other side of the I/O processor. My recollection is 
that unlike an IP router, a Chaosnet node had only one address, and 
routing tables determined which device to send the data on.

And LCS definitely had multiple coax cable runs with each run a subnet 
with routing between. But with a maximum of 256 subnets, routing was 
much simpler.

I wonder how much benefit is available from using network switches 
rather than collision detection and retransmit, though the virtual token 
was supposed to reduce collisions somewhat.

[TUHS] Re: Unix V8 Chaosnet, any takers?

[Ron Natalie]

It can do subnets, but it can’t deal with long haul (over the greater 
internet) time delays.


------ Original Message ------
From "Tom Teixeira" <tjteixeira@earthlink.net>
To tuhs@tuhs.org
Date 7/14/2022 4:32:55 PM
Subject [TUHS] Re: Unix V8 Chaosnet, any takers?

>On 7/14/22 2:19 PM, Ron Natalie wrote:
>>Note, I don’t know what you’re planning, but Chaos couldn’t take any propagation delay.   It’s really limited to a LAN implementation as originally designed.
>>
>It definitely had subnet routing, and as I recall, the KL10's and other machines with front end I/O processors generally used chaosnet routing between the host itself and the rest of the network. i.e. the I/O processor was on one subnet, the host on a second subnet and the rest of the "LAN" was on the other side of the I/O processor. My recollection is that unlike an IP router, a Chaosnet node had only one address, and routing tables determined which device to send the data on.
>
>And LCS definitely had multiple coax cable runs with each run a subnet with routing between. But with a maximum of 256 subnets, routing was much simpler.
>
>I wonder how much benefit is available from using network switches rather than collision detection and retransmit, though the virtual token was supposed to reduce collisions somewhat.
>

[TUHS] Re: Unix V8 Chaosnet, any takers?

[segaloco via TUHS]

This looks like it might be exactly what you're looking for:

http://9legacy.org/9legacy/doc/simh/v8

Steps to start with a 4.1BSD base in simh and use that to ultimately produce a V8 system. I haven't audited these instructions myself, so YMMV, but I suspect someone wouldn't go through the hard work if this didn't do anything.

That said, your original posting mentions the PDP-11, but also "Berkeley Unix Nodes". For the latter, do you mean VAX? These instructions are for VAX too, I don't know whether V8 ran on PDP-11 or not, but if that's your intent, you may want to start with a 2.xBSD or V7 as a base instead.

- Matt G.

------- Original Message -------
On Thursday, July 14th, 2022 at 12:36 PM, Lars Brinkhoff <lars@nocrew.org> wrote:


> segaloco wrote:
>
> > What sort of help are you looking for? I've got idle fingers in the
> > evenings lately, if you just need some code junkies to work on things
> > I'm happy to throw my hat in the ring.
>
>
> I'm mainly curious if the V8 code works. I haven't examined it at all,
> so I have no idea.
>
> For reference, I have a disk image with 4.1BSD patched and ready to
> run with SIMH here:
> http://lars.nocrew.org/tmp/Chaotic-4.1BSD.tar.bz2
>
> I collected all the bits and pieces here and intended to make
> an expect script to install, patch, and build everything. I didn't
> the script but all the stuff should be here:
> https://github.com/Chaosnet/Chaosnet-for-4.1BSD

[TUHS] Re: Unix V8 Chaosnet, any takers?

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 942 bytes --]

On 7/14/22 2:39 PM, Ron Natalie wrote:
> It can do subnets, but it can’t deal with long haul (over the greater 
> internet) time delays.

I wonder if there is an opportunity for something that pretends to be 
the remote side locally, sends the data via some other 
non-latency-sensitive protocol to a counter part where the counter part 
pretends to be the near side.

Local         /
              /
[A]----[B]==/==[C]---[D]
            /
           /       Remote

Where ---- is Chaosnet over a short distance and ==/== is something else 
over a long distance.  B would pretend to be D so that A could talk to 
D' in a timely manner and conversely C would pretend to be A so that A' 
could talk to D in a timely manner.

I've seen such spoofing / emulation in other protocols.  Maybe the prior 
art can work for Chaosnet.

P.S. Hopefully my ASCII art will survive the trip.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4017 bytes --]

[TUHS] Re: Unix V8 Chaosnet, any takers?

[Erik E. Fair]

Grant,

You've just described a useful piece of old ARPANET hardware: the Advanced Communications Corp (ACC) Error Control Unit (ECU). ARPANET IMP 1822 (serial) interface could be "local host" (30 feet, unbalanced serial), or "distant host" (up to 2,000 feet, balanced serial).

One used a pair of ACC ECUs - one at the IMP end, one at the host end, with potentially arbitrary distance inbetween the ECUs, so as to obviate the 1822 LH/DH limits.

I managed such a setup at LLNL in 1986 (MILNET, IMP #21): when I was hired, the group I hired into (well, put under contract to by CDC Professional Services) was on-site at the lab, but as the wires ran between the old AEC instrument trailer that was our machine room for a VAX-11/780 and PDP-11/70 (both running BSD, natch) and the Magnetic Fusion Energy Computer Center (MFE CC) where the IMP was located was rather longer than 1822 DH could handle.

A 3002 circuit ("dry" pairs) and a pair of LADDS high-speed modems did the trick there.

Later, my group moved to the Hacienda Business Park in Pleasanton, some miles away; we set up a Pac*Bell 56Kb/s (DS0) leased line with standard CSU/DSUs to connect the ACC ECUs and in turn the host (well, router) to our port on the IMP. I had some trouble getting that one going again because the ACC ECU manuals were ... disjoint: simple recipies for setting DIP switches (with no explanation of why), and a complete schematic in the back, which was useless to me because I'm not an EE, but the documented switch settings for our desired setup didn't work. ACC sent two engineers to our site from Santa Barbara to solve the problem - the senior one was the last engineer to issue an Engineering Change Order (ECO) on the ECUs.

To bring this back to a Unix context, that sort of "spoofers in the middle" was also the shtick of Telebit Trailblazer modems for the UUCP "g" protocol in UUCP/USENET days - 19.2Kb/s in one direction at a time, and the modems "knew" the "g" protocol and spoofed it for maximum speed in one direction, which was the way UUCP worked too: file transfers were handled one direction at a time, and just ACKs coming back. Internally, they effectively provided an optimized UUCP tunnel atop their quite tenacious Packetized Ensemble Protocol (PEP).

	Erik

[TUHS] Re: Unix V8 Chaosnet, any takers?

[Lars Brinkhoff]

segaloco wrote:
> This looks like it might be exactly what you're looking for:
> http://9legacy.org/9legacy/doc/simh/v8

Thanks!

> That said, your original posting mentions the PDP-11, but also
> "Berkeley Unix Nodes". For the latter, do you mean VAX?

Yes, they are VAX-11/780 SIMH instances running 4.1BSD + MIT patches.

> I don't know whether V8 ran on PDP-11 or not, but if that's your
> intent, you may want to start with a 2.xBSD or V7 as a base instead.

The Chaosnet documentation says there were PDP-11 Unix V7 nodes on the
network.  That code has not been found though.  Same goes for VAX/VMS.

[TUHS] Re: Unix V8 Chaosnet, any takers?

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 850 bytes --]

On Sat, Jul 16, 2022, 12:38 AM Lars Brinkhoff <lars@nocrew.org> wrote:

> segaloco wrote:
> > This looks like it might be exactly what you're looking for:
> > http://9legacy.org/9legacy/doc/simh/v8
>
> Thanks!
>
> > That said, your original posting mentions the PDP-11, but also
> > "Berkeley Unix Nodes". For the latter, do you mean VAX?
>
> Yes, they are VAX-11/780 SIMH instances running 4.1BSD + MIT patches.
>
> > I don't know whether V8 ran on PDP-11 or not, but if that's your
> > intent, you may want to start with a 2.xBSD or V7 as a base instead.
>
> The Chaosnet documentation says there were PDP-11 Unix V7 nodes on the
> network.  That code has not been found though.  Same goes for VAX/VMS.
>

V7 could mean a modification of net unix or using that as a starting point.
But without code that's just wild speculation on my part.

Warner

[-- Attachment #2: Type: text/html, Size: 1604 bytes --]