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

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

[Paul Ruizendaal via TUHS]

> Message: 6
> Date: Thu, 14 Jul 2022 17:51:39 +0000
> From: segaloco <segaloco@protonmail.com>
> 
> 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.

I doubt that V8 is "rebased on 4(.1?)BSD": in my understanding it ported some code from 4xBSD, but it is a different code base.

As I currently understand it, the V8 kernel:

- is a further development from 32V
- retains the code organisation of the V5..32V versions
- adds virtual memory code from BSD
- adds select() from BSD

and then adds all the V8 innovation on top of that (streams, file system switch, virtual proc file system, networking, remote file system, support for the Blit terminal, etc.)

In particular in the area of networking the V8 kernel is organised quite differently from the 4xBSD kernel, including the Chaosnet driver (i.e. it is streams based).

Paul

[TUHS] ECU

[Ron Natalie]

I had an ECU connecting the BRL-GATEWAY to the Imp in another building.  
   Rutgers also used an ECU to get their internet connection of the 
Columbia IMP.   When visiting BBN’s NOC I noted little red squares on 
the network map for my site.    I was told these signified an ECU and it 
is because it causes problems when the host crashes.

Let me explain this quaint piece of operation.

Both the IMP and the LH or DH host interface have a relay that indicates 
the interface is powered up.   The idea is that if you shutdown the 
machine (or the imp) the relay fails open.    That’s fine for a gross 
shutdown, but let’s say the machine just hangs.

The IMP has a feature called “TARDY DOWN.”  If you stop accepting 
packets for a while, the thing declares you “TARDY DOWN” (effectively 
down for the rest of the net).    This is signified on the later C-30 
imps by the display register bit for that host flashing.    Now the IMP 
says, “Hey, let me try to wake this guy up.”   It does this by dropping 
its relay for a second hoping to trick the host into thinking it has 
rebooted and it should reinitialize.   Of course, this gambit rarely 
works, but if the host did wake up, if it starts processing messages 
again, the IMP says “All is well” and declares the host up.

Now, what if you had an ECU.   Well, when the IMP flaps it’s relay, the 
ECU says “Hey, something happened to the IMP.”   I better reset 
everything including any buffered packets.  The ECU actually buffers 
three packets or so while it is transferring them to the other end.    
Well, now that the buffer is empty, it can take three more packets.   
The IMP declares it up.   Of course, the host isn’t really there, so the 
packets just stay there and then the ECU fills up and stops answering 
the IMP and the IMP eventually declares it TARDY DOWN again.

Lather, Rinse, Repeat.

This wouldn’t be so bad except that every time there’s a transition a 
message is printed out in the NOC.   So a dead host on an ECU causes a 
couple of messages to be printed every three minutes until someone does 
something about it.

Later, we had similar fun and games with the EGP protocol.   The 
protocol suggest you not declare the peer up until after you receive n 
(where n = 3) hello messages.    I’m more optimistic than that.   My 
implementation sent a “OK, You’re up” response after a single HELLO.   
Of course, this pissed off some other client who said, I can’t be up 
after only one HELLO, I better start the whole thing over again.

Lather, Rinse, Repeat.