The "OLD" ROT for LP:CP was 2:1. More recent hardware (e.g. 2817) have increased this limit to about 3:1 The exact value between 2:1 and 3:1 depends on the level of pain you can endure. YMMV.
The amount of overhead due to context switching when another LP is dispatched varies with the activity and quantity of the LPs. DANGER! Will Robinson DANGER! This IS NOT a linear equation. IMO it tends towards cubic once the 3:1 ratio is exceeded! HTH, <snip> We are thinking about HiperDispatch implementation but I am not sure it is appropriate in our environment. We have a z196 Host = 2817-M66/700 with 12 CPs. There is one large LPAR with a share that allows access to 8.89 CPs. It is assigned 12 LPs. The rest of the LPARs on this box have very low shares. There are 8 additional LPARs and the highest physical processor share is 1.05. The rest of the PP shares vary from 0.16 to 0.53. I am not sure that there is any point to turning on Hiperdispatch for these LPARs. I read an article by Don Deese where he said "HiperDispatch Management Mode cannot be effective in an LPAR unless the LPAR has a share of CPC capacity that results in at least 0.5 (the "#CP" value) equivalent physical processors." This was in a document about the z10 and I am wondering whether it is also true on a z196. If we enable HiperDispatch on the one LPAR will there be a negative effect on the other LPARs? In total now there are 37 LPs assigned for the box. I think this is a high number. </snip> ---------------------------------------------------------------------- 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
