MIT provides MULTICS source and documentation (DPS-8 simulation)
Roy J. Tellason
rtellason at verizon.net
Tue Nov 13 11:24:43 CST 2007
On Tuesday 13 November 2007 01:58, jim s wrote:
> Roy J. Tellason wrote:
> > On Monday 12 November 2007 17:24, Al Kossow wrote:
> >> > The I/O on a full blown system is where a modern system might have
> >> > emulation problems
> >> This is exactly where simulation has been hung up for years. The mass
> >> storage and terminal system is complex, with microcoded controllers for
> >> tape and disk and dedicated front end processors for terminal/network
> >> I/O.
> > This sort of thing is exactly the area where I'm fuzziest when it comes
> > to any sort of a real understanding of big iron. Aside from seeing
> > references to such stuff from time to time, I really don't have a clue
> > as to why you'd _want_ something like a separate dedicated processor to
> > handle I/O, for one example.
> The Multics system was designed to be scaled to very large numbers of
> processors and thousands of users.
That's the OS. And then there's the hardware, with which some stuff scales
well and some doesn't, and I'm still trying to figure out what the factors
are that get invovled in that.
> It was recognized that all of the tasks to handle the disk i/o which was
> very important to performance need not all go thru the processors in all
> Multics was a virtual memory system. The nature of this sort of system
> was researched by students at MIT and ideas to enhance performance showed
> that a lot of the activities could be carried out by subsystems which were
> dedicated to just the specific task of moving data to and from the memory.
This is where I get a little puzzled sometimes. Like that BB2 I mentioned,
that uses DMA to send a string of bytes to the disk controller chip rather
than using the processor to do those transfers. Why is not immediately
apparent to me since the processor isn't doing anything else at that point
> Early systems also had three level storage systems which incorporated a
> swapping drum to allow the same performance of a large amount of core memory
> w/o having the actual core available by swapping user spaces to the drum.
> Disk was sufficiently fast to allow the virtual memory approach to start to
> be used in a timesharing system, but not fast enough to match the drum
> storage performance.
A lot of the early textbooks I was able to get my hands on (mostly the sorts
you could find in a public library) mentioned drum storage, but they never
really got into the performance and capacity comparisons between those and
disk. And then there was mention briefly of those systems that had multiple
fixed heads for R/W rather than moving a single one -- I believe some of the
DEC literature I got my hands on back when also talked about such devices,
but I never really saw hard numbers to be able to compare them. Never
actually saw a drum or a system that used one, either...
> When the system I worked on was configured the threshold was crossed and
> the USL Multics system was configured with no drum and a large (1 or 2mb I
> think) or memory rather than a drum.
Speaking of crossing a threshold I can still remember years ago, when the
only computer I had was my Osborne Executive, and I was sitting there using
Wordstar, and hit the point where the file I was working on would no longer
fit completely within memory. The transition was so completely seamless and
transparent to me as the user I was impressed. :-)
And on this current linux box, it continues... Though when I run out of
swap, thats another story. It's still pretty seriously robust, though.
> > Or mass storage. Or whatever.
> The communications front end handled a lot of the mundane tasks of
> interfacing with terminals and transmitted in streams of character data to
> and from the terminal rather than dealing withcharacter transfers.
> > And I really don't have that much of a handle on how the architecture of
> > those sorts of machines differs from the micros I'm familiar with. Even
> > that bit of time I got to spend with the Heath H11 was very alien to the
> > rest of what I'm familiar with.
> > I realize that I'll never get as familiar with some of this stuff as some
> > of you guys that have actually worked with it, but can any of you point
> > me toward some resources that might let me understand some of it better
> > than I do now?
> C. Gordon Bell's books are a good place to start. One oriented towards
> DEC systems is at
> This book which is online covers all computers for the time it was published
> and is very useful to read.
Looks like some reading material, there... :-)
> Also on that site is a listing of computer companies he compiled which
> is very useful if you can't quite think of the name of the computer company
> you have a part for. (off the subject but useful)
> I find his web site is useful in general to pour over for reading. The
> links above are from books he has had put online since going to work for
I'll have a look there when the downloads are finished. Thanks for the
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, a critter that can
be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters"
Information is more dangerous than cannon to a society ruled by lies. --James
More information about the cctalk