Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #3312 > unrolled thread

'smttter IBMdroids

Back to article view | Back to comp.arch

Contents

  'smttter IBMdroids Robert Myers <rbmyersusa@gmail.com> - 2011-08-31 22:15 -0400
    Re: 'smttter IBMdroids Robert Myers <rbmyersusa@gmail.com> - 2011-08-31 22:20 -0400
      Re: 'smttter IBMdroids Anne & Lynn Wheeler <lynn@garlic.com> - 2011-08-31 22:31 -0400
        Re: 'smttter IBMdroids Robert Myers <rbmyersusa@gmail.com> - 2011-09-01 07:30 -0700
    Re: 'smttter IBMdroids Quadibloc <jsavard@ecn.ab.ca> - 2011-09-01 09:48 -0700
      Re: 'smttter IBMdroids nmm1@cam.ac.uk - 2011-09-01 17:58 +0100
      Re: 'smttter IBMdroids Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-09-01 10:58 -0700
        Re: 'smttter IBMdroids nmm1@cam.ac.uk - 2011-09-01 18:51 +0100
      Re: 'smttter IBMdroids Anne & Lynn Wheeler <lynn@garlic.com> - 2011-09-01 15:42 -0400
      Re: 'smttter IBMdroids Robert Wessel <robertwessel2@yahoo.com> - 2011-09-01 18:19 -0500
        Re: 'smttter IBMdroids Anne & Lynn Wheeler <lynn@garlic.com> - 2011-09-01 20:57 -0400
        Re: 'smttter IBMdroids nmm1@cam.ac.uk - 2011-09-02 09:17 +0100
        Re: 'smttter IBMdroids nmm1@cam.ac.uk - 2011-09-02 09:19 +0100
          Re: 'smttter IBMdroids Robert Wessel <robertwessel2@yahoo.com> - 2011-09-02 04:44 -0500
            Re: 'smttter IBMdroids nmm1@cam.ac.uk - 2011-09-02 11:39 +0100
              Re: 'smttter IBMdroids Robert Wessel <robertwessel2@yahoo.com> - 2011-09-02 11:14 -0500
          Re: 'smttter IBMdroids Robert Wessel <robertwessel2@yahoo.com> - 2011-09-02 04:47 -0500
            Re: 'smttter IBMdroids nmm1@cam.ac.uk - 2011-09-02 11:26 +0100
            Re: 'smttter IBMdroids Anne & Lynn Wheeler <lynn@garlic.com> - 2011-09-02 08:48 -0400
            Re: 'smttter IBMdroids Anne & Lynn Wheeler <lynn@garlic.com> - 2011-09-02 09:29 -0400
    Re: 'smttter IBMdroids Del Cecchi <delcecchi@gmail.com> - 2011-09-01 17:15 -0500
      Re: 'smttter IBMdroids Robert Myers <rbmyersusa@gmail.com> - 2011-09-02 10:10 -0700
        Re: innovation from Armonk, was 'smttter IBMdroids John Levine <johnl@iecc.com> - 2011-09-02 21:21 +0000
          Re: innovation from Armonk, was 'smttter IBMdroids nmm1@cam.ac.uk - 2011-09-02 21:56 +0100
          Re: innovation from Armonk, was 'smttter IBMdroids Anne & Lynn Wheeler <lynn@garlic.com> - 2011-09-02 17:49 -0400
        Re: 'smttter IBMdroids Del Cecchi <delcecchi@gmail.com> - 2011-09-02 18:04 -0500
          Re: 'smttter IBMdroids Thomas Womack <twomack@chiark.greenend.org.uk> - 2011-09-03 00:16 +0100
            Re: 'smttter IBMdroids Robert Myers <rbmyersusa@gmail.com> - 2011-09-03 14:25 -0400
              Re: 'smttter IBMdroids Thomas Womack <twomack@chiark.greenend.org.uk> - 2011-09-03 20:09 +0100
          Re: 'smttter IBMdroids Robert Myers <rbmyersusa@gmail.com> - 2011-09-03 22:02 -0400
            Re: 'smttter IBMdroids Del Cecchi <delcecchi@gmail.com> - 2011-09-03 21:50 -0500
              Re: 'smttter IBMdroids Robert Myers <rbmyersusa@gmail.com> - 2011-09-03 23:52 -0400
        Re: 'smttter IBMdroids "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-09-05 08:26 -0700
          Re: 'smttter IBMdroids Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-09-05 11:14 -0700
            Re: 'smttter IBMdroids Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-09-05 22:05 +0200
            Re: 'smttter IBMdroids Robert Myers <rbmyersusa@gmail.com> - 2011-09-05 17:27 -0400
          Re: 'smttter IBMdroids Robert Myers <rbmyersusa@gmail.com> - 2011-09-05 17:16 -0400
            Re: 'smttter IBMdroids "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-09-05 14:40 -0700
              Re: 'smttter IBMdroids Robert Myers <rbmyersusa@gmail.com> - 2011-09-05 15:45 -0700
          Re: 'smttter IBMdroids Del Cecchi <delcecchi@gmail.com> - 2011-09-06 21:47 -0500

Page 1 of 2  [1] 2  Next page →

#3312 — 'smttter IBMdroids

Not in the mood today to claim that IBM invented everything and that you 
personally were involved?

Robert.

[toc] | [next] | [standalone]

#3313

On 8/31/2011 10:15 PM, Robert Myers wrote:
> Not in the mood today to claim that IBM invented everything and that you
> personally were involved?
>
time for me to switch to folklore.  I'm certain Barb would insist she 
was involved, no matter what.

Robert.

[toc] | [prev] | [next] | [standalone]

#3314

Robert Myers <rbmyersusa@gmail.com> writes:
> time for me to switch to folklore.  I'm certain Barb would insist she
> was involved, no matter what.

maybe not going to like the smp/rdbms discussion there

-- 
virtualization experience starting Jan1968, online at home since Mar1970

[toc] | [prev] | [next] | [standalone]

#3325

On Aug 31, 10:31 pm, Anne & Lynn Wheeler <l...@garlic.com> wrote:
> Robert Myers <rbmyers...@gmail.com> writes:
> > time for me to switch to folklore.  I'm certain Barb would insist she
> > was involved, no matter what.
>
> maybe not going to like the smp/rdbms discussion there
>

I know better than to go there.

Robert.

[toc] | [prev] | [next] | [standalone]

#3330

On Aug 31, 8:15 pm, Robert Myers <rbmyers...@gmail.com> wrote:
> Not in the mood today to claim that IBM invented everything and that you
> personally were involved?

When IBM invented SMP, they called it parallel sysplex, Codd and Date
worked for IBM, the 305 RAMAC, STRETCH, the 360/85... although I
certainly wasn't involved, IBM did invent a *few* things... SMP,
relational databases, hard disks, aggressive pipelining, cache. And
they invented the vacuum column as well...

On the other hand, there's the Atlas - they didn't invent Virtual
Memory. The SDS 920/930/940 indicate that IBM didn't invent the idea
of having a family of compatible machines, even if the 360 did take it
further.

John Savard

[toc] | [prev] | [next] | [standalone]

#3333

In article <322fbe83-3e27-45bf-be6a-6c673f4c7ec5@er4g2000vbb.googlegroups.com>,
Quadibloc  <jsavard@ecn.ab.ca> wrote:
>On Aug 31, 8:15=A0pm, Robert Myers <rbmyers...@gmail.com> wrote:
>
>> Not in the mood today to claim that IBM invented everything and that you
>> personally were involved?
>
>When IBM invented SMP, they called it parallel sysplex, Codd and Date
>worked for IBM, the 305 RAMAC, STRETCH, the 360/85... although I
>certainly wasn't involved, IBM did invent a *few* things... SMP,
>relational databases, hard disks, aggressive pipelining, cache. And
>they invented the vacuum column as well...

Unless they used the term "parallel sysplex" in a completely different
sense in the 1970s from the 1960s, it's very dubious to call it SMP.

I don't go back far enough to judge exactly how much claim IBM have
to be among the inventors of SMP, but there is definitely no sense
in which they are the solve inventor.  Inter alia, the term "SMP"
meant something very different in the 1970s and even 1980s from what
it means today, and none of the early systems that I know of were
even remotely symmetric.  Even when that came in, it needed a reboot
to switch the master CPU.


Regards,
Nick Maclaren.

[toc] | [prev] | [next] | [standalone]

#3338

On 9/1/2011 9:48 AM, Quadibloc wrote:
> On Aug 31, 8:15 pm, Robert Myers<rbmyers...@gmail.com>  wrote:
>> Not in the mood today to claim that IBM invented everything and that you
>> personally were involved?
>
> When IBM invented SMP,

IBM most certainly did not invent SMP.  There were examples of SMP in 
the late 1960s.  Univac allowed up to three 1108 processors to share the 
same memory and be a single system image, just with more CPU resources 
in pretty much exactly the same way that today's multi-core chips do 
(except, of course, no caches, and multiple cabinets of logic cards 
instead of areas of a die).  This was way before Sysplex.  And I am not 
sure that Univac was the only one or even the first to do this.

In fact, IBM's closest idea was "loosely coupled" multi-processing, 
where each system had its own private memory and copy of the OS, though 
they could share peripherals and a single batch program queue.

-- 
  - Stephen Fuld
(e-mail address disguised to prevent spam)

[toc] | [prev] | [next] | [standalone]

#3340

In article <j3oh3l$qjv$1@dont-email.me>,
Stephen Fuld  <SFuld@Alumni.cmu.edu.invalid> wrote:
>On 9/1/2011 9:48 AM, Quadibloc wrote:
>> On Aug 31, 8:15 pm, Robert Myers<rbmyers...@gmail.com>  wrote:
>
>>> Not in the mood today to claim that IBM invented everything and that you
>>> personally were involved?
>>
>> When IBM invented SMP,
>
>IBM most certainly did not invent SMP.  There were examples of SMP in 
>the late 1960s.  Univac allowed up to three 1108 processors to share the 
>same memory and be a single system image, just with more CPU resources 
>in pretty much exactly the same way that today's multi-core chips do 
>(except, of course, no caches, and multiple cabinets of logic cards 
>instead of areas of a die).  This was way before Sysplex.  And I am not 
>sure that Univac was the only one or even the first to do this.
>
>In fact, IBM's closest idea was "loosely coupled" multi-processing, 
>where each system had its own private memory and copy of the OS, though 
>they could share peripherals and a single batch program queue.

That is roughly what "parallel sysplex" was when I first saw
the term (or something like it) in the 1970s.  It didn't actually
work, either, and so was dropped until the System/3090 series with
a vastly rewritten operating system came along.

If I recall, there was some muttering about a mechanism to transfer
pages between CPUs, but its users had quite enough problems just
keeping the system propped up well enough to do any work.  Its
main intention was to improve RAS by allowing failover, but ....

On the other hand, IBM can claim to be among the inventors of
autoparallelising compilers - together with Alliant - following
on from the computer science experiments with the idea.


Regards,
Nick Maclaren.

[toc] | [prev] | [next] | [standalone]

#3347

Quadibloc <jsavard@ecn.ab.ca> writes:
> When IBM invented SMP, they called it parallel sysplex, Codd and Date
> worked for IBM, the 305 RAMAC, STRETCH, the 360/85... although I
> certainly wasn't involved, IBM did invent a *few* things... SMP,
> relational databases, hard disks, aggressive pipelining, cache. And
> they invented the vacuum column as well...
>
> On the other hand, there's the Atlas - they didn't invent Virtual
> Memory. The SDS 920/930/940 indicate that IBM didn't invent the idea
> of having a family of compatible machines, even if the 360 did take it
> further.

in the 70s ... ibm called things "tightly-coupled" (smp, shared memory)
and "loosely-coupled" (cluster, non-shared memory, shared disks) ...
then they had this thing called "closely-coupled" ... basically
"loosely-coupled" ... with special locking facility that implemented
memory access semantics for cluster coordination.

my wife got con'ed into going to POK (large mainframe land) to be in
charge of loosely-coupled architecture ... where she created 
"peer-coupled shared data" architecture ... some past posts
http://www.garlic.com/~lynn/submain.html#shareddata

she didn't remain long ... mostly becase of a combination of frequent
battles with the communication group over using SNA for cluster
coordination and little uptake of the architecture ... except for IMS
hotstandby in the 80s, and eventually sysplex much later in the 90s.

as i mentioned in the recent a.f.c. smp thread ... charlie invented
compare&swap instruction at the science center, while doing
multiprocessor fine-grain (virtual machine) cp67 kernel locking support
(compare&swap chosen because CAS are charlie's initials).

parallel sysplex (april 1994)
http://en.wikipedia.org/wiki/IBM_Parallel_Sysplex

in the 60s, 360/65 had two-way shared memory multiprocessor ...  but
shared I/O was simulated by having processor specific dedicated i/o
channels ... with "twin-tailed" device i/o controllers connected to two
different channels, one going to each processor.

while the uniprocessor 360/67 was nearly identical to 360/65 with the
addition of virtual memory hardware ... the multiprocessor 360/67 was
designed for up to four processors and added a "channel controller"
allowing all processors to access all channels (all processors accessing
all channels didn't reappear until 3081 in the 80s). os/360
multiprocessor support for 360/65 had global "spin-wait" kernel lock
(only one processor executing in the kernel at a time).

recent folklore in linkedin science center group ... science center only
had a single processor 360/67 ... however, lincoln labs had a
two-processor SMP 360/67 ... that mostly ran "partitioned" as two single
processor 360/67 (each processor getting half the partitioned
resources).. Lincoln labs than notified ibm it was returning the
hardware. The head of the science center called the moving company (that
was scheduled to return the hardware to Kingston, NY) and had them
deliver it instead to the science center (upgrade of the science center
machine to a two-processor 360/67 SMP). This is the machine that Charlie
was working on when he invented the compare&swap instruction.

initial attempts to get compare&swap included in 370 were rebuffed with
statement that the POK favorite son operating system considered (360)
test&set instruction sufficient for multiprocessor operation. the
challenge was then to find uses for compare&swap that weren't
multiprocessor specific ... in order to justify for 370 inclusion.  Thus
were born the examples (still in modern mainframe principles of
operation) about using compare&swap in multi-threaded applications (like
large DBMS implementations).

misc. past posts mentioning original relational/sql implementation, 
system/r
http://www.garlic.com/~lynn/submain.html#systemr

science center ... some past posts
http://www.garlic.com/~lynn/subtopic.html#545tech

had original done virtual machine cp40 on a custom modified 360/40 that
had virtual memory hardware added. cp40 morphed into cp67 when the
science center got a 360/67 (standard product that came with virtual
memory hardware).

a.f.c. (multiprocessor/compare&swap) thread:
http://www.garlic.com/~lynn/2011k.html#61 Selectric Typewriter--50th Anniversary
http://www.garlic.com/~lynn/2011k.html#79 Selectric Typewriter--50th Anniversary
http://www.garlic.com/~lynn/2011k.html#80 Selectric Typewriter--50th Anniversary

comp.arch thread:
http://www.garlic.com/~lynn/2011k.html#63 Somewhat off-topic: comp-arch.net cloned, possibly hacked
http://www.garlic.com/~lynn/2011k.html#65 Somewhat off-topic: comp-arch.net cloned, possibly hacked
http://www.garlic.com/~lynn/2011k.html#67 Somewhat off-topic: comp-arch.net cloned, possibly hacked
http://www.garlic.com/~lynn/2011k.html#74 Somewhat off-topic: comp-arch.net cloned, possibly hacked
http://www.garlic.com/~lynn/2011k.html#75 Somewhat off-topic: comp-arch.net cloned, possibly hacked
http://www.garlic.com/~lynn/2011k.html#77 Somewhat off-topic: comp-arch.net cloned, possibly hacked

-- 
virtualization experience starting Jan1968, online at home since Mar1970

[toc] | [prev] | [next] | [standalone]

#3358

On Thu, 1 Sep 2011 09:48:06 -0700 (PDT), Quadibloc <jsavard@ecn.ab.ca>
wrote:

>On Aug 31, 8:15 pm, Robert Myers <rbmyers...@gmail.com> wrote:
>> Not in the mood today to claim that IBM invented everything and that you
>> personally were involved?
>
>When IBM invented SMP, they called it parallel sysplex, Codd and Date
>worked for IBM, the 305 RAMAC, STRETCH, the 360/85... although I
>certainly wasn't involved, IBM did invent a *few* things... SMP,
>relational databases, hard disks, aggressive pipelining, cache. And
>they invented the vacuum column as well...
>
>On the other hand, there's the Atlas - they didn't invent Virtual
>Memory. The SDS 920/930/940 indicate that IBM didn't invent the idea
>of having a family of compatible machines, even if the 360 did take it
>further.


IBM didn't call it SMP, but multi-processor systems date back to the
S/360, although they were somewhat special order then.  The S/370 line
included a couple of machines (370/158, 370/168, IIRC), which had what
IBM called Attached Processor ("AP") and Multiprocessor ("MP")
configurations.  These were SMP in every sense of the word, the main
difference was that an AP machines could not do I/O from the second
CPU (IOW, they couldn't issue any of the half dozen I/O instructions,
or take I/O interrupts), whereas the MP machines could.

Starting with the 3080 series, IBM supported four processors.  IBM
called the two CPU 3081s "dyadic", and had some other term (which
escapes me at the moment) for the four CPU 3084, but the 3084 could be
physically partitioned into two 3081 equivalents.

Parallel Sysplex is a much later term, and refers to the IBM
clustering technology for zOS.

[toc] | [prev] | [next] | [standalone]

#3360

Robert Wessel <robertwessel2@yahoo.com> writes:
> IBM didn't call it SMP, but multi-processor systems date back to the
> S/360, although they were somewhat special order then.  The S/370 line
> included a couple of machines (370/158, 370/168, IIRC), which had what
> IBM called Attached Processor ("AP") and Multiprocessor ("MP")
> configurations.  These were SMP in every sense of the word, the main
> difference was that an AP machines could not do I/O from the second
> CPU (IOW, they couldn't issue any of the half dozen I/O instructions,
> or take I/O interrupts), whereas the MP machines could.
>
> Starting with the 3080 series, IBM supported four processors.  IBM
> called the two CPU 3081s "dyadic", and had some other term (which
> escapes me at the moment) for the four CPU 3084, but the 3084 could be
> physically partitioned into two 3081 equivalents.
>
> Parallel Sysplex is a much later term, and refers to the IBM
> clustering technology for zOS.

re:
http://www.garlic.com/~lynn/2011k.html#82 'smttter IBMdroids

all 370 multiprocessors were two processor (except for a special 5-way
and a 16-way that i got to work on ... but were never announced or
shipped) and like 360/65 simulated shared i/o with processor dedicated
i/o channels ... and twin-tailed controller ... with two channel
interfaces, one for each processor dedicated channels.

all 360 & 370 two processor multiprocessors were partionable into
two independent single processor configurations.

when 3081 (two processor smp) was initially introduced, it was referred
to as dyadic to differentiate from 360&370 multiprocessors ... because
it couldn't be partitioned into two independent single processor
operations (however, as previously referenced, 3081 did have shared
channels, each processor could access all channels ... like earlier
360/67 multiprocessor) eventually 3084 support came out ... which
combined two 3081s into a 4-way smp (and could be partitioned into two
3081 2-way smps).

370 "attached processor" was less expensive 2-way multiprocessor where
one processor didn't have its own dedicated channels. "less expensive"
for 370/168AP made a little sense, since 168 had external channels.  It
was something of fabrication for 370/158AP ... since 370/158 had
"integrated channels" ... i.e. the 370/158 microprocessor engine was
shared executing the 370 instruction microcode and the integrated
channel microcode.

with the failure of Future System effort
http://www.garlic.com/~lynn/submail.html#futuresys

there was mad rush to get stuff back into the 370 product pipelines,
this included the 303x in parallel with 3081. the 303x external channel
director (used for all 303x processors) was 370/158 engine with the
integrated channel microcode and w/o 370 instruction microcode. A 3031
was a 370/158 engine with just the 370 instruction microcode and a 2nd
370/158 engine with just the integrated microcode. A 3031 multiprocessor
was actually four 370/158 engines (two with 370 instruction microcode
and two with integrated channel microcode).

3032 was 370/168 reworked to work with 303x channel director.

3033 started out with 370/168 logic remapped to 20% faster chips.
Before ship, some of the logic was reworked to take advantage of higher
circuit density in the faster chips ... eventually shipped 50% faster
than 370/168.

besides 360/65 smp tightly-coupled multiprocessor ... there was 360
loosely-coupled (twin-tailed disk controllers hooked to different
processor specific channels going to independent single processor
systems ... rather than emulated shared i/o for tightly coupled
multiprocessor). ASP spooling supported loosely-coupled ... also airline
control program (ACP) had loosely-coupled support (for both scale-up and
availability).

shared disk loosely-coupled access was managed with device
"reserve/release" i/o ....  i.e. reserve disk for specific processor
access and release when done (basically processor/device exclusive lock)

3830 disk controller (for 3330 and later 3350 disks) could have
four-tailed channel connections. In the late 70s, there was a 3830
controller "airline control program" feature for fine-grain locking
... basically able to do i/o operation that "named" a lock managed by
the 3830 controller ... which could be obtained and released.
discussed in this old email
http://www.garlic.com/~lynn/2008i.html#email800325
in this post
http://www.garlic.com/~lynn/2008i.html#39 American Airlines

3330s also had a feature called "string-switch" where a string of 3330
disks could be connected to 3830 controllers (theorically each connected
to four channels to four different processors ... providing for up to
eight system sharing).

One of the largest virtual-machine based online services in the 70s was
the internal online HONE system providing world-wide sales&marketing
support. The US HONE datacenters were consolidated at 1501 cal in the
mid-70s (more recently a newer bldg. was built at 1601 cal and occupied
by FACEBOOK, 1501 has a different occupant now). Majority of HONE
applications were implemented in APL making the load quite compute
intensive. 1501 was putting in multiple multi-processor 370/168AP (it
needed processor capacity ... not so much i/o capacity) ... and was
heading for eight such two-processor complexes ... all sharing large
3330 disk farm. HONE developed a special compare&swap channel program
sequence involving customer CKD "search-id" channel programs (it
required extra revolutions ... but was more efficient than device
reserve/release).

3081 was suppose to be multi-processor smp only ... no uniprocessor was
going to be offerred. There were two problems 1) TPF (renamed airline
control program) didn't have tightly-coupled, shared-memory support
(just loosely-coupled support) and 2) 370 clone processor vendors were
offering newer, faster single-processor machine. This eventually forced
the release of single-processor 3081, called 3083. It was something of a
problem ... basically a processor unit had to be removed from the 3081
cabinet. The cabinet was wired for processor0 at the top of the cabinet;
simply removing processor1 left the cabinet (dangerously) top-heavy.

The four-way 3084 (two 3081s tied together) resulted in stressing vm370
and mvs multiprocessor support ... not so much lock contention ... but
cache-line trashing. There was special cache-line sensitivity project
for both vm370 and mvs ... that went through kernel code making storage
cache-aligned ... so two different storage areas (potentially
concurrently being used by different processors) didn't occupy the same
cache line. This effort supposedly improved overall system throughput by
something like 5percent.

misc. past posts mentioning smp and/or compare&swap
http://www.garlic.com/~lynn/subtopic.html#smp

-- 
virtualization experience starting Jan1968, online at home since Mar1970

[toc] | [prev] | [next] | [standalone]

#3362

In article <r54067hcb735luri3r06g7l5gph7ali7mj@4ax.com>,
Robert Wessel  <robertwessel2@yahoo.com> wrote:
>On Thu, 1 Sep 2011 09:48:06 -0700 (PDT), Quadibloc <jsavard@ecn.ab.ca>
>wrote:
>
>>On Aug 31, 8:15 pm, Robert Myers <rbmyers...@gmail.com> wrote:
>>> Not in the mood today to claim that IBM invented everything and that you
>>> personally were involved?
>>
>>When IBM invented SMP, they called it parallel sysplex, Codd and Date
>>worked for IBM, the 305 RAMAC, STRETCH, the 360/85... although I
>>certainly wasn't involved, IBM did invent a *few* things... SMP,
>>relational databases, hard disks, aggressive pipelining, cache. And
>>they invented the vacuum column as well...
>>
>>On the other hand, there's the Atlas - they didn't invent Virtual
>>Memory. The SDS 920/930/940 indicate that IBM didn't invent the idea
>>of having a family of compatible machines, even if the 360 did take it
>>further.
>
>
>IBM didn't call it SMP, but multi-processor systems date back to the
>S/360, although they were somewhat special order then.  The S/370 line
>included a couple of machines (370/158, 370/168, IIRC), which had what
>IBM called Attached Processor ("AP") and Multiprocessor ("MP")
>configurations.  These were SMP in every sense of the word, the main
>difference was that an AP machines could not do I/O from the second
>CPU (IOW, they couldn't issue any of the half dozen I/O instructions,
>or take I/O interrupts), whereas the MP machines could.
>
>Starting with the 3080 series, IBM supported four processors.  IBM
>called the two CPU 3081s "dyadic", and had some other term (which
>escapes me at the moment) for the four CPU 3084, but the 3084 could be
>physically partitioned into two 3081 equivalents.
>
>Parallel Sysplex is a much later term, and refers to the IBM
>clustering technology for zOS.

[toc] | [prev] | [next] | [standalone]

#3363

In article <r54067hcb735luri3r06g7l5gph7ali7mj@4ax.com>,
Robert Wessel  <robertwessel2@yahoo.com> wrote:
>
>Starting with the 3080 series, IBM supported four processors.  IBM
>called the two CPU 3081s "dyadic", and had some other term (which
>escapes me at the moment) for the four CPU 3084, but the 3084 could be
>physically partitioned into two 3081 equivalents.
>
>Parallel Sysplex is a much later term, and refers to the IBM
>clustering technology for zOS.

Damn newsreader!

Can you remember what the term used for the short-lived and
unsuccessful linked CPUs that were intended for failover?  That
was based on the 3033, if I recall.  It was something very like
parallel sysplex.

Thanks for remind me about the 3084 - dammit, we used one! - yes,
IBM introduced modern SMP before the 390 series, though it wan't
until then that systems became properly symmetric.

Regards,
Nick Maclaren.

[toc] | [prev] | [next] | [standalone]

#3365

On Fri, 2 Sep 2011 09:19:51 +0100 (BST), nmm1@cam.ac.uk wrote:

>In article <r54067hcb735luri3r06g7l5gph7ali7mj@4ax.com>,
>Robert Wessel  <robertwessel2@yahoo.com> wrote:
>>
>>Starting with the 3080 series, IBM supported four processors.  IBM
>>called the two CPU 3081s "dyadic", and had some other term (which
>>escapes me at the moment) for the four CPU 3084, but the 3084 could be
>>physically partitioned into two 3081 equivalents.
>>
>>Parallel Sysplex is a much later term, and refers to the IBM
>>clustering technology for zOS.
>
>Damn newsreader!
>
>Can you remember what the term used for the short-lived and
>unsuccessful linked CPUs that were intended for failover?  That
>was based on the 3033, if I recall.  It was something very like
>parallel sysplex.


The only thing I remember for the 3033 was the "Alternate CPU
Recovery" feature, which required a 3033MP as a base.  I think that
only worked with MVS.  IIRC, this was a hybrid of the MP and
partitioned modes of a 3033MP, so you were effectively running a
uniprocessor 3033, but with a second one as a hot spare.

I never actually encountered a 3033 running like that, but it was in
some of the documentation.


>Thanks for remind me about the 3084 - dammit, we used one! - yes,
>IBM introduced modern SMP before the 390 series, though it wan't
>until then that systems became properly symmetric.


It somewhat depends on your definition of "properly symmetric."  I/O
on the pre-XA MP systems was partitioned amongst the various CPUs (a
MP 3033 might, for example, have 24 channels, 12 on each CPU, and each
set of 12 could only be driven from the appropriate CPU*).   Other
than that, the CPUs in all of the S/370 and later AP and MP features
were fully symmetrical.

With XA I/O was further abstracted, and all CPUs could drive all
channels (although they largely stopped actually referring to channels
at that point, rather the OS drove an I/O to a device, and the
hardware would find a free channel connected to that device to use).


*Ignoring the channel set switching feature.  *Bleech*  Which,
somewhat to my amazement,  has made something of a comeback with
logical channel sets...

[toc] | [prev] | [next] | [standalone]

#3369

In article <pg81671u52acdif0dm01em0ie0rudjv1j5@4ax.com>,
Robert Wessel  <robertwessel2@yahoo.com> wrote:
>
>>Thanks for remind me about the 3084 - dammit, we used one! - yes,
>>IBM introduced modern SMP before the 390 series, though it wan't
>>until then that systems became properly symmetric.
>
>It somewhat depends on your definition of "properly symmetric."  I/O
>on the pre-XA MP systems was partitioned amongst the various CPUs (a
>MP 3033 might, for example, have 24 channels, 12 on each CPU, and each
>set of 12 could only be driven from the appropriate CPU*).   Other
>than that, the CPUs in all of the S/370 and later AP and MP features
>were fully symmetrical.

Yes and no.  The boot CPU was configured at a VERY low level, and it
constrained a lot of what could be done thereafter.  I can't remember
the details, as it wasn't my job anyway, but I do remember that it
was easier to get hardware fixed than reconfigure to use another boot
node.  I believe that a lot of that was software constraints.


Regards,
Nick Maclaren.

[toc] | [prev] | [next] | [standalone]

#3384

On Fri, 2 Sep 2011 11:39:36 +0100 (BST), nmm1@cam.ac.uk wrote:

>In article <pg81671u52acdif0dm01em0ie0rudjv1j5@4ax.com>,
>Robert Wessel  <robertwessel2@yahoo.com> wrote:
>>
>>>Thanks for remind me about the 3084 - dammit, we used one! - yes,
>>>IBM introduced modern SMP before the 390 series, though it wan't
>>>until then that systems became properly symmetric.
>>
>>It somewhat depends on your definition of "properly symmetric."  I/O
>>on the pre-XA MP systems was partitioned amongst the various CPUs (a
>>MP 3033 might, for example, have 24 channels, 12 on each CPU, and each
>>set of 12 could only be driven from the appropriate CPU*).   Other
>>than that, the CPUs in all of the S/370 and later AP and MP features
>>were fully symmetrical.
>
>Yes and no.  The boot CPU was configured at a VERY low level, and it
>constrained a lot of what could be done thereafter.  I can't remember
>the details, as it wasn't my job anyway, but I do remember that it
>was easier to get hardware fixed than reconfigure to use another boot
>node.  I believe that a lot of that was software constraints.


That would have been an artifact of the segregation of the I/O
channels.  Each CPU in a configuration was architecturally required to
have its own IPL (boot) controls (the PoO does limit that requirement
to CPUs could perform I/O, so APs didn't have load controls, but they
had the rest).

So booting from the other CPU was not a hardware issue, but you'd have
to convince to OS to do that, and unless and you had a dual channel
connection to the boot device (and other critical volumes), you'd have
to have alternate versions of those available.  I could easily see MVS
of that era having issues unless you did a lot of prep work to get
everything set up just so.  And of course that sort of thing never
actually works the first few times you try it.

Otherwise you have to start swapping channels around, and then redo
the I/O configuration, and...  Yeah - probably a lot faster to wait to
get the hardware fixed.

[toc] | [prev] | [next] | [standalone]

#3366

On Fri, 2 Sep 2011 09:19:51 +0100 (BST), nmm1@cam.ac.uk wrote:

>In article <r54067hcb735luri3r06g7l5gph7ali7mj@4ax.com>,
>Robert Wessel  <robertwessel2@yahoo.com> wrote:
>>
>>Starting with the 3080 series, IBM supported four processors.  IBM
>>called the two CPU 3081s "dyadic", and had some other term (which
>>escapes me at the moment) for the four CPU 3084, but the 3084 could be
>>physically partitioned into two 3081 equivalents.
>>
>>Parallel Sysplex is a much later term, and refers to the IBM
>>clustering technology for zOS.
>
>Damn newsreader!
>
>Can you remember what the term used for the short-lived and
>unsuccessful linked CPUs that were intended for failover?  That
>was based on the 3033, if I recall.  It was something very like
>parallel sysplex.


The only thing I remember for the 3033 was the "Alternate CPU
Recovery" feature, which required a 3033MP as a base.  I think that
only worked with MVS.  IIRC, this was a hybrid of the MP and
partitioned modes of a 3033MP, so you were effectively running a
uniprocessor 3033, but with a second one as a hot spare.

I never actually encountered a 3033 running like that, but it was in
some of the documentation.



>Thanks for remind me about the 3084 - dammit, we used one! - yes,
>IBM introduced modern SMP before the 390 series, though it wan't
>until then that systems became properly symmetric.


It somewhat depends on your definition of "properly symmetric."  I/O
on the pre-XA MP systems was partitioned amongst the various CPUs (a
MP 3033 might, for example, have 24 channels, 12 on each CPU, and each
set of 12 could only be driven from the appropriate CPU*).   Other
than that, the CPUs in all of the S/370 and later AP and MP features
were fully symmetrical.

With XA I/O was further abstracted, and all CPUs could drive all
channels (although they largely stopped actually referring to channels
at that point, rather the OS drove an I/O to a device, and the
hardware would find a free channel connected to that device to use).


*Ignoring the channel set switching feature.  *Bleech*  Which,
somewhat to my amazement,  has made something of a comeback with
logical channel sets...

[toc] | [prev] | [next] | [standalone]

#3367

In article <rg9167te58lurkh5kis219fk2fpdhg28j4@4ax.com>,
Robert Wessel  <robertwessel2@yahoo.com> wrote:
>
>The only thing I remember for the 3033 was the "Alternate CPU
>Recovery" feature, which required a 3033MP as a base.  I think that
>only worked with MVS.  IIRC, this was a hybrid of the MP and
>partitioned modes of a 3033MP, so you were effectively running a
>uniprocessor 3033, but with a second one as a hot spare.
>
>I never actually encountered a 3033 running like that, but it was in
>some of the documentation.

That's it.  I spoke to a few people who had tried it, and they were
NOT happy bunnies!


Regards,
Nick Maclaren.

[toc] | [prev] | [next] | [standalone]

#3371

Robert Wessel <robertwessel2@yahoo.com> writes:
> It somewhat depends on your definition of "properly symmetric."  I/O
> on the pre-XA MP systems was partitioned amongst the various CPUs (a
> MP 3033 might, for example, have 24 channels, 12 on each CPU, and each
> set of 12 could only be driven from the appropriate CPU*).   Other
> than that, the CPUs in all of the S/370 and later AP and MP features
> were fully symmetrical.
>
> With XA I/O was further abstracted, and all CPUs could drive all
> channels (although they largely stopped actually referring to channels
> at that point, rather the OS drove an I/O to a device, and the
> hardware would find a free channel connected to that device to use).
>
>
> *Ignoring the channel set switching feature.  *Bleech*  Which,
> somewhat to my amazement,  has made something of a comeback with
> logical channel sets...

re:
http://www.garlic.com/~lynn/2011k.html#82 'smttter IBMdroids
http://www.garlic.com/~lynn/2011k.html#84 'smttter IBMdroids

as previously mentioned, 360/67 multiprocessor support had "channel
director" which allowed all processors direct access to all channels.
discussed in some detail in 360/67 functional characteristics
http://www.bitsavers.org/pdf/ibm/360/funcChar/GA27-2719-2_360-67_funcChar.pdf

by comparison 360/65MP and all 370 MPs had processor specific channels
... and "symmetric" multiprocessor I/O was simulated by having pairs of
processor specifical channels connected to same "twin-tailed" device
controller.

as mention in previous posts all 303x channels were actually the 370/158
engine running integrated channel microcode ... it was called a "channel
director" ... but totally different from 360/67 multiprocessor channel
director. The 370/158 integrated channel microcode supported six
channels. So a 12 channel 3033 required two 370/158 engines (channel
directors). A 16 channel 3033 required three 370/158 engines (with two
channel unused). A 24 channel 3033mp required four 370/158 engines ...
two attached/dedicated to each processor (for 12 channels each).

a big part of XA I/O was horribly long I/O path in the MVS supervisor.
High-performace disk I/O was starting to hit brickwall in MVS systems
because of long device I/O redrive latency. I/O queues were managed in
the software ... and there was long (and increasing) synchronous latency
delay between the time that a device I/O completed and the time MVS
could get the next I/O started. A big part of XA I/O was to mask this
synchronous delay latency that was becoming a larger & larger throughput
bottleneck ... by moving the queue in the hardware ... allowing the
hardware to immediately redrive the device.

I mention in this post having designed something similar during 1975 for
5-way 370 SMP effort in conjunction with some POK engineers ... well
before work started on XA:
http://www.garlic.com/~lynn/2011k.html#79 Selectric Typewriter--50th Anniversary
other past posts mentioning 370 5-way 370 (canceled before announced or
shipped)
http://www.garlic.com/~lynn/submain.html#bounce

After transferring to san jose research ... they let me wander around
disk engineering on san jose plant site and play disk engineer. bldgs.
14&15 had computer rooms for testing development devices. The processors
were being scheduled "stand-alone" dedicated time, 7x24 around the clock
for each individual device testing. At one point they attempted to bring
the processors with MVS so that on-demand, concurrent testing could go
on ... but found that MVS had 15min MTBF (between hangs and/or failures
requiring reboot), even with only single device testing. I offerred to
do rewrite of the I/Os subsystem so that it was bullet proof and never
hanged or failed ... providing engineering development with
significantly increased productivity ... on-demand, concurrent testing
of any number of devices. misc. past posts getting to play disk
engineer
http://www.garlic.com/~lynn/subtopic.html#disk

As definition of XA I/O was maturing ... one of the demo things I tried
to do with the I/O subsystem rewrite was to see how close I could come
to XA I/O redrive throughput with simple 370 programming (highly
optimized pathlength for interrupt handling indicating the end of
previous i/o and being able to redrive the device with the next queued
i/o).

Another thing that XA I/O tried to move into hardware was "dynamic
pathing" ... for configurations where same system would have multiple
channels connected to the same controller (for parallel I/O activity)
... and allowing the hardware to choose the first available channel path
to get to device.

Up until then most systems had implemented (software) primary and
alternate channel pathing (to same set of devices). I did I/O subsystem
software rewrite to do load-balancing use of multiple channel paths ...
and it failed miserably. It turns out that the new generation of
high-performance disk controllers 3880 ... for new generation of 3380
disks ... actually had very slow processor for handling commands (with
separate hardware path for data transfer) ... especially compared to its
predecessor 3830. The 3880 controller had enormous additional internal
processing overhead and latency if it got two succesive I/O requests
from different channel connections (especially compared to two
successive I/O requests from the same channel connection) ... measured
in milliseconds. It turns out that I could get better throughput with a
primary w/alternate implementation ... compared to a load-balancing
implementation (with the reduction in 3880 disk controller overhead by
minimizing the number of different channels that 3880 had to deal with
concurrently).

Note, dynamic pathing also added a bunch of complexity in the (3380)
disk controller ... as if it wasn't already slow enough and didn't
already have enough to do. I provided them with a much more efficient
alternative implementation for dynamic pathing ... but they said I was
too late ... that their existing implementation had already been cast in
concrete. misc. past posts methioning dynamic pathing:
http://www.garlic.com/~lynn/2006d.html#3 Hercules 3.04 announcement
http://www.garlic.com/~lynn/2006d.html#15 Hercules 3.04 announcement
http://www.garlic.com/~lynn/2007h.html#9 21st Century ISA goals?
http://www.garlic.com/~lynn/2007i.html#33 Internal DASD Pathing
http://www.garlic.com/~lynn/2008d.html#52 Throwaway cores
http://www.garlic.com/~lynn/2009q.html#79 Now is time for banks to replace core system according to Accenture

-- 
virtualization experience starting Jan1968, online at home since Mar1970

[toc] | [prev] | [next] | [standalone]

#3372

re:
http://www.garlic.com/~lynn/2011k.html#82 'smttter IBMdroids
http://www.garlic.com/~lynn/2011k.html#84 'smttter IBMdroids
http://www.garlic.com/~lynn/2011k.html#86 'smttter IBMdroids

3033 being a q&d effort ... get out something in the 370
market place after the failure of Future System 
http://www.garlic.com/~lynn/submain.html#futuresys

because the killing off of 370 efforts during Future System is credited
with giving the clone processor vendors a market foothold. This
was going on in parallel with the 370xa & 3081 effort ... which
was also something of a Q&D hurry up effort ... but taking
much longer ... discussed in some detail in this reference:
http://www.jfsowa.com/computer/memo125.htm

3033 was starting to see lots of competition from endicott's
mid-range 4341 ... old email
http://www.garlic.com/~lynn/lhwemail.html#4341

clusters (loosely-coupled multiprocessing) of 4341s were cheaper, had
higher aggregate throughput, had more aggregate I/O, had more aggregate
memory, and required significantly less physical resources than 3033. At
one point the mid-range 4341 competition so bothered POK (responsible
for high-end 3033) that the head of POK slipped through manufacturing
allocation that cut the corporate allocation to Endicott of a critical
component for 4341 manufacturing in half.

some large customers were starting to have orders of 4341s in multiples
of hundreds and placing them out in departmental supply & conference
rooms (didn't require all the datacenter physical planning required for
3033) ... sort of the leading edge of the distributed computing wave.
Internally, the proliferation of distributed 4341s into departmental
areas was starting to make corporate conference rooms a scarce resource.

By the time of the 3033, MVS was becoming increasingly bloated in lots
of different wasy. The maximum amount of 370 real memory that could be
addressed was 16mbytes. Even in a 3033MP configuration the maximum
amount of 370 real memory was still limited to 16mbytes.

The MVS real-storage footprint bloat was becoming a throughput
bottleneck (pushing the 16mbyte limitation wall) for single 3033
processor ... and even much more so in a 3033MP two-processor
configuration (which was also still limited to 16mbyte).

In a real hack to get around the restriction ... a 3033 design was
created that allowed for 26 bit address lines (64mbyts) even though real
and virtual addressing was still limited to 24bits. The 370 page table
entry was 16bits, with 12bit real (4kbyte) page number, two defined
function bits and two undefined bits. The hack involved prepending the
two undefined bits to the 12bit real page number for 14bit real 4k page
number (or 64mbyte addressing). Lots of MVS addressing and operation was
limited to below the 16mbyte line ... but application virtual pages
could reside above the 16mbyte line ... each application virtual address
space was still limited to 16mbytes ... but with lots of different
virtual address spaces ... some amount of the virtual pages could reside
above the 16mbyte (real) address line (and with the magic of the hacked
page table entry, 24bit virtual addresses could be turned into 26bit
real addresses). This 3033 >16mbyte hack somewhat alleviated the bloated
MVS real-storage bottleneck ... there continued to be a "below the
(16mbyte) line" real storage constraint for many MVS things.

Even after 370/xa, mvs/xa and the introduction of 31bit addressing on
3081 ... MVS design point still had a "below the (16mbyte) line" storage
constaint (things that had to reside <16mbyte real storage). Even today
with hundreds of gigabytes of real storage, 64bit addressing ... there
are still reverences to MVS having a "below the (16mbyte) line"
constaint.

Normal 360 & 370 I/O operations (also) only allow for 24bit real
addressing. However, there was an extra feature added to 370 channel I/O
program that allowed for a storage address to be specified in 32bit full
word. This was taken advantage of in the 3033 >16mbyte hack to allow
specifying 26bit real storage operation for doing data transfers (like
paging virtual pages between real storage and disk). 

Part of the "below the (16mbyte) line" constraint was some operations on
virtual pages required it to be below the 16mbyte line. If virtual page
was above the line, then it had to be brought "below the line". Their
original design was to use the I/O system to write the virtual page to
disk (from its "above the line" location) and read it back in "below the
line). I provided them with a simple hack of fiddling pagetable entry
values and then do a MVCL 4k copy from one virtual address to another
... which happened to be from a real storage location above the line to
a real storage location below the line. 

Misc. past posts mentioning above/below the line hacks:
http://www.garlic.com/~lynn/2000d.html#82 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
http://www.garlic.com/~lynn/2004e.html#41 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004f.html#38 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004k.html#44 Wars against bad things
http://www.garlic.com/~lynn/2005.html#34 increasing addressable memory via paged memory?
http://www.garlic.com/~lynn/2005p.html#19 address space
http://www.garlic.com/~lynn/2005q.html#30 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005u.html#44 POWER6 on zSeries?
http://www.garlic.com/~lynn/2006.html#13 VM maclib reference
http://www.garlic.com/~lynn/2006l.html#2 virtual memory
http://www.garlic.com/~lynn/2006m.html#27 Old Hashing Routine
http://www.garlic.com/~lynn/2006w.html#23 Multiple mappings
http://www.garlic.com/~lynn/2007b.html#34 Just another example of mainframe costs
http://www.garlic.com/~lynn/2007g.html#59 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
http://www.garlic.com/~lynn/2007r.html#56 CSA 'above the bar'
http://www.garlic.com/~lynn/2008f.html#12 Fantasy-Land_Hierarchal_NUMA_Memory-Model_on_Vertical
http://www.garlic.com/~lynn/2009g.html#71 308x Processors - was "Mainframe articles"
http://www.garlic.com/~lynn/2009g.html#74 308x Processors - was "Mainframe articles"
http://www.garlic.com/~lynn/2009l.html#67 ACP, One of the Oldest Open Source Apps
http://www.garlic.com/~lynn/2010.html#84 locate mode, was Happy DEC-10 Day
http://www.garlic.com/~lynn/2010.html#86 locate mode, was Happy DEC-10 Day
http://www.garlic.com/~lynn/2010b.html#87 "The Naked Mainframe" (Forbes Security Article)
http://www.garlic.com/~lynn/2010d.html#74 Adventure - Or Colossal Cave Adventure
http://www.garlic.com/~lynn/2010g.html#36 16:32 far pointers in OpenWatcom C/C++
http://www.garlic.com/~lynn/2010l.html#6 Z/OS 31bit or 64bit

-- 
virtualization experience starting Jan1968, online at home since Mar1970

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.arch

csiph-web