I am monitoring some machines using WMI, using .NET\'s System.Management
stuff. The query I am using is this:
SELECT Timestamp_Sys100NS, PercentProc
Try using the code create application on that machine and see if you get the right readings http://www.microsoft.com/download/en/details.aspx?id=8572
The formula you are specifically talking about is PERF_100NSEC_TIMER_INV http://msdn.microsoft.com/en-us/library/ms803963.aspx
I have not personally dealt with this problem because I have never seen values below zero.
This is all I have been doing:
/// <summary>
/// PERF_100NSEC_TIMER_INV algorithm.
/// </summary>
/// <param name="n2"></param>
/// <param name="d2"></param>
/// <param name="n1"></param>
/// <param name="d1"></param>
/// <returns></returns>
public static int CalculatePerf100NsecTimerInv(long n2, UInt64 d2,
long n1, UInt64 d1)
{
int usage = 0;
try
{
double dataDiff = (n2 - n1);
double timeDiff = (d2 - d1);
double dUsage = (1 - (dataDiff / timeDiff)) * 100;
// Evaluate
usage = (dUsage >= 0.5) ? Convert.ToInt32(Math.Ceiling(dUsage)) : 0;
}
catch { }
// Return
return usage;
}
Usage:
// Calculate
int cpuTime =
MSPerformanceAlgorithms.CalculatePerf100NsecTimerInv(
current.PercentProcessorTime, current.TimestampSys100Ns,
previous.PercentProcessorTime, previous.TimestampSys100Ns);
If I watch the CPU usage on the task manager for the 2003 box, it matches fine. I think you can disregard anything less than zero as long as you are calculating with these values.
it sounds like a standard "time synchronization" issue to me.
your system's clock is... a clock. in your case, your clock may be running fast (perhaps it completes a minute in 99% of the actual time) so when your computer syncs with an external clock (such as through the Windows Time service) your system time will jump backwards.
alternatively, the user may manually adjust the system time (eg: Date and Time control panel), so it's something you should design for (your users would be very unhappy if setting their system's time crashes your app!)
the way I solve this is by clamping. always require at least 0.0 seconds of "real time" to pass, but also clamp to a maximum of 0.5 seconds, as time adjustment may leap forwards, not only backwards.
i hope that helps.