Hi,
Thanks for the replies. Our main concern is whether we will face a performance
degradation for our current zIIP-eligible workload (that are currently running
on multiple CPs) when we make 1 single zIIP processor available for LPAR.
Here the main question is; if zIIP processor is fully utilized, will new
zIIP-eligible jobs/tasks get queued for zIIP or will they be get dispatched
with Central Processor(s)? Will zIIP give up accepting new tasks at some point
so that they will be dispathed by CPs or will those tasks just get delayed for
zIIP?
Thanks and regards.
Mursel Tasgin
Akbank
From: Miklos Szigetvari [EMAIL PROTECTED]
To: IBM-MAIN@bama.ua.edu
Sent: Friday, December 5, 2008 12:01:12 PM
Subject: Re: zIIP queue vs CP dispatch when zIIP is fully utilized
Norman Hollander on DesertWiz wrote:
First part. depends on what you have in IEAOPT for IIPHONORPRIORITY.
One was says that if the Needs Help Dispatcher needs help, it will dispatch
work on the CPs (YES). The other says wait for the zIIP no matter what
(NO).
Second part. There is overhead to route work to a zIIP (in the range of
2-11%).
zIIP processors will NOT likely be in the same Processor Core or Book as the
CP the work is coming from. The largest performance implication comes from
having
to reload the High Speed Buffers (or Level 1 and 1.5 caches). The having to
keep track
SMF data and the switch rate will add a bit.
Also consider the Capacity Planning part. When you add Specialty processors
to the mix
with CPs in an LPAR, that LPAR will now have an increased n-way MP effect.
Example, if
you have a 4-way LPAR and add 1 zIIP and 1 zAAP, that LPAR now behaves
almost like a 6-way.
And only the CPs can run general work.
Remember- Specialty Processors are not for Performance reasons or increasing
capacity.
They are for keeping your license costs from going up when you need to add
more processors.
According our understanding not only , you could free up the general
CP's if you could dispatch something to zIIP
I just di a presentation on this at CAWorld, and will repeat it at Share in
Austin. There
will be a webcast for CA customers in mid-January.
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Scott Barry
Sent: Thursday, December 04, 2008 SYSN 02:56 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: zIIP queue vs CP dispatch when zIIP is fully utilized
On Thu, 4 Dec 2008 14:15:04 -0800, Mursel Tasgin [EMAIL PROTECTED] wrote:
Hi,
Planning to use zIIP processor and try to figure out what performance issues
we may experience.
When zIIP processor is fully utilized (for us: having only 1 zIIP processor,
shared among LPARs of different sysplex's), if new zIIP-eligible works
arrive would they be queued for the zIIP processor or get dispathed on
available CPs?
Does high zIIP utilization(or a single zIIP) cause CP overhead? (ie. because
of queues, switching back-and-forth between zIIPs and CPs)
Thanks and regards.
Mursel Tasgin
Akbank
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
This document reference may be useful on this topic.
Scott Barry
SBBWorks, Inc.
IBM Journal reference - topic on zIIP and zAAP:
zAAPs and zIIPs: Increasing the strategic value of System z
http://www.research.ibm.com/journal/rd/511/wyman.html
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
--
Miklos Szigetvari
Development Team
ISIS Information Systems Gmbh
tel: (+43) 2236 27551 570
Fax: (+43) 2236 21081
E-mail: [EMAIL PROTECTED]
Info: [EMAIL PROTECTED]
Hotline: +43-2236-27551-111
Visit our Website: http://www.isis-papyrus.com
---
This e-mail is only intended for the recipient and not legally
binding. Unauthorised use, publication, reproduction or
disclosure of the content of this e-mail is not permitted.
This email has been checked for known viruses, but ISIS accepts
no responsibility for malicious or inappropriate content.
---
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED
