Just as the topic of TUHS isn't 'how _I_ could/would build a _better_ OS', but
'history of the OS that was _actually built_' (something that many posters
here seem to lose track of, to the my great irritation), so too the topic
isn't 'how to build a better network' - or actually, anything network-centric.
I'll make a few comments on a couple of things, though.
> From: steve jenkin
> packet switching won over Virtual Circuits in the now distant past but
> in small, local and un-congested networks without reliability
> constraints, any solution can look good. ... Packet switching
> hasn't scaled well to Global size, at least IMHO.
The internetworking architecture, circa 1978, has not scaled as well as would
have been optimal, for a number of reasons, among them:
- pure scaling effects (e.g. algorithms won't scale up; subsystems which
handle several different needs will often need to be separated out at a larger
scale; etc)
- inherent lack of hindsight (unknown unknowns, to use Rumsfeld's phrase; some
things you only learn in hindsight)
- insufficiently detailed knowledge of complete requirements for a
global-scale network (including O+M, eventual business model, etc)
- limited personnel resources at the time (some things we _knew_ were going to
be a problem we had to ignore because we didn't have people to throw at the
problem, then and there)
- rapid technological innovation (and nobody's crystal ball is 100% perfect)
It has been possible to fix some aspects of the ca. 1978 system - e.g. the
addition of DNS, which I think has worked _reasonably_ well - but in other
areas, changes weren't really adequate, often because they were constrained by
things like upward compatibility requirements (e.g. BGP, which, among numerous
other issues, had to live with existing IP addressing).
Having said all that, I think your assertion that virtual circuits would have
worked better in a global-scale network is questionable. The whole point of
networks which use unreliable datagrams as a fundamental building block is
that by moving a lot of functionality into the edge nodes, it makes the
switches a lot simpler. Contemporary core routers may be complex - but they
would be much worse if the network used virtual circuits.
Something I suspect you may be unaware of is that most of the people who
devised the unreliable datagram approach of the internetworking architecture
_had experience with an actual moderately-sized, operational virtual circuit
network_ - the ARPANET. (Yes, it was basically a VC network. Look at things
like RFNMs, links {the specific ARPANET mechanism referred to by this term,
not the general concept}, etc.) So they _knew_ what a VC network would
involve.
So, think about the 'core routers' in a network which used VC's. I guess a
typical core router tese days uses a couple of OC768 links. Assume an average
packet size of 100 bytes (probably roughly accurate, with the bimodal
distribution between data and acks). With 4 OC768's, that's 4*38.5G/800 =
~155M packets/second. I'm not sure of the average TCP connection length in
packets these days, but assume it's 100 packets or so (that's a 100KB Web
object). That's still roughly _1 million cicuit setups per second_.
If the answer is 'oh, we'll use aggregation so core routers don't see
individual connections - or their setup/tear-down' - well, the same
can be done with a datagram system; that's what MPLS does. Work
through the details - VCs were not preferred, for good reasons.
> Ethernet only became a viable LAN technology with advent of Twisted
> pair: point to point + Switches.
It's really irritating that a lot of things labelled 'Ethernet' these days
_aren't_ _real_ Ethernet (i.e. a common broadcast bus allocated via CSMA-CD).
They use the same _packet format_ as Ethernet (especially the 48-bit
globally-unique address, which can usefully be blown into things at
manufacture time), but it's not Ethernet. In some cases, they also retain the
host interface<->network physical interface - but the thing on the other side
of the interface is totally different (such as the hub-based systems commmon
now - as you indicate, it's a bunch of small datagram packet switches plugged
together with point-point links).
Interfaces are forever; like the screw in light-bulb. These days, it's likely
an LED bulb on one side, powered by a reactor on the other - two technologies
which were unforseen (and unforseeable) when the interface was defined, well
over 100 years ago.
Noel
On Tue, Jun 21, 2022 at 05:56:02PM -0600, Jacob Moody wrote:
> I recently stumbled across the existence of datakit
> when going through the plan9foundation source archives.
> Would be curious to hear more about its involvement
> with plan9.
There are at least 2 versions of Datakit. I my current understanding there are “Datakit” which is the research version, and “Datakit II” which seems to be the version that was broadly deployed into the AT&T network in the late 80’s -- but very likely the story is more complicated than that. Plan9 is contemporaneous with Datakit II.
In short, Sandy Fraser developed the “Spider” network in 1970-1974 and this was actively used with early Unix (at least V4, maybe earlier). Sandy was dissatisfied with Spider and used its learnings to start again. The key ideas seem to have gelled together around 1977 with the first switches being available in 1979 or so. The first deployment into the Bell system was around 1982 (initially connecting a handful of Bell sites).
In 1979/1980 there were two Datakit switches, one in the office of Greg Chesson who was writing the first iteration of its control software, and one in the office/lab of Gottfried Luderer et al., who used it to develop a distributed Unix.
Datakit at this time is well described in two papers that the ACM recently moved from behind its paywall:
https://dl.acm.org/doi/pdf/10.1145/1013879.802670 (mostly about 1980 Datakit)
https://dl.acm.org/doi/pdf/10.1145/800216.806604 (mostly about distributed Unix)
The Chesson control software was replaced by new code written by Lee McMahon around 1981 (note: this is still Datakit 1). The Datakit driver code in V8 is designed to work with this revised Datakit. Three aspects of Datakit show through in the design the V8-V10 networking code:
- a separation in control words and data words (this e.g. comes back in ‘streams')
- it works with virtual circuits; a connection is expensive to set up (‘dial’), but cheap to use
- it does not guarantee reliable packet delivery, but it does guarantee in-order delivery
Probably you will see echoes of this in early Plan9 network code, but I have not studied that.
> From: Paul Ruizendaal
> it would seem to me that Sandy had figured out a core problem some 30
> years before the TCP/IP world would come up with a similar solution. I
> would not even be surprised if I learned that modern telco routers
> transparantly set up virtual circuits for tcp traffic.
To fully explore this topic would take a book, which I don't have the energy
to write, and nobody would bother to read, but...
Anyway, I'm not upon the latest and greatest high-speed routers: I saw some
stuff from one major vendor under NDA about a decade ago, but that's my most
recent - but at that point there was nothing that looked even _vaguely_ like
virtual circuits. (The stuff Craig was alluding to was just about
connectivity for getting bitts from _interface_ to _interface_ - if you don't
have a giant crossbar - which is going to require buffering on each input
anyway - how exactly do you get bits from board A to board Q - a single
shared bus isn't going to do it...)
A problem with anything like VC's in core switches is the growth of per-VC
state - a major high-speed node will have packets from _millions_ of TCP
connections flowing through it at any time. In the late-80's/early-90's - well
over 30 years ago - I came up with an advanced routing architecture called
Nimrod (see RFC-1992, "The Nimrod Routing Architecture"; RFC-1753 may be of
interest too); it had things called 'flows' which were half way between pure
datagrams (i.e. no setup - you just stick the right destination address in the
header and send it off) and VCs (read the RFCs if you want to kow why), and it
went to a lot of trouble to allow flow aggregation in traffic going to core
switches _precisely_ to limit the growth of state in core switches, which
would have traffic from millions of connections going through them.
I have barely begun to even scratch the surface, here.
Noel
I’ve been wondering about the growth of Unix and if there’s any good data available.
There’s the Early Unix Epoch, which probably ends with the Unix Support Group assuming the distribution role, plus providing / distributing their version of the code.
Later there’s commercial Unix:
System III and System V, I guess.
BSD, until the lawsuit was resolved, required a Source code license, but their installation count is important in pre-Commercial Unix.
Large licensees like SUN, HP & IBM (AIX) may not have published license counts for their versions - but then, were their derivatives “Unix” or something else?
Warner Loch’s paper has data to around 1978 [below].
I’ve no idea where to find data for USG issued licences, or if the number of binary & source licences were ever reported in the Commercial Era by AT&T.
I’ll not be the first person who’s gone down this road, but my Search Fu isn’t good enough to find them.
Wondering if anyone on the list can point me at resources, even a bunch of annual reports.
I don’t mind manually pulling out the data I’m interested in. But why reinvent the wheel if the work is already done?
steve
===============
numbers extracted from Warner Loch’s paper.
<https://papers.freebsd.org/2020/FOSDEM/losh-Hidden_early_history_of_Unix.fi…>
2nd Edn June 1972 10 installations
3rd Edn February 1973 16
4th Edn November 1973 >20, or 25
July 74 CACM paper "Unix Time Sharing System” after which external interest exploded
6th Edn 1975 ???
7th Edn March 1978 600+, >300 inside Bell System, "even more have been licensed to outside users”
===============
--
Steve Jenkin,
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA
mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin
> From: Dan Cross
> I believe that's actually a menu
Hence the "erroneous _impression_" (emphasis added).
I'm curious as to how they decided which models to run which editions on.
Although V4 _ran_ on the /45, split I+D wasn't supported - for user or kernel
- until V6. (I'm assuming a number of things - both in the kernel, and
applications - started hitting the 64KB limit, which led to its support.)
Speaking of split I+D, there's an interesting little mystery in V6 that at
one point in time I thought involved split I+D - but now that I look closely,
apparently not. The mystery involves a 'tombstone' in the V6 buf.h:
#define B_RELOC 0200 /* no longer used */
I had created (in my mind) an explanation what this is all about - but now
that I look, it's probably all wrong!
My explanation involves the slightly odd layout of the kernel in physical
memory, with split I+D; data below the code, at physical 0. This actually
makes a lot of sense; it means the virtual address of any data (e.g. a
buffer) is the same as its physical address (needed for DMA). It does require
the oddness of 'sysfix', to invert the order of code+data in the system
binary, plus odd little quirks in the assembler startup (e.g. copying the
code up to make room for BSS).
So I thought that B_RELOC was a hangover from a time, at the start of split
I+D, when data _wasn't_ at physical 0, so a buffer's virtual and phsyical
addresses differed.
But that must be wrong (at least in any simple way). B_RELOC was in buf.h as
of V4 - the first kernel version in C - with no split I+D. So my theory has
to be wrong.
However, I am unable to find any code in the V4 kernel which uses it! So
unless someone who remembers the very early PDP-11 kernel can enlighten us,
its purpose will always remain a mystery!
Noel
> From: Paul Ruizendaal
> [c] Fifth Edition UNIX PDP-11/40 June 1974
> [d] Sixth Edition UNIX PDP-11/45 May 1975
> [e] Seventh Edition UNIX PDP-11/70 January 1979
This table gives an erroneous impression of which versions supported which
PDP-11 models. 4th Edition supported only the /45; 5th Edition added support
for the /40; and the /70 appeared in 6th edition.
Noel
Sandy Fraser died June 13. The moving spirit behind Datakit, Sandy
served as director then executive director responsible for computing
science at Bell Labs in the era of v8, v9, and v10. He became VP at
AT&T Shannon Labs after the split with Lucent.
Doug
Excited as I was to see this history of Unix code in a single repository:
https://github.com/dspinellis/unix-history-repo
it continues the long-standing tradition of ignoring all the work done at
Bell Labs after v7. I consider v8 v9 v10 to be worth of attention, even
influential, but to hear this list talk about it - or discussions just
about anywhere else - you'd think they never existed. There are exceptions,
but this site does reinforce the broadly known version of the story.
It's doubly ironic for me because people often mistakenly credit me for
working on Unix, but I landed at the Labs after v7 was long dispatched. At
the Labs, I first worked on what became v8.
I suppose it's because the history flowed as this site shows, with BSD
being the driving force for a number of reasons, but it feels to me that a
large piece of Unix history has been sidelined.
I know it's a whiny lament, but those neglected systems had interesting
advances.
-rob
While I know that there are people here who like good old ed...I've been playing with UTS under VM/370. This version is from 1981 and I think it's v7. But the important thing is that Tom Lyon wrote a 3270 terminal driver, and it comes with ned, which is a screen editor that feels a lot like XEDIT--which wasn't even in CMS at that point, although EE has been added to the VM370 Community Edition I'm using. And the man pages are fullscreen as well.
UTS is very, very usable because of that. This really is a wonderful terminal driver.
So, thank you, Tom!
Adam
> I don't know the exact history of RFS a la System V, but I
> don't think it was Peter Weinberger's stuff, and it certainly
> wasn't his code.
Peter’s code is available in the V8 and V9 trees on TUHS.
The Sys V repositories on Github appear to include RFS code in all of R3.0, R3.1 and R3.2.
At first glance, it seems quite different from the V8/V9 code.
> Peter, being a self-described fan of cheap hacks, also wasn't
> inclined to spend much time thinking about general abstractions;
> in effect he just turned various existing kernel subroutines
> (when applied to a network file system) into RPCs. The
> structure of the file system switch was rather UNIX-specific,
> reflecting that.
Yes, well put. I’ve back ported his filesystem switch to V6/V7 and it is very light touch: on the PDP11 it added only some 500 bytes of kernel code (after some refactoring).
With hindsight it seems such a logical idea, certainly in a context where the labs were experimenting with remote system calls in the mid 70’s (Heinz Lycklama's work on satellite Unix) and early 80’s (Gottfried Luderer et al. on distributed Unix — another forgotten version). It is such a powerful abstraction, but apparently very elusive to invent.
Paul
