<div dir="ltr">Yes, Unix was inspired by Multics, and borrowed much -- Dennis Ritchie was Bell's person at MIT MAC until they withdrew (and Mike Padlipsky's officemate iirc); originally spelled Unics, meaning "One of whatever Multics is many of" (or a castrated Multics).<div>

<br><div>(The shell having syntax that made pipes scriptable rather than only being compiled as in Multics was the major advance in Bell Unix; other differences from were scaling back.)</div><div style><br></div><div style>

( Multics directly influenced VMS and PR1MOS as well; most other OS's were indirectly influenced. )</div></div><div style><br></div><div style>-- Bill </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">

On Wed, Apr 17, 2013 at 10:30 PM, Jack Haverty <span dir="ltr"><<a href="mailto:jack@3kitty.org" target="_blank">jack@3kitty.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Tony,<br>
<br>
Thanks for that link!  I downloaded the book and it appears to be the<br>
kind of content I remember (level of detail about kernel innards).<br>
That plus the source code was enough to start the project to create a<br>
TCP implementation back in 1977.<br>
<br>
What I recall using wasn't a book, but more like a set of notes for a<br>
class or tutorial.  That correlates with the book, which says in the<br>
introduction that the book is the descendant of class notes for an<br>
operating system course taught in 1976-77.  I probably had a copy of<br>
those notes, which ARPA had somehow obtained.   I don't remember that<br>
Australia was on the ARPANET for FTPing.  The Unix kernel code came<br>
from ATT of course, through ARPA.  But it pretty much matched the code<br>
described in Lions material.<br>
<br>
I thought it was "University of Wollongong", but University of New<br>
South Wales is probably the right source.   Hey, at least I remembered<br>
the right continent..... Ahah, a little googling reveals that<br>
University of Woolongong is in New South Wales, Australia and seems to<br>
be a subsidiary of University of NSW.<br>
<br>
/Jack<br>
<br>
PS - Since this is the "internet history" mailing list, perhaps I<br>
should capture a bit of the history of the Internet and Unix, since I<br>
was there when the two came together.  So, while I still remember,<br>
here's some more details in case someone's ever interested in the<br>
collision of Unix and TCP at the start of The Internet.<br>
<br>
As I said in an earlier message, I got the assignment to create a TCP<br>
running on a PDP-11/40 under Unix, sometime in the second half of<br>
1977.   That TCP was a "version 2.5" TCP, which I implemented on that<br>
11/40 and subsequently evolved to TCP4.  The work was done under one<br>
of Vint's contracts at ARPA, as I believe were most or maybe all of<br>
the other implementations.   Postel's report on the first "TCP<br>
Bakeoff" is a good reference to identify the set of early<br>
implementations that first managed to talk with each other rather than<br>
just themselves.<br>
<br>
The PDP-11/40 ran a variant of Unix V6 -- e.g., it had the "Rand<br>
ports" extensions.  That particular model PDP11 was very memory<br>
constrained - 32K of address space.  So the whole kernel, instructions<br>
and data, had to fit in 32K.  Other models, e.g., PDP11/45 and<br>
PDP11/70, had twice the memory address space, by "i/d separation"<br>
which put instructions and data into separate address spaces.  But the<br>
PDP11/40 had no "elbow room".   Definitely coach class networking.<br>
<br>
Randy Rettberg and I, both at BBN, took the TCP/Unix challenge.  We<br>
were both Unix neophytes.  After figuring out what we could (Lion's<br>
notes were a great help), we still didn't see any clean way to<br>
construct the common kinds of network programs inside the Unix<br>
environment.  In particular, it didn't seem possible to write a<br>
program that could serve a duplex information flow, where you couldn't<br>
predict from which direction the next piece of data would come.  I.E.,<br>
when the program was ready to go into an idle state and wait for more<br>
work to do, you could issue a "read" call to the kernel, specifying a<br>
file descriptor, and it would hang until data was available from that<br>
"file".  But if you picked the "wrong" fd to wait on for input, your<br>
program would wait forever.  How would a "telnet" program, for<br>
example, know whether its local human user would type another<br>
character next, or its remote partner across the net would send the<br>
next character for output to that user terminal.   There may have been<br>
a way to do this in Unix of the era, but we neophytes couldn't see it.<br>
 Networking didn't seem to fit the Unix "concatenation of pipes"<br>
paradigm where input flows unidirectionally to output.<br>
<br>
We invented a very, very simple mechanism to enable a process to wait<br>
on any of several file descriptors, and to also determine how much<br>
could be read or written without causing the system call to hang<br>
waiting for more data than what was already in the kernel buffers.<br>
Those were the AWAIT and CAPAC system calls, which we added to the<br>
kernel.   There was actually a paper about this in 1978 -- J. F.<br>
Haverty, R. D. Rettberg, “Inter-process Communication for a Server in<br>
UNIX," Proceedings Compcon 78, September 1978, pp. 312-315.   With<br>
AWAIT and CAPAC added to the kernel, it was possible to then write<br>
networking software.  Later primitives, e.g., "sockets", provided<br>
similar mechanisms but with richer functionality.<br>
<br>
Adding those primitives to the kernel was a real challenge.  The<br>
kernel memory was full, at least with the 32K limitation of the 11/40.<br>
  Adding any new functionality meant you had to remove something else<br>
to make room, or find some place to optimize and squeeze out a few<br>
words of space.   The guys at Bell Labs were very good coders -- not<br>
much fat to trim.   I recall poring through the kernel listing,<br>
searching for places to optimize, and mostly finding space by taking<br>
out some "panic" code --- code that checked something and halted the<br>
processor if things were bad.  You did what you had to do....and this<br>
is why the AWAIT/CAPAC primitives were so primitive -- absolute<br>
minimum new kernel code.<br>
<br>
After struggling with AWAIT and CAPAC, which had to be in the kernel,<br>
it was pretty clear that there was no way to shoehorn a TCP<br>
implementation in there too.  So the TCP itself also had to be in user<br>
space - a separate user process that communicated with the kernel to<br>
interact with the ARPANET/1822 hardware in a full-duplex fashion, and<br>
communicated full-duplex with TCP user's processes (e.g., a Telnet<br>
program) by using multiple Rand ports.<br>
<br>
I started with Jim Mathis' TCP implementation for MOS that was in use<br>
on LSI11 systems.  It was written in Macro-11, so it was compatible<br>
with the PDP11/40, and "simply" had to be restructured to fit in the<br>
Unix world and then changed as we changed the TCP definition.  That's<br>
what I did.  This all happened in the late 1977 timeframe, while<br>
others were also working on TCPs -- Bill Plummer, Bob Braden, Dave<br>
Clark, et al.  We were also simultaneously changing the definition of<br>
TCP, e.g., splitting into TCP and IP, changing header formats and<br>
state diagrams, etc., as part of going from TCP2 to TCP4 through many<br>
intermediate stages.<br>
<br>
Life was not wonderful though.  I recall getting the 11/40 TCP finally<br>
to the state that it could open a connection, to itself, and send<br>
data.  So I rigged up a quick performance test, sending a large<br>
convenient text file (probably the source code) through a TCP<br>
connection, looking at my watch, and then dividing to compute the<br>
throughput.<br>
<br>
That first TCP was blazing away at an average of 11 bits/second ....<br>
yes, bits.   I did the math twice.  Embarassing.  It couldn't keep a<br>
model 33 teletype busy.  I could write good code, or so I thought.<br>
<br>
More diving into the system to see where the time was going.<br>
Profiling indicated that more than 95% of the time was spent inside<br>
system calls involving I/O through pipes/ports.  Making my code<br>
infinitely efficient could only hope to get a 5% improvement.  So it<br>
was back into the Unix kernel listing to see what was happening.<br>
<br>
After much poking around, I remember finding the offending code.   I<br>
can't recall whether it was pipes or ports or both, but the<br>
implementation of that mechanism was basically a tiny wrapper around<br>
the general file I/O code.  A pipe/port was essentially a standard<br>
file, with a "read pointer" and a "write pointer" showing where the<br>
input and output was stopped at the moment.  A bit of code made sure<br>
the reader never got in front of the writer, and another bit of code<br>
held both sides up when the file hit a certain length (4096 bytes<br>
IIRC); when the reader caught the writer at that position, the file<br>
was truncated back to 0 length and I/O resumed from there.  It was<br>
basically just a 4K FIFO, with a file descriptor attached to each end<br>
and "control" that every 4K stopped the writer to wait for the reader<br>
to catch up and then clear the FIFO.<br>
<br>
The problem was that, since it was built on top of the regular file<br>
system, the rest of the system didn't know that the underlying file<br>
was about to be truncated.  There was no notion of "truncating" a<br>
file.  So the kernel viewed that 4K of file data as being "dirty" and<br>
in need of writing out to the physical disk before allowing any<br>
further activity on that file.  So all network traffic had to be<br>
written to disk as well.  With the limited physical memory it was<br>
maybe even taking detours to the swap file.  We had a slow "cartridge"<br>
disk.<br>
<br>
Result -- 11 bits per second TCP performance.<br>
<br>
Some more kernel hacking and "panic removal" made some space to make<br>
the pipe/port mechanism somewhat more efficient, and got the TCP to<br>
the point that we could use it in the projects which needed it.<br>
<br>
Subsequently we argued, successfully, that a PDP11/40 wasn't a good<br>
choice for this kind of thing, and the newer /45 and /70 were better.<br>
In those machines, there was a lot more space - a whole additional 32K<br>
for instructions and data, so it was feasible to put the TCP<br>
implementation into the kernel.  As I recall Mike Wingfield and Al<br>
Nemeth subsequently worked on that for the PDP-11/70, and Rob Gurwitz<br>
for the Vax, all at BBN under various ARPA or DCA contracts.  The<br>
Macro-11 user-space TCP that I wrote for Unix on the 11/40 was<br>
thankfully and quickly abandoned.<br>
<br>
And that's the way it was, circa 1977-78 in the early days of The<br>
Internet and the Unix system...<br>
<br>
Hope this helps some Internet and Unix historians,<br>
/Jack Haverty<br>
April 17, 2013<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
<br>
<br>
On Wed, Apr 17, 2013 at 3:37 AM, Tony Finch <<a href="mailto:dot@dotat.at">dot@dotat.at</a>> wrote:<br>
> Jack Haverty <<a href="mailto:jack@3kitty.org">jack@3kitty.org</a>> wrote:<br>
>><br>
>> The only document about Unix internals I recall finding (in 1978) was<br>
>> from the University of Wollongong (Australia), where someone had<br>
>> written up a nice description of the architecture of the kernel and<br>
>> the software structure, data, etc.  Very, very helpful in getting that<br>
>> TCP running.   I guess Wollongong was far enough away from AT&T to not<br>
>> be worried.<br>
><br>
> Are you referring to the Lions book?<br>
> <a href="http://www.lemis.com/grog/Documentation/Lions/" target="_blank">http://www.lemis.com/grog/Documentation/Lions/</a><br>
><br>
> Tony.<br>
> --<br>
> f.anthony.n.finch  <<a href="mailto:dot@dotat.at">dot@dotat.at</a>>  <a href="http://dotat.at/" target="_blank">http://dotat.at/</a><br>
> Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.<br>
> Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,<br>
> occasionally poor at first.<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Bill<br>@n1vux <a href="mailto:bill.n1vux@gmail.com" target="_blank">bill.n1vux@gmail.com</a>
</div>