I know of a couple of places running a single CPU, probably because the
mainframes were supposed to be replaced by Windows/Unix - except they
ended up staying for a handful of applications deemed too difficult to
move. A single processor bothers me too, but these systems are hanging
by a thread and there is no money available.
I remember having a system failure one day running a single processor
(maybe Skip Robinson can remember the details). I think he got IBM
involved and the result was that the software failure would not have
occurred if we were running more than one processor.
Martin Packer wrote:
FWIW the vast majority of my customer set have multiple engines in their
machines and the vast majority of their LPARs are defined as logical 2-way
and above.
And to think when I got into this game (in 1985) there was still quite a
lot of suspicion of multiprocessors.
Going from a max of 4 to a max of 6 with 3090E was quite a big deal. And
from 6 to 8 (and then to 10) with 9021 likewise. Now we add handfuls at a
time. :-)
Cheers, Martin
Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, IBM
+44-7802-245-584
email: [email protected]
Twitter / Facebook IDs: MartinPacker
Blog:
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
From: Anne & Lynn Wheeler <[email protected]>
To: [email protected]
Date: 01/10/2014 20:16
Subject: Re: zOS 1.13 – CPU latent demand
Sent by: IBM Mainframe Discussion List <[email protected]>
[email protected] (Gibney, Dave) writes:
In my opinion, back in the day, there as a benefit of going to
fewer/faster engines. But, with a deep drop off a precipice when fewer
reached one.
Never again will I willingly agree to be on a single CPU machine.
in the past, multiple engines have been beneficial
1) constraining ill-performing tasks, partially compensating
for poor resource management software.
2) increasing importance of cache hit ratios ... careful control of task
switching can significantly improve cache hit ratios and aggregate
throughput. multiple engines can also help poor resource management
software minimizing task switches resulting in having to change
cache contents each time.
large mainframes use to have large penalty going from one processor to
two processor (and enormous penalty going to four processors). two
processor 370 hardware used to be only 1.8 times single processor
(clocks slowed down to handle cross-cache invalidation) and throughput
typically rated at 1.3-1.5 times single processor (because of enormous
operating system multiprocessor overhead).
in the mid-70s, i managed to do some slight of hand where got nearly 2.0
times throughput with two processors (over one processor), it was some
superfast operating system pathlength for management of two processors
along with careful task switch management ... that improved cache hit
ratio improving throughput compensating for the 20% slowdown hardware
slowdown (part of it was logically a little like SAPs where I/O
interrupt handling could be partially batched on same processor,
improving interrupt handling throughput because of cache affinity of the
interrupt handler and improving cache hit ratio of applications on the
other processor with fewer interrupts).
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
