Tim Bradshaw <tfb(a)tfeb.org> writes on 17 Jan 2017 13:09 +0000
>> I think we've all lived in a wonderful time where it seemed like
>> various exponential processes could continue for ever: they can't.
For an update on the exponential scaling (Moore's Law et al), see
this interesting new paper:
Peter J. Denning and Ted G. Lewis
Exponential laws of computing growth
Comm. ACM 60(1) 54--65 January 2017
https://doi.org/10.1145/2976758
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
> One thing that I'm unclear about is why all this Arpanet work was not filtering more into the versions of Unix done at Bell Labs.
The short answer is that Bell Lbs was not on Arpanet. In the early
80s the interim CSNET gave us a dial-up window into Arpanet, which
primarily served as a conduit for email. When real internet connection
became possible, network code from Berkeley was folded into the
research kernel. (I am tempted to say "engulfed the research kernel",
for this was a huge addition.)
The highest levels of AT&T were happy to carry digital data, but
did not see digital as significant business. Even though digital T1
was the backbone of long-distance transmission, it was IBM, not
AT&T, that offered direct digital interfaces to T1 in the 60s.
When Arpanet came along MCI was far more eager to carry its data
than AT&T was. It was all very well for Sandy Fraser to build
experimental data networks in the lab, but this was seen as a
niche market. AT&T devoted more effort to specialized applications
like hotel PBXs than to digital communication per se.
Doug
I'm having a lot of fun with a virtual 11/94 and 2.11. What a lot of
excellent engineering!
It seems like an obvious project would be to adapt a newer pcc with ANSI
C support of some sort. Has this already been done? I'll take a look
if not.
Thanks,
Andy Valencia
p.s. The "less" in /usr/local doesn't seem to handle stty based TTY
geometry. I re-ported "less2" from comp.sources.unix and added this.
Somebody ping me if the mildly edited sources are of interest.
> From: Larry McVoy
> It is pretty stunning that the company that had the largest network in
> the world (the phone system of course) didn't get packet switching at
> all.
Actually, it's quite logical - and in fact, the lack of 'getting it' about
packets follows directly from the former (their large existing circuit switch
network).
This dates back to Baran (see his oral history:
https://conservancy.umn.edu/handle/11299/107101
pg. 19 and on), but it was still detectable almost two decades later.
For a variety of all-too-human reasons (of the flavour of 'we're the
networking experts, what do you know'; 'we know all about circuit networks,
this packet stuff is too different'; 'we don't want to obsolete our giant
investment', etc, etc), along with genuine concerns about some real issues of
packet switching (e.g. the congestion stuff, and how well the system handled
load and overload), packet switching just was a bridge too far from what they
already had.
Think IBM and timesharing versus batch and mainframe versus small computers.
Noel
> From: Warren Toomey
> Something I've been meaning to ask for a while: why Unix and octal on
> the PDP-11? Because of the DEC documentation?
Yeah, DEC did it all in octal.
> I understand why other DEC architectures (e.g. PDP-7) were octal: 18b
> is a multiple of 3. But PDP-11 is 16b, multiple of 4.
Look at PDP-11 machine code. Two-op instructions look like this (bit-wise):
oooossssssdddddd
where 'ssssss' and 'dddddd' (source and destination) have the same format:
mmmrrr
where 'mmm' is the mode (things like R, @Rn, etc) and 'rrr' is the register
number. All on octal boundaries. So if you see '010011' in a dump (or when
looking at memory through the front console switches :-), you know
immediately that means:
MOV R0, @R1
Much harder in hex... :-)
Noel
> From: Angelo Papenhoff
> The problem is that the function which did the savu was not necessarily
> the same as the function that does the retu, so after retu the function
> could have the call stack of a different function. As dmr explained,
> this worked with the PDP-11 compiler but not with the interdata
> compiler.
To put it slightly differently, in PDP-11 C all stack frames look identical,
but this is not true of other machines/compilers. So if routine A called
savu(), and routine B called aretu(), when the call to aretu() returned,
procedure B is still running, but on procedure A's stack frame. So on machines
where A's stack frame looks different from B's, hilarity ensues.
(Note that aretu() was significantly different from retu() - the latter
switched to a different process/stack, whereas aretu() did a 'non-local goto'
[technically, switched to a different stack frame on the current stack] in the
current process.)
> Note that Lions doesn't explain this either, he assumed that the
> difficulty was with with u_rsav and u_ssav .. (he probably wasn't that
> wrong though, it really is confusing, but it's just not what the comment
> refers to)
Right. There are actually _three_ sets of saved stack info:
int u_rsav[2]; /* save r5,r6 when exchanging stacks */
int u_qsav[2]; /* label variable for quits and interrupts */
int u_ssav[2]; /* label variable for swapping */
and it was the interaction among the three of them that I found very hard to
understand - hence my (incorrect) memory that the 'you are not' comment
actually referred to that, not the savu/aretu stuff!
Calls to retu(), the primitive to switch stacks/processes, _always_ use
rsav. The others are for 'non-local gotos' inside a process.
Think of qsav as a poor man's exception handler for process software
interrupts. When a process is sleeping on some event, when it is interrupted,
rather than the sleep() call returning, it wakes up returning from the
procedure that did the savu(qsav). (That last is because sleep() - which is
the procedure that's running when the call to aretu(qsav) returns - does a
return immediately after restoring the stack to the frame saved in qsav.)
And I've forgotten exactly how ssav worked - IIRC it was something to do with
how when a process is swapped out, since that can happen in a number of
ways/places, the stack can contains calls to various things like expand(),
etc; when it's swapped back in, the simplest thing to do is to just throw that
all away and have it go back to where it was just before it was decided to
swap it out.
Noel
> From: Tony Finch
This is getting a bit far afield from Unix, so my apologies to the list for
that. But to avoid dumping it in the Internet-History list abruptly, let me
answer here _briefly_ (believe it or not, the below _is_ brief).
> AIUI there were two major revisions to the IPv4 addressing architecture:
Not quite (see below). First, one needs to understand that there are two
different timelines for changes to addressing: in the hosts, and in the
routers (called 'gateways' originally). To start with, they were tied
together, but as of RFC-1122, they were formally separated: hosts no longer
fully understood the syntax/semantics of addresses, just (mostly) treated them
as opaque 32-bit quantities.
> subnetting (RFC 917, October 1994 ... RFC 950, August 1985), and
> classless routing (RFC 1519, September 1993)
Originally, network numbers were 8 bits, and the 'rest' (local) part was 24.
Mapping from IP addresses to physical network addresses was some with direct
mapping - ARP did not exist - the actual local address (e.g. IMP/Port) was
contained in the 'rest' field - each network had a document which specified
the mapping. (Which is part of the interoperability issue with old
implementations.)
As some point early on, it was realized that 8 bits of network number were not
enough, and the awful A/B/C kludge was added (it was dropped on the community,
not discussed before-hand). Subnetting was indeed the next change. Then the
host/router split happened.
Classless routing (which effectively extended addesses, for path-computation
purposes, to 32+N bits - since you couldn't look at a 32-bit IP address and
immediately tell which was the 'network' part any more, you _had_ to have the
mask as well, to tell you how many bits of any given address were the network
number) was more of a process than a single change - the inter-AS routing
(BGP) had to change, but so did IGP's (OSPF, IS-IS), etc, etc.
> originally called supernetting (RFC 1338, June 1992).
There was this effort called ROAD which produced RFC-1338 and 1519, and IIRC
there was an intermediate, involving blocks of network numbers (1338), and
that slowly evolved into arbitrary blocks (1519).
One should also note that the term "super-netting" comes from a proposal by
Carl-Hubert ("Roki") Rokitansky which did not, alas, make it to RFC. (His
purpose was different, but it used the same mechanism.) Alas, the authors of
1338/1519 failed to properly acknowledge his earlier work.
Noel
> From: Johnny Billquist
>> everyone working on TCP/IP heard about Version 4 shortly after the
>> June, 1978 meeting.
> Over a year before any documents said anything about it.
Incorrect. It's documented in IEN-44, June 1978 (written shortly after the
meeting, in the same month).
> I'm sure people were doing networking protocols and stuff earlier, but
> it wasn't the TCP/IP we know and talk about today
People were working on Unix in 1977, but it's not the same Unix we know and
talk about today. Does that mean it's not Unix they were working on?
>> there were working implementations (as in, they could exchange data with
>> other implementations) of TCP/IPv4 by January 1979 - see IEN 77.
^^
> But not TCP4 then.
I just specified that it was v4 (see above).
> thus, not interoperable with an implementation today
No, with properly-chosen addresses (because of the changes in address
handling), they probably would be.
Noel
> From: Paul Ruizendaal
> I guess by April 1981 (RFC777) we reach a point where things are
> specified to a level where implementations would interoperate with
> today's implementations.
Yes and no. Earlier boxes would interoperate, _if addresses on each end were
chosen properly_. Modern handling of addresses on hosts (for the 'is this
destination on my physical network' step of the packet-sending algorithm) did
not come in until RFC-1122 (October 1989); prior to that, lots of host code
probably tried to figure out if the destination was class A, B or C, etc, etc.
Also, until RFC-826 (ARP, November 1982) pretty much all the network
interfaces (and thus the code to turn the 'destination IP address' into an
attached physical network address, for the first hop) were things like ARPANet
that no longer exist, so you could't _actually_ fire up one of them unless you
do something like the 'ARPANet emulation' that the various PDP-10 simulators
use to allow old OS's running on them to talk to the current Internet.
> only if one accepts IEN54/55 as 'TCP/IP'
What are they, if not TCP/IP?
Not the modern variant, of course, but then again, nothing before the early
90's is truly 'modern TCP/IP'.
> IEN98 mentions a TCP3 stack done for Network Unix ... in 1978 by DTI /
> Gary Grossman.
I read this, BITD, but don't recall much about it. I was not impressed by the
coding style.
> at the same time it also uses old-style assignments ('=+' instead of
> '+='). Could this be "typesetter C"?
I don't know. IIRC, that compiler supported both styles. It had to have been a
later compiler than the one that came with V6, that didn't support longs. But
I don't recall any bug with long support in the typetter C compiler we had at
MIT.
> From the above I would support the moniker "first TCP/IP in C on Unix"
No. That clearly belongs to the DTI one. (The difference between V3 and V4,
while significant, aren't enough to make the DTI not 'TCP/IP in C for Unix'.)
If you want to say 'first V4TCP/IP in C for Unix', maybe; I'd have to look for
dates on the one done at MIT for V6, that may be earlier, but I don't think
so. (Check the minutes in the IEN's, that's probably the best source of data
on progress of the various implementations.)
> One thing that I'm unclear about is why all this Arpanet work was not
> filtering more into the versions of Unix done at Bell Labs.
Here's my _guess_ - ask someone from Bell for a sure answer.
You're using 20/20 hindsight. At that point in time, it was not at all obvious
that TCP/IP was going to take over the world.
There were a couple of alternatives for moving data around that Bell used -
Datakit, and UUCP - and they worked pretty well, and there was no reason to
pick up on this TCP/IP thing.
I suspect that it wasn't until LAN's became popular than TCP/IP looked like a
good thing to have - it fits very well with the capabilities most LANs had (in
term of the service provided to things attached to them). Datakit was its own
thing, and for UUCP you'd have to provide a reliable stream, and TCP/IP 'just
did that'.
Noel