[ih] inter IMP hackery [was Recently restored and a small ARPANET was run using simulated IMP hardware, ]

[vinton cerf]

local back up paper tape and phone calls to people to flip switches -
eventually a BBN node came up and the boot-from-neighbor code was written.

v


On Sun, Sep 6, 2020 at 8:58 PM the keyboard of geoff goodfellow via
Internet-history <internet-history at elists.isoc.org> wrote:

> Bernie, one thing yours truly has always been curious of is when the
> ARPANET was initially being rolled out, viz.:
> http://som.csudh.edu/fac/lpress/history/arpamaps/press.jpg :
>
> How were the first four IMPs (UCLA, SRI, UCSB & UTAH) managed/controlled
> until the cross country link to IMP #5 to y'all at BBN was installed?
> and
> What was the length of time the initial 4 ARPANET IMPs "ran" without the
> cross country link to IMP #5 in Boston?
>
> geoff
>
> On Sun, Sep 6, 2020 at 1:30 PM Bernie Cosell via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
> > Let me add a little bit to Jack's explorations.  There are two things of
> > interest we
> > put in the IMP code that relates to this.  The first was the DDT/TTY
> > machinery
> > and other was the "reload from your neighbor" machinery.
> >
> > I remember that first quite well, since I mostly designed it [we did
> > EVERYTHING as a team so we coöperated and sorted stuff out together] and
> I
> > implemented it [so I was really responsible for the complicated machinery
> > that
> > made this aspect of the IMP work]:
> >
> > Early on as we were coding the IMP stuff the question arose as to what to
> > do
> > about the TTY [and how the hell were we to debug the damn thing].  We did
> > several things in this regard.  First I wrote a simple DDT [about as
> > powerful as
> > the test-word switches on our PDP-1 :o)] but it allowed us to poke around
> > in the
> > dead hulk of the code of a stopped system to see what went wrong and also
> > put
> > patches in.  I believe it was originally a stand alone - the imp would
> > crash or hit a
> > diagnostic trap and they we could run the DDT and look at buffers and
> > counters
> > and pointers and such and generally try to figure out what happened.
> When
> > the
> > IMP was running solidly enough [which actually happened pretty early on
> in
> > its
> > development],   I can't remember the genesis of the underlying idea, but
> > we
> > thought we could route the DDT *over* the net to other IMPs and poke at
> > *then*.
> > I came up with a scheme that Will [I think] thought was way too
> > complicated:
> >
> >    1) connect the DDT to the IMP as a "fake host",
> > &2) connect the TTY to the IMP as another "fake host"
> >
> > With those now residing *in* the IMP, instead of apart from it we got a
> > bunch of
> > benefits:
> >     1) we could run the DDT *while* the IMP was up doing its thing, and
> >    2) we could interrogate a *different* IMPs DDT [simply by pointing the
> > TTY to
> > the appropriate fake host on the other IMP.
> >    3) We could "IM" between machines [simply by pointing the TTY to the
> > *TTY*
> > on the other machine.
> >
> > [on (3) that ability was very handy as Ben and Marty were bringing up
> IMPs
> > 1&2.
> > They knew, for example, long before any of the host interface and
> > machinery was
> > working, that the IMP was doing just fine, since they could exchange
> > messages
> > and *knew* it used the same code that the hosts would be using.  It also
> > replaced
> > lots of long-distance calls to coördinate what was happening at SRI and
> > UCLA]
> >
> > WE also had the IMPs send "health reports" [via a background process] and
> > they
> > were hard wired to send to the IMP 5 TTY and so virtually from the outset
> > we
> > could monitor [and with the DDT tweak] the whole network.   Until the
> > PDP-1
> > was online it chewed up a fair bit of paper :o)
> >
> > It was all using the basic IMP packet-handling machinery, so that two
> IMPs
> > could be poking the DDT on a particular IMP and not interfere with one
> > another.
> > When the PDP-1 came online as the first proto-NCC, the DDT was as happy
> to
> > talk to a real host as one of its fake brethrens and ditto for the
> "health
> > reports"
> > that just changed which host they were going to and it all worked.  So
> > everything
> > was fitting together very nicely and very usefully [despite the
> > complicated code]
> >
> > A conceptually neat part about all this is that the *internals* of the
> IMP
> > were
> > host-agnostic.   They didn't care if they were fake or real, they just
> > sent the
> > packets where there were supposed to go.   and so we could implement
> > "satellite"
> > activities that used the underlying IMP code to do other useful things
> > beyond
> > just host-to-host.
> >
> > Expanding this principle a few years later, we had a H316 that had *two*
> > 16k
> > banks.  [and I think I've mentioned this before on this list].  We
> decided
> > to
> > implement the TIP as, what else?? :o), a host.  But in this case it was a
> > pseudo-real-host [as I've mentioned before]  this was done so that the
> TIP
> > code
> > could live in the upper memory bank and its "host interface" transferred
> > data and
> > control across the boundary.  The IMP didn't need to know or care that
> the
> > TIP
> > was there.
> >
> > Phew.   now to the second mechanism: reloading from a neighbor.   Maybe
> > dave
> > remembers this better than I do but I think that one of the things we did
> > as the
> > IMP got more solid was removed its "loader" [which could boot the machine
> > from paper tape] and replaced with with something that could live in 20
> > words
> > [which was where the paper tape loader lived: in shadow memory behind the
> > registers]   I think that that code was *just* enough of a bootstrap to
> > send
> > message to a neighboring IMP and the first thing that IMP sent over a
> > smarter
> > loader that than received a whole memory-full of IMP code from the
> > neighbor
> > and then started the neighbor up.   I believe we could trigger this
> > remotely via
> > DDT and so if the IMP was up but just in need of an updated version it
> > could
> > suck it in from its neighbor.
> >
> > My opinion is that hacking in this kind of stuff [and piggybacking
> > "services" on
> > top of the IMP's 'day job' of handing real host data] helped a lot in the
> > ARPAnet
> > being virtually "operational" [and manageable] from the start.
> >
> >   /Bernie\
> >             Bernie Cosell
> >        bernie at fantasyfarm.com
> > -- Too many people; too few sheep --
> >
> >
> >
> >
> > --
> > Internet-history mailing list
> > Internet-history at elists.isoc.org
> > https://elists.isoc.org/mailman/listinfo/internet-history
> >
> >
>
> --
> Geoff.Goodfellow at iconia.com
> living as The Truth is True
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>