However, I downloaded acpi_ppc from http://www.spa.is.uec.ac.jp/~nfukuda/software/ and there comes a program called chkfreq with it which measures the cpu time. It always shows the maximum speed. For example 2992751205 for 3ghz P4 (from the above examples) regardless of what freq is set.

OK lets say the chkfreq is faulty, but I tested this on another machine with 6.2 box with:
CPU: AMD Athlon(tm) 64 Processor 3500+ (2202.83-MHz 686-class CPU)
and acpi_ppc says:

and when at 1000mhz chkfreq shows 1001297861 when I unload acpi_ppc it shows 2202845489.

Then I load cpufreq and I see:
powernow0: <Cool`n'Quiet K8> on cpu0
and run powerd
dev.cpu.0.freq: 1000
dev.cpu.0.freq_levels: 2200/89000 2000/69000 1800/50000 1000/22000
dev.powernow.0.freq_settings: 2200/89000 2000/69000 1800/50000 1000/22000
dev.cpufreq.0.%driver: cpufreq
dev.cpufreq.0.%parent: cpu0
but when I run chkfreq I get 2202846202 (I checked with -v, powerd does not increase speed while testing)

I tested powerd on several machines with p4, athlon64, xeon processors and it seems to work in none of the machines properly.

Does anybody know how any way to check for sure if powerd is really working or not?

The sysctl shows that the cpu frequency is lowered, acpi_ppc is similar to cpufreq and it doesnt check the speed. There comes a small program with acpi_ppc called chkfreq. This chkfreq program uses the RDTSC assembly command to determine the processor speed:http://en.wikipedia.org/wiki/RDTSC

I think you didnt understand the problem here. What I am saying is that the sysctl is showing wrong processor speed than the actual processor speed in all my machines. In essence, cpufreq is doing nothing and faking us that it changed the speed but the speed doesnt change. Got it?

Look, there's no need to attack someone that is trying to help you. I suggest that if you need help and someone tries to help you, you respond politely. Nobody on these forums needs to help anybody, we do it because we want to help. If you attack someone, then nobody else will likely help you.

If the responder didn't understand the question you have asked, then maybe you can re-word it politely to more accurately ask what you want. No need for things like "Got it" and such.

__________________
I just saved a bunch of money on my car insurance by fleeing the scene of the accident!

I didnt think that 'got it?' was offensive, sorry. I wanted to mean 'do you understand now?' (or is that offensive to ask somebody that too?) perhaps you should excuse me as English is not my native language.

It is ok. I know that I make this kind of mistakes from time to time. As I said, english is not my native language so I dont always realize what is offensive and not. Thanks for the warning anyway, I will try to be more careful with my choice of words in future.

Back to the subject, I am putting in the source of the chkfreq program below. This is the same program which ships with acpi_ppc. If you are using cpufreq/powerd then please copy/paste this code into a text file and compile and see your processor and check if sysctl is reporting correctly in your case.

I think, most of the time cpufreq is doing nothing but it is saying that it is doing something. I was fooled earlier that I thought cpufreq was working but now I am pretty sure that it is doing nothing.

Why the seeds of mistrust? Have you overlooked cpufreq source code at least for comparison? Don't get me insulting, but you just sound like "They're cheating us!!!"
IMO, I'd rather trust the utility that exists since 5.(4?) release of FreeBSD as a system component, rather some external softget.

radcapricorn, I already explained why I think it doesnt work and I also gave you a way to test it on your own. Please read my posts as a whole.

I didn't mean to offend, and I don't throw the context away. What I have meant is that you're building your decision on top of say 'untrusted' thing. I might say that, while running powerd and launching that kind of program you've posted (chkfreq I mean), it may well be that the frequency just goes up again so it does show max freq and all.

Quote:

What is inside the cpufreq code is not relevant as you can figure out if it works or not by comparing the processor frequency with what the cpufreq sysctl says only.

Well that's nice... What is inside OS code is irrelevant, but what's inside third-party code is? Are we still talking about OPEN-SOURCE UNIX system or (you-know-what-OS-I-mean)?
cpufreq speaks to drivers that do the actual work. Generally, if ACPI system/drivers on your box may lie, so may cpufreq. But in that case it's not powerd/cpufreq fault anymore.

Quote:

So I explained how I tested the situation and how I test to see if cpufreq is working or not, back to my question, how do 'you' test that cpufreq works?

Well, I hope the people will offer their options. Personally I don't test if I'm certain that ACPI works (if I'm uncertain, I don't use tools like cpufreq so nothing to test here :-) ).

I didn't mean to offend, and I don't throw the context away. What I have meant is that you're building your decision on top of say 'untrusted' thing. I might say that, while running powerd and launching that kind of program you've posted (chkfreq I mean), it may well be that the frequency just goes up again so it does show max freq and all.

The program is pretty trustable and it is based on a well known assembly command. It is very short and you can see the source code to review as well. It also gives correct processor speed on every platform I run it. Also, on the same machines if I change the processor speed using acpi_ppc, then chkfreq reports lowered CPU speed correctly. Perhaps I should point out here that the chkfreq has no code which interacts with acpi_ppc and it does the processor speed test independently so it is not a situation where the tool works with the shipped module only.

Also, if you read my first post, I already mentioned that powerd is not increasing the speed during the test. I have verified this by running powerd with -v switch. Actually even more, I have changed the chkfreq's freq sysctl manually without running powerd at all. So there cant be any such issue.

Can you explain why you think that cpufreq is working? I mean how do you come to this conclusion? I took it granted that it didnt give errors so it must be working until today myself. But now I see that I was wrong.

Quote:

Originally Posted by radcapricorn

Well that's nice... What is inside OS code is irrelevant, but what's inside third-party code is? Are we still talking about OPEN-SOURCE UNIX system or (you-know-what-OS-I-mean)?
cpufreq speaks to drivers that do the actual work. Generally, if ACPI system/drivers on your box may lie, so may cpufreq. But in that case it's not powerd/cpufreq fault anymore.

Here I am trying to verify if cpufreq works or not. It doesnt require going into the code. It is irrelevant if ACPI system lies or not, that would be the cause of the problem if ACPI system lies. Which doesnt change the fact that cpufreq says that it changed the speed but it actually didnt, meaning it doesnt work. If there is this kind of problem, this must be at least documented in the manual. Now people think that it doesnt give error so it must be working.

But if cpufreq doesnt work but acpi_ppc works then wouldnt you say that there is a problem in cpufreq which should be fixed? because it is obviously lying to people and it can be fixed?

Quote:

Originally Posted by radcapricorn

Well, I hope the people will offer their options. Personally I don't test if I'm certain that ACPI works (if I'm uncertain, I don't use tools like cpufreq so nothing to test here :-) ).

With what information you are certain that cpufreq works properly for you? I have to say, "I'm certain" does not qualify as a proof, do you see scientists having theories/hyphothesis backed up with "I'm certain" ?

I asked this to you in my previous post also. How do you know that cpufreq really works? If you cant give a solid, verifiable answer to this question then it means that it is not a fact that it works, it is your opinion/view that it works which can be right or wrong (which makes an opinion without proof mostly useless eh?)

Please understand that I am not trying to be offensive here, but I have put my case with a lot of information and examples and I am getting answers which ignores and omits all those information. I just dont like explaining all again and again.

The program is pretty trustable and it is based on a well known assembly command. It is very short and you can see the source code to review as well. It also gives correct processor speed on every platform I run it.

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.

Quote:

Also, if you read my first post, I already mentioned that powerd is not increasing the speed during the test.

I said "it may well be", not "it will"

Quote:

Can you explain why you think that cpufreq is working? I mean how do you come to this conclusion?

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.

Quote:

But if cpufreq doesnt work but acpi_ppc works then wouldnt you say that there is a problem in cpufreq which should be fixed? because it is obviously lying to people and it can be fixed?

I would. If it were true, I would.

Quote:

With what information you are certain that cpufreq works properly for you? I have to say, "I'm certain" does not qualify as a proof, do you see scientists having theories/hyphothesis backed up with "I'm certain" ?

Ooooh, they actually always say that Well, the answer's above.

Quote:

I asked this to you in my previous post also. How do you know that cpufreq really works? If you cant give a solid, verifiable answer to this question then it means that it is not a fact that it works, it is your opinion/view that it works which can be right or wrong (which makes an opinion without proof mostly useless eh?)

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.

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

Quote:

Please understand that I am not trying to be offensive here,

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

Quote:

but I have put my case with a lot of information and examples and I am getting answers which ignores and omits all those information. I just dont like explaining all again and again.

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.

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 )

My apologies, the cpufreq seems to be working. I dont know how I thought otherwise at first place. Maybe too little sleep However I am now checking all the boxes 1by1 again. I will let you know if I find something weird about this.

It may well be cpufreq WILL fail on some (unsupported) architecture. And the investigation you started is generally a good thing to do. For example, right now I have some issues with pppd and cannot get any feedback on my problems so the only options I have is to negotiate the developers or to dig through OS source

Now, 2 ephemera:

This is an OT actually, but as the topic is closed by now (is it?), I may try:
nanosleep is a function. How it is implemented, you do not know. Who knows, maybe it is doing some funny things with the CPU, so there is no guarantee that after it you'll get the needed result from rdtsc. Of course, this is a mere guess

Last edited by radcapricorn; 12th June 2008 at 11:12 PM.
Reason: Overquoting removed