I assume you have read the Wikipedia page about RDTSC carefully enough? You can not ever fetch current CPU speed using single instruction wrapped into a loop, (to my memory, such a possibility died loooong ago). Instead, to do this, you need to use (BI)OS-level access layer to power subsystems info that can fetch CPU info at different levels, summarize it and make trustable conclusions.

Wikipedia page states that it can be done as long as the operation is restricted to one core. I have done all the tests on 1 core systems. As well as I am getting the correct results on all processors I tried the command.

In either case, if the processor was slowed down the results wouldnt always show the full speed of the processor. Also if chkfreq didnt work properly then this doesnt explain how it is able to give perfectly correct results when acpi_ppc is used.

That said, I am open to suggestions, if you know anything else which can detect running cpu frequency more accurately please let me know.

Quote:

Originally Posted by radcapricorn

I come to this conclusion by what cpufreq and sysctl tell me. Because they do query the hardware in a legitimate, safe and quite precise manner.

Cpufreq tries to set the cpu speed and then updates the sysctl. The value in sysctl does not reflect the current cpu speed. Does you can not be sure of the current running speed of the processor unless you test it externally. So you cant trust that value.

Quote:

Originally Posted by radcapricorn

I would. If it were true, I would.

You dont know if this is true or not because your assumption is based on sysctl value showing the correct cpu frequency which can be wrong. So you can not say with a high level of certainty that it is false or true.

Quote:

Originally Posted by radcapricorn

The answer you seek is embodied in the three paragraphs at the beginning of my reply. For a short review: cpufreq (and sysctl facility) are a well-weighed, tested and approved softgets that WILL work provided the hardware/bios works. chkfreq, on the contrary, is a too simple tool to make such a great judgement as current CPU frequency.

Exactly who says that this cant be done with a simple tool?

Quote:

Originally Posted by radcapricorn

Oh and BTW, have you checked temperature counts while using cpufreq? Don't they change a bit? Mine do.

I have no doubt that it works on certain motherboard/cpu combinations. I have boxes where cpufreq works properly also. (and chkfreq returns the correct speed value for these boxes, so I guess you can at last accept that it is working?)

I tested this by running ubench until the temperature stabilize and used mbmon:
CPU: Intel(R) Pentium(R) 4 CPU 3.06GHz (3059.02-MHz 686-class CPU)

chkfreq reports about 3059380132 for both... temperature was fluctuating between 60-62

As you can see, sysctl is not very trustable. If I were you I wouldnt be blindly trusting it. Cpufreq is failing on some machines without giving errors.

Quote:

Originally Posted by radcapricorn

I do understand it quite well. In fact, we're in a very interesting discussion here. Though I must say I suspect that if anyone else follows this little batallia, they're already becoming bored

And what I'm trying to explain to you is why such a source as chkfreq cannot be lightly trusted despite the fact "it shows correct timings". Especially when it gets compared with the core OS component that exists and extends for several releases now.

As I mentioned chkfreq shows correct results where the cpu frequency is changed properly. You can just copy/paste it and try on your system (well it would have taken much less time to try than argue )