Fear of Multiprocessing?
Bruce James Robert Linley
Is it just me or is there a fear on the part of the big chip makers
of multiprocessor desktop machines becoming cheap? As an example, Intel
has been wildly slashing prices on all of it's Pentium chips over the
last year *except* for one. The Pentium Pro- the only one that will
work in groups of more than two CPUs. Now it's been discontinued. Yet
it still has not dropped in price comparable to the rate at which other
discontinued CPUs have dropped. Do Cyrix, AMD, etc., have a drop in
substitute for the PPro? PPro development was quietly halted until the
chip was abandoned without an immediate successor. Very wierd.
I think that the chip makers do not want multiprocessor machines to
get cheap. I think they want to keep all of us salivating over the
latest, greatest, umpteem bazillion MHz processor to keep us from
realizing that many cheap processors working in parallel would
actually outperform a single fast CPU *and* do it for less money.
Granted, not a lot of consumer-obtainable OSs support multiple CPUs
(only NT?) or do so only in experimental OS versions (Linux 2.1.x).
If they did, demand for such boxes might go up. It's kind of a catch
22 here. While Linux, because of it's nature, is able to buck against
the conspiracy, a lack of multi-CPU support in the hardware can hurt
Linux's development in this area. Yes, even Linux, despite its open
source and collaborative nature, is still at the mercy of the chip
makers to a large extent.
Intel also broke its own trend of multiple CPU support. 486s and earlier
worked only as single CPU machines, Pentiums could work in pairs, though
this is was seldom exploited due to lack of OS support. PPro could work
in groups of up to 8 CPUs. So what's Intel's next step? PentiumIIs that
can work in... *smack*... back down to 1 or 2 CPU configurations. Oh
sure we have Slot 2 coming that will do more, but that will be priced
far above what the desktop PC buyer can ever afford. Further, I fully
expect Slot 2 CPUs to disappear altogether with no competitive
replacement, no successor, and for the remaining supply to stay priced
high until the supply dwindled just like the PPro is doing now.
Maybe I'm just being paranoid, but it's a massive global conspiracy! :)
--
Bruce James Robert Linley | +---+---+--_ | "Tea is always bitter... but
lin...@netcom.com | | |NV | UT | blood is warm and sweet."
Programmer, Fortunet Inc. | \ CA \ |___ |
Las Vegas, Nevada, USA ----------> \*| AZ | - Miyu
Tim Shoppa
In article <linleyEs...@netcom.com>,
Bruce James Robert Linley <lin...@netcom.com> wrote:
>Is it just me or is there a fear on the part of the big chip makers
>of multiprocessor desktop machines becoming cheap? As an example, Intel
>has been wildly slashing prices on all of it's Pentium chips over the
>last year *except* for one. The Pentium Pro- the only one that will
>work in groups of more than two CPUs. Now it's been discontinued.
You're suffering from "all the world's a desktop PC-clone" syndrome.
While there certainly are a few areas in which a desktop PC-clone
multiprocessing is appropriate (notably, areas where raw instructions
per second is the main goal), it's very difficult to get the required
I/O and memory bandwidth into a desktop box so that more typical real-world
applications can be run on the machine.
Enlarge your breadth a little and you'll see there's a rich array
of options for multiprocessing from all the major non-PC-clone
manufacturers, all of which address real-world applications more
closely by addressing memory and I/O bandwidth limitations appropriately.
Most notably, you might want to look at the DEC Alpha chips in
Galaxy configurations, building on deades of experience with VMSCluster
and SMP technology.
>Granted, not a lot of consumer-obtainable OSs support multiple CPUs
>(only NT?) or do so only in experimental OS versions (Linux 2.1.x).
Again, you're limiting yourself to "desktop PC-clone OS's". Expand
your view a little and you'll find that many manufacturers have been
paying close attention to this for decades, often with the goal of
making multiprocessing affordable to the smaller users.
Tim. (sho...@triumf.ca)
R!ch
On Fri, 1 May 1998, Bruce James Robert Linley wrote:
> Granted, not a lot of consumer-obtainable OSs support multiple CPUs
> (only NT?) or do so only in experimental OS versions (Linux 2.1.x).
Solaris 2.x supports multiple CPUs (up to 64 in fact). My SPARC 20
desktop supports up to four CPUs, although it currently only has 2.
I think you need to realize that there's more to computers than
just IBM peecee clones. In fact peecees are at the bottom of
the food chain.
--
R!ch Teer
If it ain't analogue, it ain't music.
Richard Teer richar...@rkdltd.demon.co.uk
Risc Key Developments Ltd
Voice: +44 (0)1256 330612
WWW: www.rkdltd.demon.co.uk
Peter van Hooft
In <Pine.SOL.3.96.980503182552.548A-100000@zen> R!ch <ri...@rkdltd.demon.co.uk> writes:
>On Fri, 1 May 1998, Bruce James Robert Linley wrote:
>> Granted, not a lot of consumer-obtainable OSs support multiple CPUs
>> (only NT?) or do so only in experimental OS versions (Linux 2.1.x).
>Solaris 2.x supports multiple CPUs (up to 64 in fact). My SPARC 20
>desktop supports up to four CPUs, although it currently only has 2.
I think most (all?) Unix implementations have SMP support nowadays, and
some have had for years. And Linux supports multiple cpu's in 2.0.x as
well.
peter
Tom Van Vleck
Huw Davies wrote:
> Of more folklore type interest, what were the early commercial multiprocessor
> machines? (By commercial, I mean sold in commercial quantities - say
> more than 10 :-)
Honeywell 6180. I don't think the GE-645 makes the cutoff.
Huw Davies
Bruce James Robert Linley (lin...@netcom.com) wrote:
: Granted, not a lot of consumer-obtainable OSs support multiple CPUs
: (only NT?) or do so only in experimental OS versions (Linux 2.1.x).
: If they did, demand for such boxes might go up. It's kind of a catch
: 22 here.
Of more folklore type interest, what were the early commercial multiprocessor
machines? (By commercial, I mean sold in commercial quantities - say
more than 10 :-)
My first experience was with an 11/782 so that's only early '80s. I guess
the CDC6600 sort of counts, although the I/O processors weren't usually
used to run user code....
--
Huw Davies | e-mail: Huw.D...@latrobe.edu.au
Information Technology Services | Phone: +61 3 9479 1550 Fax: +61 3 9479 1999
La Trobe University | "My Alfas keep me poor in a monetary
Melbourne Australia 3083 | sense, but rich in so many other ways"
Williams, Steve
How about Univac 1108? Up to 3 CPUs and two dedicated I/O processors.
Around 1966 for the MP version, I think.
On the other hand, The Univac LARC (completed when? 1958?) also had
multiple CPU and I/O processors. However, much as Univac would have
liked to, I don't think they managed to sell 10 of them.
jmfb...@ma.ultranet.com
In article <6ij8f5$4nr$1...@news.latrobe.edu.au>,
cc...@lucifer.its.latrobe.edu.au (Huw Davies) wrote:
>Bruce James Robert Linley (lin...@netcom.com) wrote:
>
>: Granted, not a lot of consumer-obtainable OSs support multiple CPUs
>: (only NT?) or do so only in experimental OS versions (Linux 2.1.x).
>: If they did, demand for such boxes might go up. It's kind of a catch
>: 22 here.
>
>Of more folklore type interest, what were the early commercial
>multiprocessor machines? (By commercial, I mean sold in commercial
>quantities - say more than 10 :-)
>
>My first experience was with an 11/782 so that's only early '80s. I guess
>the CDC6600 sort of counts, although the I/O processors weren't usually
>used to run user code....
TOPS10 (a timesharing OS run on PDP-10s) had master/slave CPU support
since 1070ish or so (I don't remember the announcement year). In
the late 70s, JMF and TW (the primary TOPS10 developers then) designed
something that we called SMP (symmetric multi-processing--not to be
confused with today's use of the term); officially this OS software
supported 3 CPUs. We did have a site that ran with five.
/BAH
Alan Bowler
In article <thvv-03059...@thvv.vip.best.com> th...@best.com (Tom Van Vleck) writes:
>Huw Davies wrote:
>> Of more folklore type interest, what were the early commercial multiprocessor
>> machines? (By commercial, I mean sold in commercial quantities - say
>> more than 10 :-)
>
Why not? There certainly were multiprocesor 635 systems. Otherwise
there would not have been all the stress in the manuals about the
read/alter/rewrite differences between the 600 and 6000 systems.
On the 6000 you needed to do gating with the read and clear
instructions because they kept the memory locked. On the 635,
you could get away with things like tally operations and add to storage
operations. DTSS got burned on that.
PDP-10's were also sold in multiprocessor configurations.
Eugene A. Pallat
Huw Davies <cc...@lucifer.its.latrobe.edu.au> wrote in article
<6ij8f5$4nr$1...@news.latrobe.edu.au>...
> Bruce James Robert Linley (lin...@netcom.com) wrote:
>
> : Granted, not a lot of consumer-obtainable OSs support multiple CPUs
> : (only NT?) or do so only in experimental OS versions (Linux 2.1.x).
> : If they did, demand for such boxes might go up. It's kind of a catch
> : 22 here.
>
multiprocessor
> machines? (By commercial, I mean sold in commercial quantities - say
> more than 10 :-)
>
> the CDC6600 sort of counts, although the I/O processors weren't usually
> used to run user code....
Don't forget the 360/67 ca. early 1060s designed for up to 4 CPUs with
shared memory.
Remove the '-glop-' for sending email to me.
Gene eapa...@orion-glop-data.com
Orion Data Systems
Solicitations to me must be pre-approved in writing
by me after soliciitor pays $1,000 US per incident.
Solicitations sent to me are proof you accept this
notice and will send a certified check forthwith.
Huw Davies
jmfb...@ma.ultranet.com wrote:
: TOPS10 (a timesharing OS run on PDP-10s) had master/slave CPU support
: since 1070ish or so (I don't remember the announcement year). In
: the late 70s, JMF and TW (the primary TOPS10 developers then) designed
: something that we called SMP (symmetric multi-processing--not to be
: confused with today's use of the term); officially this OS software
: supported 3 CPUs. We did have a site that ran with five.
I must be getting old to forget my favorite "mature" operating system. Of
course we only had a single KI-10 to play with.
As an aside, in what ways did -10 SMP differ from today's usage (say
the way VMS does SMP). Did TOPS-10 SMP allow any processor to handle
all of an I/O request or was there something else?
Richard Shetron
In article <6ij8f5$4nr$1...@news.latrobe.edu.au>,
Huw Davies <cc...@lucifer.its.latrobe.edu.au> wrote:
>Bruce James Robert Linley (lin...@netcom.com) wrote:
>
>: Granted, not a lot of consumer-obtainable OSs support multiple CPUs
>: (only NT?) or do so only in experimental OS versions (Linux 2.1.x).
>: If they did, demand for such boxes might go up. It's kind of a catch
>: 22 here.
>
>Of more folklore type interest, what were the early commercial multiprocessor
>machines? (By commercial, I mean sold in commercial quantities - say
>more than 10 :-)
>
>My first experience was with an 11/782 so that's only early '80s. I guess
>the CDC6600 sort of counts, although the I/O processors weren't usually
>used to run user code....
> Huw Davies | e-mail: Huw.D...@latrobe.edu.au
I'm only famalier with things through around 1979
The GE-600 series released around 1964/1965? supported up to 7 CPU's.
After Honeywell bought the GE division, the new models were the HIS-6000
series and then later called the Level 66. GECOS (GE) and later GCOS
(HIS) ran in a master/slave mode with one master cpu supporting the
remaining cpu's as slave cpus.
The Multics versions (GE-645, later the HIS-6180, then HIS Level 68)
supported up to 7CPU's. Multics ran more in SMP mode, no master/slave CPU
setup. Standard Multics configurations started with 2 CPU's. I did hear
that HIS did a special mod for the AFDSC system to support 15(?) CPU's.
The IBM 360/65 (67) was made later and I don't know if they made more
then 10 multi-cpu systems.
The dual cpu 6180 system at RADC used the 4 4MB 500ns core boxes that
came with the original 635/645 system.
jmfb...@ma.ultranet.com
In article <6ilvjg$go9$1...@news.latrobe.edu.au>,
cc...@lucifer.its.latrobe.edu.au (Huw Davies) wrote:
>jmfb...@ma.ultranet.com wrote:
>
>: TOPS10 (a timesharing OS run on PDP-10s) had master/slave CPU support
>: since 1070ish or so (I don't remember the announcement year). In
>: the late 70s, JMF and TW (the primary TOPS10 developers then) designed
>: something that we called SMP (symmetric multi-processing--not to be
>: confused with today's use of the term); officially this OS software
>: supported 3 CPUs. We did have a site that ran with five.
>
>I must be getting old to forget my favorite "mature" operating system. Of
>course we only had a single KI-10 to play with.
Yup. People keep forgetting [emoticon irritated just a tad :-)].
Ah, but you had lights. When we had to use KLs and KSs, we really
missed those flashes that gave us a nice warm feeling or a panic
alert. I don't think TW ever got over losing the lights.
>
>As an aside, in what ways did -10 SMP differ from today's usage (say
>the way VMS does SMP).
I wasn't aware that VMS did SMP. My impression has been that most
of today's SMP designations are really what we used to think of a
parallel processing--a very different beastie. There also seems
to be a great confusion about the nature of timesharing. I'm
finding that what we used to think of as partitioning is being
considered as timesharing.
>Did TOPS-10 SMP allow any processor to handle
>all of an I/O request or was there something else?
As long as there was a hardware path to the device, any CPU
could do the I/O. For instance, given 3 CPUs and a disk
drive dualported between CPU0 and CPU1, if the job executing
on CPU2 requested I/O from that disk, the job had to be
context-switched to a CPU that had access to the disk.
I don't feel qualified to talk about the technical details
of TOPS10's implementation, but there are lurkers who know
that stuff inside out. Maybe a few of them would talk about
this software technology, if you please :-).
IMO, the greatest feature of TOPS10 SMP was the ability to
SUSPEND/CONTINUE system operation. It was used to split
apart a system for field service, stand alone, etc. Jim
and Tony didn't even realize the implications of this
aspect of an SMP implementation. At a "my god, we finally
shipped this hardware" dinner, I was asked why anyone would
want this feature? People shut down their systems at 17:00
everyday. There wasn't any reason that a system should be
up 24 hours/day, 7 days/week, 52 weeks/year. I asked
the guy (he was a hardware type) if he would be happy
losing his electricity for the day or two it might take to
bring a new dynamo on line. He understood the analogy but
couldn't conceive of a computer system that was so important
that it had to be in operation at all times.
This conversation occurred in the mid-80s; there were times
when I got really dejected at the lack of foresight.
/BAH
Alan Bowler
In article <354e9...@news.wizvax.net> mul...@wizvax.wizvax.net (Richard Shetron) writes:
>
>The GE-600 series released around 1964/1965? supported up to 7 CPU's.
>After Honeywell bought the GE division, the new models were the HIS-6000
>series and then later called the Level 66. GECOS (GE) and later GCOS
>(HIS) ran in a master/slave mode with one master cpu supporting the
>remaining cpu's as slave cpus.
>
>The Multics versions (GE-645, later the HIS-6180, then HIS Level 68)
>supported up to 7CPU's. Multics ran more in SMP mode, no master/slave CPU
>setup. Standard Multics configurations started with 2 CPU's. I did hear
>that HIS did a special mod for the AFDSC system to support 15(?) CPU's.
15 CPU's would have been hard. The limit in those boxes was the SCU
(memory box) which had 8 ports. On the 635/645 you could connect a CPU,
an IOC or a frontend (FNP) to an SCU port. Later the front end
connection was changed so that it connected through an IOM instead,
this meant it could use the IOM's address relocation and the FNP itself
did not need to be changed to connect to a main system with more than 1
megabyte of main memory.
A system with 7 CPU's would therefore have only 1 IOM, and no direct
connected FNP's. That does not seem like enough I/O capacity. Gcos
only supported up to 6 CPU's until recently. (I.e. you needed at least
two IOM's for a system that big). There were not many of those, since
big customers that could afford 4 CPUs usually found they needed more
than 2 IOM's.
The latest version of the hardware has changed this, and there are now
more memory ports, so you can configure 8 CPU systems.
John Savard
lin...@netcom.com (Bruce James Robert Linley) wrote:
>The Pentium Pro- the only one that will
>work in groups of more than two CPUs. Now it's been discontinued. Yet
>it still has not dropped in price comparable to the rate at which other
>discontinued CPUs have dropped. Do Cyrix, AMD, etc., have a drop in
>substitute for the PPro? PPro development was quietly halted until the
>chip was abandoned without an immediate successor. Very wierd.
No, Cyrix and AMD have the same problem with the Pentium Pro as with
the Pentium II; they can't clone those chips, since the cache
interface is patented.
Supposedly, Intel was going to make an Overdrive chip that let you
plug a Pentium II into a Pentium Pro socket. Now, since that chip
would have no excuse for not being faster than a real Pentium II (the
Pentium II has a slower CPU chip to on-module-cache interface than the
Pro) Intel would have to improve the Pentium II before they could
release that product without embarassment.
However, SMP is no panacea. For most problems, having two chips
working on the problem at once is little help. And existing software
would have to be rewritten before it could directly benefit. Two
different programs running at the same time could be shoved, by the
operating system, onto different CPUs, but no one program would run
faster than it already had by itself - without a major rewrite to use
the multiple CPUs.
And the memory we have is too slow to even support one CPU properly,
hence the need for cache! SMP has all the CPUs taking turns on the
same bus for the same memory.
Architectures with many small CPUs, each having a small amount of
memory, all this memory together also serving as the memory for a big
CPU - they would be more efficient, but they are specialized.
John Savard
Tom Van Vleck
In article <35510...@news.wizvax.net>, mul...@wizvax.wizvax.net
(Richard Shetron) wrote:
> In article <6inh9e$pl2$1...@goblin.uunet.ca>,
> Alan Bowler <atbo...@thinkage.on.ca> wrote:
> >In article <354e9...@news.wizvax.net> mul...@wizvax.wizvax.net
(Richard Shetron) writes:
> [snip]
>
> >15 CPU's would have been hard. The limit in those boxes was the SCU
> >(memory box) which had 8 ports. On the 635/645 you could connect a CPU,
> >an IOC or a frontend (FNP) to an SCU port. Later the front end
> >connection was changed so that it connected through an IOM instead,
> >this meant it could use the IOM's address relocation and the FNP itself
> >did not need to be changed to connect to a main system with more than 1
> >megabyte of main memory.
>
> What I heard is HIS did a 16port SCU for the pentagon AFDSC system
> to allow more then 7 CPU's. I know someone who worked on the system,
> but I've lost touch with him, last postal mail bounced.
>
> [snip]
First I've heard of this. Wouldn't work with Multics, unless
major changes were made to the hardcore: the assumption of 8 ports/SCU
was built into a lot of the configuration code. Now, the AFDSC site
at the Pentagon had 5 Multics systems, but I think they only ran
a 6-CPU system once, as an experiment. I will try to dig up the
performance figures, which showed the degradation below linear
as a result of contention for the Page Table Lock.
Richard Shetron
Edward Rice
In article <354e9...@news.wizvax.net>,
mul...@wizvax.wizvax.net (Richard Shetron) wrote:
> The GE-600 series released around 1964/1965? supported up to 7 CPU's.
Four CPUs, not seven. It supported up to eight (total) active units, of
which four could be processors and four could be I/O devices. On the
GE-635, the I/O devices could be the IOC (a big mux) or a Datanet-30.
> After Honeywell bought the GE division, the new models were the HIS-6000
> series and then later called the Level 66. GECOS (GE) and later GCOS
> (HIS) ran in a master/slave mode with one master cpu supporting the
> remaining cpu's as slave cpus.
Not really. Master/slave referred to slave application-type programs and
the master-mode that the operating system used. The processor
configuration was essentially symmetric -- as GCOS progressed, the minor
exceptions were ironed out and eventually, the processor configuration was
fully symmetric. Throughout, a "fault" (internal interrupt) taken by a
processor would dive that specific processor into the fault handler in
hardcore, which would then decide what to do about it. In no version of
GCOS with which I'm familiar did one processor defer to some other
processor to handle faults.
> The Multics versions (GE-645, later the HIS-6180, then HIS Level 68)
> supported up to 7CPU's. Multics ran more in SMP mode, no master/slave
CPU
> setup. Standard Multics configurations started with 2 CPU's. I did
hear
> that HIS did a special mod for the AFDSC system to support 15(?) CPU's.
Multics started closer to symmetric operation than GCOS did. Curiously,
GCOS reached fully symmetric operation somewhat before Multics did. The
issue wasn't really resources applied, since the major work done on GCOS
was done by one on-site analyst who thought it would be a cool project. I
forget his name, but Honeywell gave him the Swett Award, which is the
highest engineering recognition in the company.
> The IBM 360/65 (67) was made later and I don't know if they made more
> then 10 multi-cpu systems.
Actually, the 360/67 and the GE-645 were contemporaneous.
> The dual cpu 6180 system at RADC used the 4 4MB 500ns core boxes that
> came with the original 635/645 system.
Nope. The 635 and 645 did not have 500-ns core boxes. The 6080 (and its
non-EIS brother, the 6070) and the 66|80 used 500-ns core boxes. I'm
fairly sure that 635/645 memory could /not/ be connected to 6000-line
products at all (and why bother, anyway?), because of differences in the
System Controller (memory controller, for you non-HIS hackers out there).
And no 635 or 645 *ever* had anything like a 4-MB core box. Four megs was
BIG in those days, and didn't arrive until the second generation of
metal-oxide semiconductor memory.
Edward Rice
In article <6inh9e$pl2$1...@goblin.uunet.ca>,
atbo...@thinkage.on.ca (Alan Bowler) wrote:
> 15 CPU's would have been hard. The limit in those boxes was the SCU
> (memory box) which had 8 ports. On the 635/645 you could connect a CPU,
> an IOC or a frontend (FNP) to an SCU port. Later the front end
> connection was changed so that it connected through an IOM instead,
> this meant it could use the IOM's address relocation and the FNP itself
> did not need to be changed to connect to a main system with more than 1
> megabyte of main memory.
>
> A system with 7 CPU's would therefore have only 1 IOM, and no direct
> connected FNP's. That does not seem like enough I/O capacity. Gcos
> only supported up to 6 CPU's until recently. (I.e. you needed at least
> two IOM's for a system that big). There were not many of those, since
> big customers that could afford 4 CPUs usually found they needed more
> than 2 IOM's.
Um. Originally, GCOS and Multics both had 4-processor software
restrictions, and the physical SCU box had an 8-active-unit restriction.
So a site was limited to four processors on a system, and four IOMs. I'm
not aware of GCOS /ever/ relaxing that restriction. At the Air Force Data
Services Center, in order to meet certain contractual obligations,
Honeywell provided the Air Force with modified software capable of running
up to six Multics processors, and extensive tests were carried out with
this configuration during off-peak hours, for a period of several weeks
after the software was running. The performance results were actually
better than expected, although not fabulous... we lost less than a tenth of
a processor on *every* processor for each processor we added. The table
looked, roughly, like this:
1 processor 1 figure-of-merit
2 processors 1.8 FOMs
3 processors 2.5 FOMs
4 processors 3.1 FOMs
5 processors 3.6 FOMs
6 processors 4.0 FOMs
That's from memory -- it might have been a trifle better. The reason for
losing ground on every processor as the numbers increased is that the
central point of Honeywell large-scale systems was the memory controller.
With memory-centered systems and a lot of reasonably fast processors
cranking, we ended up with memory-wait-states and software memory locks
more and more, as processor capacity went up. On Multics, I would estimate
that abut 60-75% of the problem lay in the memory-wait-states (hardware
interference). The figure would have been much higher on the software lock
side, but we had extensive experience benchmarking 3-processor systems
under extremely heavy load, and Bob Mullen (of Honeywell CISL) and others
had done some magnificent work in cleaning up the multiprocessor software
bottlenecks before the Air Force acquired their fourth processor.
What was clear was, we got more bang for the users by running a pair of
triple-processors than we did by ganging everything together. From the
system's shop's point of view, we got a LOT better result by running a
3-processor classified system, a 2- or 1-processor unclassified system, and
a 1- or 2-processor system just for the system shop. I think eventually,
the classified system ran with four processors pretty regularly -- the
Secretary of the Air Force and the Secretary of Defense were real CPU hogs.
A 4-cpu, 1-IOM system would almost certainly be I/O bound, but it could be
configured; so could (for pathological reasons) a 1-processor, 4-IOM
system. Generally, about the third processor, a customer would pick up a
second IOM, for backup if nothing else. The boxes were reliable enough in
normal operation (especially the IOMs) that if you had a spare, you ran
with it -- it was more likely to fail to work sitting in the corner unused,
than operating under full load all day.
> The latest version of the hardware has changed this, and there are now
> more memory ports, so you can configure 8 CPU systems.
I'm a little skeptical of this, but this may have happened after I left
Honeywell. I don't recall any GCOS system with more than four processors.
We ran GCOS triples at Teamsters (a site at which I worked after leaving
Honeywell), and they went to four after I left that project, but I'm fairly
certain the limit of four remained in that system.
Alan Bowler
In article <B176C8089...@0.0.0.0> ehr...@his.com (Edward Rice) writes:
>In article <6inh9e$pl2$1...@goblin.uunet.ca>,
>atbo...@thinkage.on.ca (Alan Bowler) wrote:
>
>Um. Originally, GCOS and Multics both had 4-processor software
>restrictions, and the physical SCU box had an 8-active-unit restriction.
>So a site was limited to four processors on a system, and four IOMs. I'm
>not aware of GCOS /ever/ relaxing that restriction.
Gcos did support 6 processors and some where shipped to customers. (I
just checked an old JS2 manual). There weren't many of these, because
the customers that needed that much cpu soon migrated off the DPS-8/70's
to the newer systems. A DPS-88 (Orion) only supported 2 CPU's, but a
single DPS-88 CPU system had about the throughout of a 4 processor 8/70.
(I.e. going to 6 processors was a mostly done by customers that needed the
extra cpu befor the DPS-88 was available). The successor systems NEC
systems (DPS-90, DPS-9000/800 (Titan), and DPS-9000/900 (Zeus)) were
shipped with up to 4 processors, it might be possible they could run
6-cpu 2 IOPs, but I don't know if this was tried. The DPS-8000 (rpm)
likely could run 6 CPU's but it would be have been easier to upgrade
to one of the NEC models instead. The DPS-9000/500 (rpm2) certainly
can be configured with 6 cpu's, but I don't know if any customers run
this way. Last year, Systems I and J were running on a 9000/500 box
with 6 CPU's (I don't know the I/O configuration).
> > The latest version of the hardware has changed this, and there are now
> > more memory ports, so you can configure 8 CPU systems.
>
>I'm a little skeptical of this, but this may have happened after I left
>Honeywell. I don't recall any GCOS system with more than four processors.
>We ran GCOS triples at Teamsters (a site at which I worked after leaving
>Honeywell), and they went to four after I left that project, but I'm fairly
>certain the limit of four remained in that system.
I did say the *latest*. You can configure 8 cpu's on a DPS 9000/700
(Jupiter) system. System J (the successor to System X) currently
runs on an 8 processor configuration. I don't think any customers
currently have such a configuration. System J was only went to 8
processors a few weeks ago, but a customer hitting the limits of a quad
processor 9000/800 might consider it. (It would save on power and
floor space.)
Richard M. Alderson III
>TOPS10 (a timesharing OS run on PDP-10s) had master/slave CPU support since
>1070ish or so (I don't remember the announcement year).
1070 is the KI monitor, right, Barb? That would put it in the 1971-72
timeframe at the earliest...
--
Rich Alderson Last LOTS Tops-20 Systems Programmer, 1984-1991
last name @ XKL dot COM Current maintainer, MIT TECO EMACS (v. 170)
Richard M. Alderson III
In article <6ilvjg$go9$1...@news.latrobe.edu.au> cc...@lucifer.its.latrobe.edu.au
(Huw Davies) writes:
>I must be getting old to forget my favorite "mature" operating system. Of
>course we only had a single KI-10 to play with.
This brings up another wonder of multi-processor architecture in the -10
family.
The TENEX operating system (written at BBN, licensed as Tops-20 v. 1 by DEC)
ran on the KA and KI processors before the KL was created. It was a single-
processor operating system...
...except at the IMSSS (Institute for Mathematical Studies in the Social
Sciences, Stanford University), which needed more processor power for some of
their work. They ran a dual-processor KI under TENEX until the early 1990s.
Only PDP-10 on the campus I didn't have an account on.
Richard Shetron
In article <B176BC4B9...@0.0.0.0>, Edward Rice <ehr...@his.com> wrote:
>In article <354e9...@news.wizvax.net>,
>mul...@wizvax.wizvax.net (Richard Shetron) wrote:
> > The dual cpu 6180 system at RADC used the 4 4MB 500ns core boxes that
> > came with the original 635/645 system.
>
>Nope. The 635 and 645 did not have 500-ns core boxes. The 6080 (and its
>non-EIS brother, the 6070) and the 66|80 used 500-ns core boxes. I'm
>fairly sure that 635/645 memory could /not/ be connected to 6000-line
>products at all (and why bother, anyway?), because of differences in the
>System Controller (memory controller, for you non-HIS hackers out there).
>And no 635 or 645 *ever* had anything like a 4-MB core box. Four megs was
>BIG in those days, and didn't arrive until the second generation of
>metal-oxide semiconductor memory.
You're right, Griffis had 4 1MB core boxes for 4MB total. I'm pretty
sure they were 500ns core. I was there before (college work study) and
after (HIS/FSO multics analyst) the upgrade from the 635/645 to 6180.
As best I remember from what people said, they kept the the memory boxes
from teh 635/645. They may have done something to the SCU to do so.
When I left HIS in 79, they still have the 4 core boxes and I remember the
Field Engineers at one point talking about how much fun it was replacing
core planes.
I remember being at MIT getting the 2 week intro to the NFS software he
wrote and touring CISL and being told they had both a 500ns core and a
750ns MOS memory box and they had a small 2 page program and could tell
which page was in which box by the run time.
Richard Shetron
In article <thvv-06059...@thvv.vip.best.com>,
Tom Van Vleck <th...@best.com> wrote:
>In article <35510...@news.wizvax.net>, mul...@wizvax.wizvax.net
>(Richard Shetron) wrote:
>
>> In article <6inh9e$pl2$1...@goblin.uunet.ca>,
>> Alan Bowler <atbo...@thinkage.on.ca> wrote:
>> >In article <354e9...@news.wizvax.net> mul...@wizvax.wizvax.net
>(Richard Shetron) writes:
>> [snip]
>>
>> >(memory box) which had 8 ports. On the 635/645 you could connect a CPU,
>> >an IOC or a frontend (FNP) to an SCU port. Later the front end
>> >connection was changed so that it connected through an IOM instead,
>> >this meant it could use the IOM's address relocation and the FNP itself
>> >did not need to be changed to connect to a main system with more than 1
>> >megabyte of main memory.
>>
>> to allow more then 7 CPU's. I know someone who worked on the system,
>> but I've lost touch with him, last postal mail bounced.
>>
>> [snip]
>
>major changes were made to the hardcore: the assumption of 8 ports/SCU
>was built into a lot of the configuration code. Now, the AFDSC site
>at the Pentagon had 5 Multics systems, but I think they only ran
>a 6-CPU system once, as an experiment. I will try to dig up the
>performance figures, which showed the degradation below linear
>as a result of contention for the Page Table Lock.
As I understood it, it was a special project. As I understood it, they
acutally never ran the system as one system, but as several from unsecured
to classified and moved hardware around as needed to match the workload.
Someplace I have a Multics limits sheet I got while out at Multics school
in Pheonix based on the 6180 of 1978 showing maximum amounts of resources
a system coule have. I remember the disk space limit was based on cable
length with the disks on all sides.
jmfb...@ma.ultranet.com
In article <ALDERSON.9...@netcom.netcom.com>,
alde...@netcom.netcom.com (Richard M. Alderson III) wrote:
>In article <6ikc2e$bft$1...@ligarius.ultra.net> jmfb...@ma.ultranet.com
writes:
>
>>TOPS10 (a timesharing OS run on PDP-10s) had master/slave
>>CPU support since
>>1070ish or so (I don't remember the announcement year).
>
>1070 is the KI monitor, right, Barb? That would put it in the 1971-72
>timeframe at the earliest...
1070 is the KI single processor monitor. When I went to my 25th
DEC anniversary dinner, they had a copy of the internal newspaper.
The DECsystem-1070 was announced that year (I know, I've probably
got the dashing wrong..I'll never get it right...but that's another
story :-)). Oh, yeah, I was hired in 1971.
/BAH
Jack Peacock
jmfb...@ma.ultranet.com wrote in message <6iupca$5vf$1...@ligarius.ultra.net>...
>>>TOPS10 (a timesharing OS run on PDP-10s) had master/slave
>>>CPU support since
>>>1070ish or so (I don't remember the announcement year).
>>
>DEC anniversary dinner, they had a copy of the internal newspaper.
Several multi-processing systems came out about the same time. The school
where I was learning programming upgraded from an 1106 (with FASTRAND drums!)
to an 1108, dual CPUs and 256KW, plus a whole floor of short stack 20MB disk
drives. That was in '72, but I think the dual processor config was available
before then, Martn Marietta was using the big Univacs (1110s?) for space
shuttle design work.
Jack Peacock
jmfb...@ma.ultranet.com
In article <3550ceb6...@news.prosurfr.com>,
jsa...@tenMAPSONeerf.edmonton.ab.ca (John Savard) wrote:
>lin...@netcom.com (Bruce James Robert Linley) wrote:
<snip>
>However, SMP is no panacea. For most problems, having two chips
>working on the problem at once is little help.
See. I wouldn't call this SMP; I would call it parallel processing
or pipe-line processing if it's done with one CPU.
>And existing software
>would have to be rewritten before it could directly benefit. Two
>different programs running at the same time could be shoved, by the
>operating system, onto different CPUs, but no one program would run
>faster than it already had by itself - without a major rewrite to use
>the multiple CPUs.
This is true for a single user system. I'm generally talking about
a timesharing system. Our SMP implementation actually improved
system performance from the point of view of the user (among other
things that I won't go into here). One did not have to "wait" to
exit out of an editor. The feel of a TOPS10 SMP system was faster
than this 486x66 processor.
>
>And the memory we have is too slow to even support one CPU properly,
>hence the need for cache! SMP has all the CPUs taking turns on the
>same bus for the same memory.
>
>Architectures with many small CPUs, each having a small amount of
>memory, all this memory together also serving as the memory for a big
>CPU - they would be more efficient, but they are specialized.
You should really look at the implementations of SMP on TOPS10 and UNIX
(System V) to get an idea of how these problems were addressed.
The TOPS10 implementation almost came to a schreeching halt just because
the KL CPU did not have a write-through cache.
/BAH