I am by no means attached to jiffies - just seemed like an easy way to get what I wanted.<br><br>what is the most precise and/or accurate (preferrable inexpensive) way to track CPU utilization of a given PID? again, precision & accuracy are important for what I'm trying to prove...<br>
<br><div class="gmail_quote">On Fri, Jan 30, 2009 at 2:39 PM, Chris Kleeschulte <span dir="ltr"><<a href="mailto:chris.kleeschulte@it.libertydistribution.com">chris.kleeschulte@it.libertydistribution.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I studied the Linux kernel pretty heavily in college, but I am no<br>
means an expert. I can say that I would never use jiffies for<br>
benchmarking anything. The code comments surrounding the code in the<br>
kernel illustrates this. That does not really help you though, sorry,<br>
but I would find another method for monitoring cpu utilization. I can<br>
explain why using jiffies is bad, but that may be overkill.<br>
<br>
<br>
<br>
Chris<br>
<div><div></div><div class="Wj3C7c"><br>
On Jan 30, 2009, at 2:05 PM, Sid Lane wrote:<br>
<br>
> all,<br>
><br>
> I'm playing w/a script that monitors cpu utilization (mysqld in my<br>
> case) by taking the delta of user & system jiffies in /proc/$PID<br>
> between loops at regular intervals. since individual jiffy mileage<br>
> may vary I did a calibration test by watching a gzip -c<br>
> bigarsefile.gz > /dev/null. 100% of the time the delta between<br>
> loops is 100 jiffies/sec while top reports that PID @ 100% cpu<br>
> utilization (i.e. saturating one core - the goal for the<br>
> benchmark). this leads me to conclude that a jiffy on my box (dual<br>
> quad-core Dell 2950 running openSuSE 11 FWIW) is .01 CPU*s so I<br>
> should have a theoretical 800 jiffies/sec on this box (8 cores).<br>
> the problem (or ? I can't explain) is that I have a data point for<br>
> my mysqld PID where the 10 second delta is 9,402 (7,586 user/1,834<br>
> sys) which is almost 20% above what should be possible. it would<br>
> make sense if a jiffy were 1/120th of a second (=> 9,600 would be<br>
> available in 10 sec) but (again) my gzip test consistently produces<br>
> 500 per 5 seconds (=> 100/s) so I don't know what to make of this<br>
> data point. I though about lack of time precision in my<br>
> measurements but 18%? for a 30 second sample? when the lowest 5<br>
> second value for the gzip test was 498/highest 502?<br>
><br>
> any idea what to make of this? I need to have confidence in this<br>
> data for scaling testing/planning I'm doing...<br>
</div></div>> _______________________________________________<br>
> Ale mailing list<br>
> <a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
> <a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
<br>
_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
</blockquote></div><br>