Wrong defining CPU frequency about open-hardware-monitor

[GoogleCodeExporter]

Wrong values could be caused by the fact, that your system uses a very high
Stopwatch.Frequency (actually this seems to be the TSC of the CPU itself). 
Maybe the
EstimateMaxClock should use a start time offset of "ticks" or "ticks / 2", 
instead of
just "2". Otherwise the "timeEnd - timeBegin" is longer than the intervall 
counted
with the TSC. But this would just explain values that are too small, and yours 
is too
high. 

Does OHM always estimate about 3312 Mhz? What is the range of values (lowest,
highest) you can get from OHM? You need to start OHM a few times, because the
Frequency is estimated only during startup for Pentium 4 CPUs.

Original comment by moel.mich on 22 Apr 2010 at 12:43

• Changed state: Accepted

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I dont know what happened but right now i downloaded the same version from 
site, and 
problem disappeared, i cant repeat wrong result, rebooting three times, run 
program 
five times and get always the same 3015cpu 201bus. Did you change something in 
program?
I dont understand tech stuff what you saying to me, i just noticed this strange 
thing 
and decided write a bug report for helping improve the app. This is not 
important for 
me. and for many other i think, because P4 is realy old CPU.
But if some more info needed you can ask me
PS BIOS at default settings of course

Original comment by [email protected] on 23 Apr 2010 at 12:04

[GoogleCodeExporter]

The technical details above are mostly a note to myself, so you easily ignore 
them.

Thank you very much for testing this once more (and giving feedback on the 
issue).

I did not change anything in the OHM so far. The OHM does only estimate the cpu 
and
bus frequency, and it can occur in rare cases that the estimated value is not 
very
accurate. But its good to know that there can still be cases where the accuracy 
is
not as good as I expected. And I guess this is not limited to P4 CPUs. 

So it could be useful to improve the clock estimation routine further.

Original comment by moel.mich on 23 Apr 2010 at 5:33

[GoogleCodeExporter]

This issue was closed by revision r122.

Original comment by moel.mich on 25 Apr 2010 at 2:40

• Changed state: Fixed