My experience shows that when performing comparison tests on  the z with
other platforms is greatly askew when ONLY measuring one process.  The z10
will show a greater usage for one process to other platforms.  However,
jack up the processes and you will see that the z10 will not increase
measurably while the other platforms will.

Richard (Gaz) Gasiorowski
Global System z Linux /AO Mainframe Services
Product Manager
Americas RPE Portfolio Platform Services
CSC
3170 Fairview Park Dr., Falls Church, VA 22042
845-889-8533|Work|845-392-7889 Cell|[email protected]|www.csc.com




This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to
any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose.



From:
Barton Robinson <[email protected]>
To:
[email protected]
Date:
01/04/2010 12:20 PM
Subject:
Re: x86 to z CPU comparison for calculating IFLs needed



I think you are missing several things. (And jiffies are in 10ms
increments, not 1ms increments)

First, have you verified the accuracy of your CPU numbers?  Does RHEL4
include the steal timer patch and is it working correctly on both VMWare
and z/VM? Even with current levels of Linux and z/VM, the CPU numbers
must be corrected.

2nd, what is your target peak cpu utilization for VMWare, and for z/VM?
I would expect 50% for VMWare (Being very generous i think) and 90% for
z/VM.  So z/VM, the processors get an extra 80% of CPU seconds.

3rd, It looks like you are measuring one "batch" process.  Real work
would have lots of processes, switching between workloads at even 1000's
of times per second.  The cache technology in the z10 will be vastly
superior, and will provide better CPU numbers when measuring an
environment closer to a production reality.

Stewart Thomas J wrote:
> Need some assistance on understanding a workload comparison. Here is
what we have:
>
> We run a business workload (Java/WebSphere) for one week on an HP DL585
G5 server four Quad-Core

AMD Opteron Processors, model 8389 (2.9GHz) on Red Hat Enterprise Linux
4 kernel version 2.6.9.
This is virtualized under VMware ESX.  Using /proc/$$/stat, we see that
our process id consumed
23,525 seconds of "cpu time". We are basing this "cpu time" on the
utime/stime values (from
issuing a cat against /proc/$$/stat). Our understanding is that this is
giving us the total
jiffies consumed, and we are then dividing this by 1000 since the jiffy
timer is a millisecond.
That is how we calculated the "cpu time" in seconds.
>
> We ran this same load on a System z10 EC for a week. This is a z/VM 5.3
LPAR with RHEL4
running as a guest. On the mainframe, we see that our process id
consumed 25,649 seconds of
"cpu time".
>
> We generated what we call an equivalence factor: 23,525 / 25,649 =
0.9172
>
> Based on this, we believe that we'll need ~10% more z10 CPU cores to
process our workload
than we would on our comparison platform.
>
> Question for the audience is - are we not understanding jiffies or the
/proc/$$/stat timers
for cpu calculation correctly? Wondering if we might be missing
something insanely obvious in
comparing cpu time (cores) in this fashion, or if this does seem
reasonable for a Java/WebSphere
workload.
>
> For reference, we have someone in doing a TCO for our workload using
generalized spreadsheets
for the calculations and we are using our internal comparison and the
numbers are way off for
the total estimated IFL count. For an example of what I'm talking about
here, say we have 68
x86 cores for this workload. During overlapping peak times we are
totally consuming 30 of these.
Based on our equivalence factor calculation above, we are saying that
we'll need >30 IFLs to
handle these peaks. Based on the generalized spreadsheet calculations
from those doing the TCO
they claim we can run this peak workload in 8 IFLs. So essentially my
main question from your
experiences are if our own calculations make more sense or if the
generalized spreadsheet
can/cannot be trusted for accuracy.
>
> Any advice or experiences would be welcomed.
>
> Tom Stewart
> Mainframe OS, Networking & Security
> Deere & Company Computer Center
> www.johndeere.com
>
>
>
> ----------------------------------------------------------------------
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO LINUX-390 or
visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
>
>

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390



----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Reply via email to