Re: TCP adoption in 1984

below

On Tue, May 5, 2026 at 10:03 AM Craig Partridge via Internet-history <
[email protected]> wrote:

> On Tue, May 5, 2026 at 7:35 AM Lawrence Stewart via Internet-history <
> [email protected]> wrote:
> >If I remember correctly, the Unibus Ethernet was a full hex card.
>
You remember correctly.


> >3COM board was made to fit in a multibus form factor, but only by making
> it half duplex (I think).

DIX (and earlier 3M) is ½ duplex by design.  Even if the transmitter and
receiver sections of the board operate independently, it only gives the
programmer the illusion that Ethernet is a full-duplex device. In fact, only
one packet may exist on the coaxial cable at a tIme.

>Van benchmarked various 10Mb Ethernet interfaces and showed them lacking.
>
Right.  Sadly, I remember that, and the effects caused much pain to the
system vendors.  The other thing he showed was the "gap" on the wire when
different boards switched modes, and few could either deliver or receive
back-to-back packets.  My memory is that until AMD released its AM7990
"Local Area Network Controller for Ethernet" (LANCE) chip, it was a huge
problem.


> Speaking of evolutions -- there was a huge jump in the availability of
> affordable systems during the 1980s. Remember the early SUN workstations
> were a custom CPU board using a Motorola 680x0 processor connected to a
> stock multibus, later VMEbus, and third-party interface cards.

IIRC, the three original players (at least in the Multibus space) were
3Com's 3C400, InterLAN NI1010, and Execlan's EXOS 101 and 102.  Both 3Com
and InterLAN created a common "Ethernet controller" board and then
interfaced that to the specific bus [Unibus or Multibus].  Both
designs had issues
in production systems.  The 3C100 scheme was a dual-ported memory, which
was expensive for the host (particuarly if you were running UNIX or
anything multitasking). And my memory is that it was a big sinner WRT to
back-to-back packets too.   I've always attributed their design to their Alto
experience, which was single-user.

InterLAN's NI2010 for the Unibus was the winner. At UCB, it became the
default controller for most of the vaxen.  But they really screwup the
multibus interface.  Its flaw was that it would interrupt the hosts and
then go into a childlike "who me" state.  Multibus was extremely short on
Interrupt vectors, so the different OS's from Apollo's Domain, Masscomp's
RTU, or Sun's SunOS all had a PDP-10-like interrupt skip chain so
interrupts could be shared.  Having the board not tell you that he just
interrupted you for something basically did not work well.

Execlan took a different tack than their competitors.  Their original
101/102 series had an onboard 8088.  They stuffed the IP/TCP stack into it,
so the host did not need it.  As a Real-Time system, this was extremely
attractive to us at Masscomp because most of the work was done on the
coprocessor, and we could ignore it when high-priority (real-time)
operations were running on the host.  The flaw was that the 68000 was
faster than the 8088, and our network performance was limited by how
quickly the 8088 could run the protocol stack.  The other stumbling block
was multi-homed hosts, since "IP" part of things was running on two
different coprocessors.  It was a clever but unattractive hack that made it
all work [credit Perry Flinn].

In 1984, they replaced the processor with an 80186, which was not only much
faster but also supported Intel-style DMA on their side of the bus.  They
called it their 200 series.  Of course, time had moved on, and we were now
using 68020s in the host, and we still had an issue where the network
controller was the bottleneck .  Eventually, using it as a smart controller
with the stack on board was offered as an option; we had a traditional BSD
stack inside of RTU, and many customers chose to use it as a very basic
controller with lots of buffering, which, IIRC, is how it was often sold
for Sun hardware.



> There were
> lots of copycats. By the late 1980s, most Computer Science departments on
> CSNET had internal Ethernets delivering email to individual desktops (so
> their link to the outside world was CSNET, or UUCP, or both over dialup
> lines, but internally they were running TCP/IP).  When NSFNET appeared,
> switching to full Internet connectivity was relatively easy. CSNET already
> used domain names so the primary problems were (1) renumbering (ugh, but
> doable) and (2) campus politics (was CS or campus IT in charge of the link,
> etc. [NSF's requirement that connectivity be offered throughout campus
> simplified that fight quite a bit]).
>
> Craig
>
> --
> *****
> Craig Partridge's email account for professional society activities and
> mailing lists.
> --
> Internet-history mailing list
> [email protected]
> https://elists.isoc.org/mailman/listinfo/internet-history
> -
> Unsubscribe:
> https://app.smartsheet.com/b/form/9b6ef0621638436ab0a9b23cb0668b0b?The%20list%20to%20be%20unsubscribed%20from=Internet-history
>
-- 
Internet-history mailing list
[email protected]
https://elists.isoc.org/mailman/listinfo/internet-history
-
Unsubscribe: https://app.smartsheet.com/b/form/9b6ef0621638436ab0a9b23cb0668b0b?The%20list%20to%20be%20unsubscribed%20from=Internet-history