Lawrence D'Oliveiro
2024-05-12 04:01:09 UTC
Another recent addition to Bitsavers is this little document
<http://bitsavers.trailing-edge.com/communications/ungermann-bass/Enslow_-_Initial_Experience_with_a_Local_Area_Network_198110.pdf>
from 1981, written at the Georgia Institute of Technology, reporting
on their experience with the “Net/One” LAN product from
Ungermann-Bass.
LANs were pioneering stuff in those days. UB were just starting out,
and they were using Georgia Tech as a testbed (hopefully charging them
little or nothing for the privilege).
Interesting that this idea of a “LAN” had no concept of peer-to-peer
connections between computers. Instead, it was purely about giving
access to a bunch of minicomputer-class machines (a VAX, a PDP-11/45,
some HP, Prime and IBM boxes) from users seated at a bunch of
different terminals. Instead of a dedicated serial line running from
one terminal to one computer, this new-fangled “LAN” thing provided a
multiplexor service on its single main cable running around the whole
network. Near each computer and each cluster of terminals, there was
an interface box with regular RS-232 serial connectors on it.
There is mention of using Ethernet as a physical connection medium in
place of their slower regular cabling. But there seems to be no
mention of how Xerox PARC were using their Ethernet to make
peer-to-peer connections.
Ah, looking again at one of the diagrams, the Prime machines are also
connected via their own proprietary LAN, and similarly the IBM ones
(token-ring?). And I see some other lines going directly between
certain pairs of minis.
Those interface boxes had Z-80 processors in them, acting purely as
interface controllers. Besides regular interface boxes, there was also
a “Network Administration Station” (used to handle network
configuration) and a “Network Development System” (on which the
customers could develop their own code to run on the network
processors).
Interestingly, the serial connection through the LAN was far from
fully transparent: there were ongoing problems with constraints on
configuring parity, particular control characters not being properly
transmitted through, and a BREAK indication being incorrectly turned
into an ASCII NUL character.
Also each network endpoint could only accept a single virtual-circuit
connection at a time. So if a particular machine used to have, say, 24
serial lines running from it before, it still had to have separate
connections to 24 ports on a nearby interface box (or boxes), so all
that was really saved was cabling.
The initial version of the software required users to type in
addresses of the services they wanted to connect to. Later a name
service was added; the appropriate endpoints had to be configured to
respond to broadcast name lookups for their own names. I guess the
nice thing about this decentralized approach (also used later in
AppleTalk) is that, if an interface box goes down, then the associated
names for those ports are automatically deregistered as well.
<http://bitsavers.trailing-edge.com/communications/ungermann-bass/Enslow_-_Initial_Experience_with_a_Local_Area_Network_198110.pdf>
from 1981, written at the Georgia Institute of Technology, reporting
on their experience with the “Net/One” LAN product from
Ungermann-Bass.
LANs were pioneering stuff in those days. UB were just starting out,
and they were using Georgia Tech as a testbed (hopefully charging them
little or nothing for the privilege).
Interesting that this idea of a “LAN” had no concept of peer-to-peer
connections between computers. Instead, it was purely about giving
access to a bunch of minicomputer-class machines (a VAX, a PDP-11/45,
some HP, Prime and IBM boxes) from users seated at a bunch of
different terminals. Instead of a dedicated serial line running from
one terminal to one computer, this new-fangled “LAN” thing provided a
multiplexor service on its single main cable running around the whole
network. Near each computer and each cluster of terminals, there was
an interface box with regular RS-232 serial connectors on it.
There is mention of using Ethernet as a physical connection medium in
place of their slower regular cabling. But there seems to be no
mention of how Xerox PARC were using their Ethernet to make
peer-to-peer connections.
Ah, looking again at one of the diagrams, the Prime machines are also
connected via their own proprietary LAN, and similarly the IBM ones
(token-ring?). And I see some other lines going directly between
certain pairs of minis.
Those interface boxes had Z-80 processors in them, acting purely as
interface controllers. Besides regular interface boxes, there was also
a “Network Administration Station” (used to handle network
configuration) and a “Network Development System” (on which the
customers could develop their own code to run on the network
processors).
Interestingly, the serial connection through the LAN was far from
fully transparent: there were ongoing problems with constraints on
configuring parity, particular control characters not being properly
transmitted through, and a BREAK indication being incorrectly turned
into an ASCII NUL character.
Also each network endpoint could only accept a single virtual-circuit
connection at a time. So if a particular machine used to have, say, 24
serial lines running from it before, it still had to have separate
connections to 24 ports on a nearby interface box (or boxes), so all
that was really saved was cabling.
The initial version of the software required users to type in
addresses of the services they wanted to connect to. Later a name
service was added; the appropriate endpoints had to be configured to
respond to broadcast name lookups for their own names. I guess the
nice thing about this decentralized approach (also used later in
AppleTalk) is that, if an interface box goes down, then the associated
names for those ports are automatically deregistered as well.