Regarding jiffies, we found this earlier: http://linux.die.net/man/7/time "On x86 the situation is as follows: on kernels up to and including 2.4.x, HZ was 100, giving a jiffy value of 0.01 seconds; starting with 2.6.0, HZ was raised to 1000, giving a jiffy of 0.001 seconds; since kernel 2.6.13, the HZ value is a kernel configuration parameter and can be 100, 250 (the default) or 1000, yielding a jiffies value of, respectively, 0.01, 0.004, or 0.001 seconds. "
-- anyone know if that holds the same on z hardware implementations? Our RHEL4 level does not have the steal timer metric. I'm in the process right now of trying to verify the CPU number accuracy, but I figure I have to compare what the hipervisor thinks in relation to Linux. Unfortunately when they did this test they didn't let me know so I didn't capture the data at the time, although I might have it squirreled away somewhere. And (even worse) other work was going on the server in addition to the comparison workload, which is why they were trying to capture it from the Linux perspective instead of the hipervisor (which I guess would give much more meaningful data). The VMware CPU utilization is a good question. I know they only run half-capacity servers for failover, but I don't know if that means they run them at 25% or 50% utilization. For z/VM we were planning to calculate to 90%. The test workload was actually a production Java application server that we moved over, so it was doing business transactional workload. Thanks, Tom Stewart -----Original Message----- From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of Barton Robinson Sent: Monday, January 04, 2010 11:17 AM To: LINUX-390@VM.MARIST.EDU 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 lists...@vm.marist.edu 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 lists...@vm.marist.edu 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 lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
