The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: "Ron Natalie" <>
To: "The Eunuchs Hysterical Society" <>
Subject: [TUHS] ECU
Date: Fri, 15 Jul 2022 11:55:38 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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.

      reply	other threads:[~2022-07-15 11:56 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-15  8:51 [TUHS] Re: Unix V8 Chaosnet, any takers? Paul Ruizendaal via TUHS
2022-07-15 11:55 ` Ron Natalie [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).