On 3/8/2016 3:58 AM, Scott Chapman wrote:
Even absent the chargeback and software cost issues, how do you do capacity planning with that level of variability? How do you do performance testing? Of course the other platforms that have this sort of technology seem to largely just say something like "oh we just by a 4, 8 or 16 way machine"--but that's possible because of the hardware and software costs being smaller increments. I'm not sure we can make that work in the current z world.
Other platforms price software by cores (that's even true on Linux for z), so software costs for a 16-way machine are 4X those of a 4-way machine. Those platforms have serious financial incentive to limit the number of cores whereas our z-based incentive is to *increase* the number of cores (to obtain more points of dispatch) -- even if it means running sub-capacity. Threads should therefore be quite helpful to us, except...
The great thing about threads is they don't add to software costs for core-based pricing, so if you multithread three IFLs, you get the throughput of of ~4.2 cores for the price of three. Not bad economics.
Setting aside the variability and repeatability issues for a moment, CPU-based chargeback schemes will charge ~4.2 times as much as for those same three cores when multithreading. I consider those economics to be rather unfortunate.
-- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
