You are not logged in.
I was testing cpufreq and by ffmpeg converting one file several times I noticed that my CPU is faster with ondemand governor than with userspace set to maximum CPU speed. The speed is definitely correct. What might be wrong?
Offline
You're asking about CPU stuff without mentioning which CPU you have? Jeez...
I'm thinking it's turbo.
Offline
It's Intel Core i5-2410M 2.30 GHz
Here's /proc/cpuinfo: http://pastebin.com/mnBixCGj
How do I turn Turbo on with userspace, then?
Last edited by ernetas (2012-11-03 13:35:07)
Offline
Why do you want to use userspace? Ondemand will run your CPU at its highest speed when necessary, and scale it down at other times. You don't gain anything by using userspace to force it to run at high speed all the time.
Offline
Why do you want to use userspace? Ondemand will run your CPU at its highest speed when necessary, and scale it down at other times. You don't gain anything by using userspace to force it to run at high speed all the time.
Then why such frequency scaling is not implemented into kernel?
Offline
Acctually they are, cpufrequtils is just frontend, and discontinioued (?). As from 3.1 there is another userpsace util called "cpupower", whitch utilize "turbo boost".
Last edited by cybertorture (2012-11-03 13:53:52)
O' rly ? Ya rly Oo
Offline
2ManyDogs wrote:Why do you want to use userspace? Ondemand will run your CPU at its highest speed when necessary, and scale it down at other times. You don't gain anything by using userspace to force it to run at high speed all the time.
Then why such frequency scaling is not implemented into kernel?
From the CPU Frequency Scaling wiki topic:
Since kernel 3.4 the necessary modules are loaded automatically and the recommended ondemand governor is enabled by default.
Offline
Acctually they are, cpufrequtils is just frontend, and discontinioued (?). As from 3.1 there is another userpsace util called "cpupower", whitch utilize "turbo boost".
Great! Thanks.
Offline
Don't forget to mark this as solved if this answers your question. Prepend the title with [Solved] by editing the first post.
Offline
Don't forget to mark this as solved if this answers your question. Prepend the title with [Solved] by editing the first post.
Before doing that, I'd like to clarify: so Intel Turbo Boost works based not only on load, but also on CPU core frequencies? Because I see no reason why Turbo should stop working with higher core frequencies set manually. cpupower shows that Turbo Boost is active in both cases.
Offline
Because with userspace you are specifying the speed to run at. It will not deviate from that. I am unsure how this doens't make sense to you. It is obvious how it deteremines when to use turboboost. But if you lock it to a frequency, there it will stay.
Offline
Because with userspace you are specifying the speed to run at. It will not deviate from that. I am unsure how this doens't make sense to you. It is obvious how it deteremines when to use turboboost. But if you lock it to a frequency, there it will stay.
Agree, it is as it sould, otherwise no reason to lock frequency ( esspecially if your CPU overhead fast with TB) .
O' rly ? Ya rly Oo
Offline
WonderWoofy wrote:Because with userspace you are specifying the speed to run at. It will not deviate from that. I am unsure how this doens't make sense to you. It is obvious how it deteremines when to use turboboost. But if you lock it to a frequency, there it will stay.
Agree, it is as it sould, otherwise no reason to lock frequency ( esspecially if your CPU overhead fast with TB) .
Are you trying to tell me that without CPU frequency scaling in kernel, you can't have Intel Turbo Boost working? Then how do I turn it off, to have maximum frequency on idle and more when running single threaded processes?
Another thing is that ondemand governor does not increase my CPU frequency to 2.9GHz as it is stated on Intel website. Only to 2.301 GHz. Maybe it's a mistake in metrics, but if so - why does cpupower show 2.55 GHz, not 2.9 GHz as a maximum for Turbo Boost?
Last edited by ernetas (2012-11-03 18:03:28)
Offline
I just manually checked it with i7z and setting userspace as a governor and 2.3 GHz as a frequency.
There is a mistake in metrics, because somehow the kernel thinks (according to /sys/devices/system/cpu/cpu*/cpufreq/bios_limit) that the limit is 2.301 GHz. Yet, i7z tool shows that BIOS scales the frequency to 2.86 GHz BOTH when in userspace with 2.3 GHz frequency for all cores and in ondemand governors for all cores. Hence, you were wrong.
But it still does not explain why "performance" governor fails to outrun "ondemand" governor by a few seconds on ffmpeg test.
CPU running in ondemand converted AVI to MP3 in 1:37, while CPU running in userspace at maximum frequency converted AVI to MP3 in 1:42 (measured with "time" command).
Last edited by ernetas (2012-11-03 18:24:29)
Offline
Are you trying to tell me that without CPU frequency scaling in kernel, you can't have Intel Turbo Boost working?
Why does this surprise you?
to have maximum frequency on idle
Why on Earth would you want that?? Why would you intentionally create more heat and burn more electricity for no benefit whatsoever?
Offline
ernetas wrote:Are you trying to tell me that without CPU frequency scaling in kernel, you can't have Intel Turbo Boost working?
Why does this surprise you?
Because, it's BIOS by definition that implements Turbo Boost. Setting 2.3 GHz frequency with kernel tools does not turn off Intel Turbo Boost.
ernetas wrote:to have maximum frequency on idle
Why on Earth would you want that?? Why would you intentionally create more heat and burn more electricity for no benefit whatsoever?
It should offer higher performance, shouldn't it? But it doesn't, it gives considerably less performance than ondemand governor. Why? I'm just curious, nothing more.
Last edited by ernetas (2012-11-03 18:51:41)
Offline
Gusar wrote:ernetas wrote:Are you trying to tell me that without CPU frequency scaling in kernel, you can't have Intel Turbo Boost working?
Why does this surprise you?
Because, it's BIOS by definition that implements Turbo Boost. Setting 2.3 GHz frequency with kernel tools does not turn off Intel Turbo Boost.
Gusar wrote:ernetas wrote:to have maximum frequency on idle
Why on Earth would you want that?? Why would you intentionally create more heat and burn more electricity for no benefit whatsoever?
It should offer higher performance, shouldn't it? But it doesn't, it gives considerably less performance than ondemand governor. Why? I'm just curious, nothing more.
Exactly, the bios ultimately controls frequency, Linux just assumes that what the CPU reports is max frequency is the same as the bios, but in the case of overclocking and turbo boost it's not.
My box for example is set up to run @ 4.4GHz through the bios, my CPU reports it's max as 3.3GHz so Linux assumes 4.4Ghz is 3.3GHz, only i7z will tell me the truth. I'm not sure what the deal is with bios_limit, because it's not reported from the bios because it's wrong, mine shows 3.3GHz - it seems that the chip reports this just like it reports cpupower & cpuinfo.
This is why I set up my overclocks on windows - http://www.meyithi.com/graphics/oc.png - and then I usually nuke the windows partition when happy and use i7z to check the overclock, everything else is wrong.
Offline
Because, it's BIOS by definition that implements Turbo Boost. Setting 2.3 GHz frequency with kernel tools does not turn off Intel Turbo Boost.
Turbo works by temporarily increasing the frequency, depending on thermal conditions and what number of cores are in use and possibly other heuristics. How do you expect this to work if you've locked the CPU into a fixed frequency? It's not possible. A fixed frequency is a fixed frequency.
It should offer higher performance, shouldn't it?
Idle means the processor is doing nothing. Doing nothing at a higher frequency will... still do nothing. Except burn electricity and produce heat.
There are very, very, *very* few reasons to not use the ondemand governor. You don't have any such reasons.
Offline
ernetas wrote:Because, it's BIOS by definition that implements Turbo Boost. Setting 2.3 GHz frequency with kernel tools does not turn off Intel Turbo Boost.
Turbo works by temporarily increasing the frequency, depending on thermal conditions and what number of cores are in use and possibly other heuristics. How do you expect this to work if you've locked the CPU into a fixed frequency? It's not possible. A fixed frequency is a fixed frequency.
It works. Do you want me to film it?
You totally don't understand what cpufreq does. It only sets the frequency, but leaves Intel Turbo Boost on. When using ondemand governor, cpufreq sets CPU frequency. It is exactly the same as userspace governor - ondemand governor ALSO fixes a frequency, but it "refixes" it when needed.
ernetas wrote:It should offer higher performance, shouldn't it?
Idle means the processor is doing nothing. Doing nothing at a higher frequency will... still do nothing. Except burn electricity and produce heat.
There are very, very, *very* few reasons to not use the ondemand governor. You don't have any such reasons.
By idle I mean 3-4% utilization, which is often considered as idle. By doing nothing at a higher frequency it will not burn more electricity and produce heat - as you said, it does nothing when idle.
Very few? How about high latency server?
Offline
It works. Do you want me to film it?
Yes. But even if it's true, that turbo ups the freq even with the userspace governor, there's still no reason to use it over ondemand. You're still seriously impacting the thermal conditions by not allowing the processor to use it's power management as it was intended to.
It is exactly the same as userspace governor - ondemand governor ALSO fixes a frequency, but it "refixes" it when needed.
That makes no sense.
By idle I mean 3-4% utilization, which is often considered as idle.
Read this: https://lesswatts.org/projects/applicat … o-idle.php. By using the userspace governor you're interfering with that.
By doing nothing at a higher frequency it will not burn more electricity and produce heat - as you said, it does nothing when idle.
It still ticks. It just does doesn't do anything at every tick. So yes, it *will* burn more electricity and produce heat. You think processor makers developed dynamic frequencies just for fun? No, they did it because of very specific improvements. That you're actively working against.
Very few? How about high latency server?
When CPUs are closely packed in server racks, proper power management is even more important. You will not gain anything by artificially holding the processor at a high frequency. Only increase the electricity bill, because you'll need stronger cooling.
Offline
ernetas wrote:It works. Do you want me to film it?
Yes. But even if it's true, that turbo ups the freq even with the userspace governor, there's still no reason to use it over ondemand. You're still seriously impacting the thermal conditions by not allowing the processor to use it's power management as it was intended to.
Here it is: https://www.dropbox.com/s/hyxvw30n485rn72/cpufreq.ogv
If it's idle - it does not do anything, according to you, and hence it does not generate as much electricity. Of course, it will generate more electricity than an analogical CPU idle at a lower frequency, but not that significantly. If some kind of small calculation comes up - a CPU under performance governor should do it faster than ondemand, because it does not need to wait for the average utilization reach 95%.
It's power management was not intended to be under cpufreq. On Windows you have to install spec. drivers to get frequency scaling.
ernetas wrote:It is exactly the same as userspace governor - ondemand governor ALSO fixes a frequency, but it "refixes" it when needed.
That makes no sense.
How? What cpufreq does is scaling a CPU frequency. In other words, it sets a frequency. Don't you agree?
Governor just defines how and when it should be done. Doesn't it?
Setting a frequency is, by your definition, "making it fixed", so it does not matter what governor we talk about - all of them, according to you, make CPU frequency "fixed". Now, THAT does not make sense.
Another thing: according to you, cpufreq fully controls CPU frequency. But Intel Turbo Boost is a BIOS technology and it is in BIOS, not in cpufreq code lines. That does not make sense, as well.
ernetas wrote:By idle I mean 3-4% utilization, which is often considered as idle.
Read this: https://lesswatts.org/projects/applicat … o-idle.php. By using the userspace governor you're interfering with that.
First of all, this includes voltage scaling.
Second, this shows that running CPU at highest frequency is consuming less energy. Could you elaborate on that with your own words?
ernetas wrote:By doing nothing at a higher frequency it will not burn more electricity and produce heat - as you said, it does nothing when idle.
It still ticks. It just does doesn't do anything at every tick. So yes, it *will* burn more electricity and produce heat. You think processor makers developed dynamic frequencies just for fun? No, they did it because of very specific improvements. That you're actively working against.
So it ticks. You said it does absolutely nothing.
I'm not working against CPU frequency throttling. I'm very happy with it. I'm just saying you don't understand how cpufreq works at all. It does not fixate a CPU frequency. It only sets a nominal maximum frequency, while real frequency differs, so does power consumption.
[ Only increase the electricity bill, because you'll need stronger cooling.
It's a single server, not racks, so no stronger cooling required. Running with ondemand governor would produce same results if it would be constantly on full load. We are talking about the time it takes for it to get back from idle state.
CONCLUSIONS (mostly from the video):
cpufreq does not make frequency fixed. It can only set the maximum frequency the CPU will operate at full load.
That means that when idle, it will be working on lower frequencies than
Now, yes, it is worth throttling frequency when CPU is more or less idle, because, i.e., in the video the frequency never goes below 1.8 GHz.
But it does not mean that cpufreq fixates the frequency.
cpufreq also does not disable BIOS from implementing Intel Turbo Boost, if you allow it.
We had this long discussion, in most of which part I was just trying to make arguments to argue my opinion about cpufreq, not whether CPU throttling is a good thing, but you still came to this question somehow.
My question why ffmpeg does worse when cpufreq is in userspace than in ondemand was left unanswered. (in the video the difference is only ~1 sec. probably because the screen recording software was consuming more resources and hence overall the whole task took almost twice as long to accomplish than without recording screen)
Offline
a CPU under performance governor should do it faster than ondemand, because it does not need to wait for the average utilization reach 95%.
That's such a small part of the whole operation, it's completely insignificant in the end. Frequency switches happen in millisecond intervals.
It's power management was not intended to be under cpufreq.
Power management is a complex thing. And cpufreq is very much part of it.
On Windows you have to install spec. drivers to get frequency scaling.
I would actually have to check that, I'd find it weird if Vista and 7 didn't already have cpufreq drivers out-of-the-box. Even if they don't, how is that different from Linux? Here too you need to load the cpufreq driver. We now have the luxury of it happening automatically since kernel 3.4, but before a user needed to take care of it themselves.
How? What cpufreq does is scaling a CPU frequency. In other words, it sets a frequency. Don't you agree?
Depends on the governor. Some set a frequency. Others dynamically scale it all the time. With these dynamic scaling governors, the state changes every few milliseconds. I would not call constant changes "setting a frequency".
Setting a frequency is, by your definition, "making it fixed"
Setting a frequency is setting a frequency. There's no "my definition", there's just common sense.
so it does not matter what governor we talk about - all of them, according to you, make CPU frequency "fixed".
Wait, what? How did you get to that conclusion? I don't see how it follows from what was previously said.
Now, THAT does not make sense.
When you make weird conclusions, of course it doesn't make sense.
Another thing: according to you, cpufreq fully controls CPU frequency. But Intel Turbo Boost is a BIOS technology and it is in BIOS, not in cpufreq code lines.
First, I reserved the possibility that turbo works even with the userspace governor. *But*, did you notice in your video that turbo didn't kick in until you set the freq to 2.31? When you set it to 2.30 turbo did *not* work, the CPU was constantly at 23x. So 2.30 means literally "2.30", while 2.31 seems to mean "as fast as possible, including turbo".
First of all, this includes voltage scaling.
It does, yes. So what? It's several mechanisms working together, one of them being frequency scaling. All of them combined are required for proper power management. All of them combined required for turbo to provide the most benefits.
Second, this shows that running CPU at highest frequency is consuming less energy. Could you elaborate on that with your own words?
No, it does not show that. It shows less energy consumption by switching high to complete a task as fast as possible, so that the processor can go back to idle as soon as possible.
Switch high quickly to make it possible to switch low quickly - that's exactly what ondemand does.
I'm not working against CPU frequency throttling.
If you're not using ondemand, you are.
I'm just saying you don't understand how cpufreq works at all. It does not fixate a CPU frequency. It only sets a nominal maximum frequency, while real frequency differs, so does power consumption.
There were indeed fluctuations with the userspace governor while the processor was not doing much. I found that interesting. Though now the question is, was the freq really fluctuating, or is it a quirk of i7z? I would be really, really interested in the answer to that. Still, the freq was at all times higher than with ondemand, screwing with the processor's power management.
Running with ondemand governor would produce same results if it would be constantly on full load.
But a server is never constantly on full load.
My question why ffmpeg does worse when cpufreq is in userspace than in ondemand was left unanswered.
I already answered it, at the very beginning - turbo. Your video showed that with the userspace governor turbo did not kick in when you set a valid frequency. Only after you've set a value that seems to mean "as fast as possible" did it kick in. Though that in itself still does not explain the different encoding times. However I do have an explanation, and it's a very simple one: Like I said, one of the heuristics for turbo is thermal conditions. In the slower encode thermal conditions were worse, so turbo did not kick in as often.
Because there's one thing you need to understand: i7z refreshes every 1 second or maybe every 0.5 seconds. But freq changes happen, like I said above, in *millisecond* intervals. So there's tons of freq changes that you do not see when looking at i7z. So you might think the processor works the same in every encode, but the reality is different, because heuristics that control turbo differ.
Last edited by Gusar (2012-11-04 01:28:59)
Offline
ernetas wrote:a CPU under performance governor should do it faster than ondemand, because it does not need to wait for the average utilization reach 95%.
That's such a small part of the whole operation, it's completely insignificant in the end. Frequency switches happen in millisecond intervals.
I can see that you argue without any proof and just based on your own opinion... Way to go. Let me quote ArchLinux Wiki:
With the out-of-the-box configuration, the ondemand governor will result in a slight but measurable and noticeable loss of performance.
ernetas wrote:It's power management was not intended to be under cpufreq.
Power management is a complex thing. And cpufreq is very much part of it.
So what?
By saying that CPUs power management was not intended to under cpufreq I mean, that Intel did not gave support for the creation of this utility, which is now integrated in kernel. Which part of this sentence imply that power management is a complex thing? Stop talking off topic.
ernetas wrote:On Windows you have to install spec. drivers to get frequency scaling.
I would actually have to check that, I'd find it weird if Vista and 7 didn't already have cpufreq drivers out-of-the-box. Even if they don't, how is that different from Linux? Here too you need to load the cpufreq driver. We now have the luxury of it happening automatically since kernel 3.4, but before a user needed to take care of it themselves.
Sorry, my bad - on Windows you DON'T have to install any drivers. Because power management is done via BIOS and not Windows OS. How come? You can use Windows Vista, which was released before Intel Turbo Boost and before you CPU, but it still runs perfectly and implements Intel Turbo Boost without any additional drivers.
ernetas wrote:How? What cpufreq does is scaling a CPU frequency. In other words, it sets a frequency. Don't you agree?
Depends on the governor. Some set a frequency. Others dynamically scale it all the time. With these dynamic scaling governors, the state changes every few milliseconds. I would not call constant changes "setting a frequency".
So, dynamic scaling governors are still basically the same thing as userspace, but it's just changes the frequency every "few milliseconds" (which, according to ArchLinux Wiki, is not the case and you can stop arguing about it).
ernetas wrote:Setting a frequency is, by your definition, "making it fixed"
Setting a frequency is setting a frequency. There's no "my definition", there's just common sense.
Let me quote:
How do you expect this to work if you've locked the CPU into a fixed frequency? It's not possible. A fixed frequency is a fixed frequency.
Here you called userspace "setting frequency" as "locking a frequency into a fixed". So I assume this implies the same thing as "setting a frequency" and since, as you say, "setting a frequency is setting a frequency", so just as userspace sets a frequency till you manually change it, so does ondemand governor sets a frequency (to fixed) till it is recalculated that it's time to reset it.
ernetas wrote:so it does not matter what governor we talk about - all of them, according to you, make CPU frequency "fixed".
Wait, what? How did you get to that conclusion? I don't see how it follows from what was previously said.
I just explained it in more detail above, if that wasn't enough previously.
ernetas wrote:Another thing: according to you, cpufreq fully controls CPU frequency. But Intel Turbo Boost is a BIOS technology and it is in BIOS, not in cpufreq code lines.
First, I reserved the possibility that turbo works even with the userspace governor. *But*, did you notice in your video that turbo didn't kick in until you set the freq to 2.31? When you set it to 2.30 turbo did *not* work, the CPU was constantly at 23x. So 2.30 means literally "2.30", while 2.31 seems to mean "as fast as possible, including turbo".
No, you did not:
Turbo works by temporarily increasing the frequency, depending on thermal conditions and what number of cores are in use and possibly other heuristics. How do you expect this to work if you've locked the CPU into a fixed frequency?
Here you clearly imply that "locking a CPU frequency" does not allow Turbo Boost to work.
I did. But how does your argument prove that "using userspace disables Turbo Boost"? I'm just now locking the frequency to 2.301 GHz.
ernetas wrote:I'm not working against CPU frequency throttling.
If you're not using ondemand, you are.
Who said that? Now, start even making assumptions that I am not even an Arch user and I will have no comments on this topic...
Anyways. ...How do you explain performance and userspace governors are still in the kernel? I, for instance, sometimes need to gain maximum performance from my laptop. Isn't that what userspace and performance governors are for?
ernetas wrote:I'm just saying you don't understand how cpufreq works at all. It does not fixate a CPU frequency. It only sets a nominal maximum frequency, while real frequency differs, so does power consumption.
There were indeed fluctuations with the userspace governor while the processor was not doing much. I found that interesting. Though now the question is, was the freq really fluctuating, or is it a quirk of i7z? I would be really, really interested in the answer to that.
A quirk?.. Show me it in the code then. Somehow I can see those "quirks" even on Windows with various utilities and not just on this laptop.
Still, the freq was at all times higher than with ondemand, screwing with the processor's power management.
This one simply just needed a separate quote... If I had used my CPU fully at maximum load for the whole time, how is that "screwing"?
ernetas wrote:My question why ffmpeg does worse when cpufreq is in userspace than in ondemand was left unanswered.
I already answered it, at the very beginning - turbo. Your video showed that with the userspace governor turbo did not kick in when you set a valid frequency. Only after you've set a value that seems to mean "as fast as possible" did it kick in. Though that in itself still does not explain the different encoding times.
You should replay the video till the very end. After setting frequency to 2.301 GHz and Turbo kicking in, I restarted ffmpeg for the test to be fair.
However I do have an explanation, and it's a very simple one: Like I said, one of the heuristics for turbo is thermal conditions. In the slower encode thermal conditions were worse, so turbo did not kick in as often.
Now you want to tell me that Turbo was switching on and off for all the time, every millisecond? It takes huge calculations to make that happen. That is a waste of CPU resources and it is not happening, because if you overclock your CPU for a few seconds, it does not burn just in those few seconds, because the temperature does not go up so fast.
Because there's one thing you need to understand: i7z refreshes every 1 second or maybe every 0.5 seconds. But freq changes happen, like I said above, in *millisecond* intervals.
Well, it does not. Also, it would be irrational to make frequency change calculations every millisecond interval, because it is simply just a waste of CPU resources.
Offline
I can see that you argue without any proof and just based on your own opinion... Way to go. Let me quote ArchLinux Wiki:
And the "proof" the wiki presents is... ? Also, I didn't say there is no difference. I said the difference is insignificant. And the power management benefits far outweigh this. Read this: http://mjg59.livejournal.com/88608.html
By saying that CPUs power management was not intended to under cpufreq I mean, that Intel did not gave support for the creation of this utility, which is now integrated in kernel.
I can't even parse this sentence.
Because power management is done via BIOS and not Windows OS. How come? You can use Windows Vista, which was released before Intel Turbo Boost and before you CPU, but it still runs perfectly and implements Intel Turbo Boost without any additional drivers.
Give me proof that Windows is not involved in power management. You won't find any, because it's silly. If you go into the Device Manager, you'll see drivers loaded, among other things for power management. Also, have you heard of service packs and "Patch Tuesdays"? They bring fixes, but they also bring updated drivers. So if Vista does not support turbo out-of-the-box, there is for sure a driver that adds the support.
So, dynamic scaling governors are still basically the same thing as userspace, but it's just changes the frequency every "few milliseconds"
So they are basically the same except they're not the same. <- That's exactly what you just said. Of course in the next post you'll deny this, but that *is* exactly what you just said.
So I assume this implies the same thing as "setting a frequency" and since, as you say, "setting a frequency is setting a frequency", so just as userspace sets a frequency till you manually change it, so does ondemand governor sets a frequency (to fixed) till it is recalculated that it's time to reset it.
My head hurts from all the spinning you're doing here. The big difference is that userspace *will not change the freq on it's own*, it has two settings - "specified fixed freq" and "maximum, including turbo", and it will not deviate from those. Ondemand will constantly change the freq *on it's own*, because that's it's job.
Here you clearly imply that "locking a CPU frequency" does not allow Turbo Boost to work.
And your video shows that to be 100% correct. When you set it to 2.30, it did not go beyond 2.30.
I'm just now locking the frequency to 2.301 GHz.
No, you're not. You're setting a mode that says "turbo allowed". The freq is *not* locked at 2.301, it's at whatever turbo determines it can be. Your video clearly shows that. You're arguing against your own video! I can't help but find this funny.
Anyways. ...How do you explain performance and userspace governors are still in the kernel?
The kernel is flexible. Very flexible. It allows for various things, in this case for various cpu governors. They are there to be used *if* one knows what they're doing.
I, for instance, sometimes need to gain maximum performance from my laptop. Isn't that what userspace and performance governors are for?
You'd think that, but no. I can only repeat: Using userspace will interfere with the CPU's power management, which affects the effectiveness of turbo. Now, if you had a processor without turbo, then using userspace could possibly give a tiny benefit. But your processor has turbo.
If I had used my CPU fully at maximum load for the whole time, how is that "screwing"?
But you don't have it at maximum load for the whole time. And your processor has turbo. That's a really bad argument, when you can only make a point by creating an improbable hypothetical scenario.
Now you want to tell me that Turbo was switching on and off for all the time, every millisecond?
YES! Every few milliseconds the processor state changes.
It takes huge calculations to make that happen. That is a waste of CPU resources and it is not happening
Yes, it is happening. That's the whole point of cpufreq. Ask Intel engineers. Ask kernel developers. The processor changes C-states (voltage) and P-states (frequency) every few milliseconds.
Well, it does not. Also, it would be irrational to make frequency change calculations every millisecond interval, because it is simply just a waste of CPU resources.
Oh, the irony. You started the post with: "I can see that you argue without any proof and just based on your own opinion... Way to go." <-- That is exactly what you're doing. *You* are the one arguing about things you don't understand.
Last edited by Gusar (2012-11-04 12:50:00)
Offline
ernetas wrote:I can see that you argue without any proof and just based on your own opinion... Way to go. Let me quote ArchLinux Wiki:
And the "proof" the wiki presents is... ? Also, I didn't say there is no difference. I said the difference is insignificant. And the power management benefits far outweigh this. Read this: http://mjg59.livejournal.com/88608.html
The Wiki is the proof. The whole point of that article is to explain how to use advanced CPU frequency throttling for performance benefits, not battery.
The article is only about power consumption efficiency and nothing about maximum performance.
ernetas wrote:By saying that CPUs power management was not intended to under cpufreq I mean, that Intel did not gave support for the creation of this utility, which is now integrated in kernel.
I can't even parse this sentence.
By saying "CPUs power management was not intended to be under cpufreq" I mean, that Intel did not gave support for the creation of this utility.
ernetas wrote:Because power management is done via BIOS and not Windows OS. How come? You can use Windows Vista, which was released before Intel Turbo Boost and before you CPU, but it still runs perfectly and implements Intel Turbo Boost without any additional drivers.
Give me proof that Windows is not involved in power management. You won't find any, because it's silly. If you go into the Device Manager, you'll see drivers loaded, among other things for power management. Also, have you heard of service packs and "Patch Tuesdays"? They bring fixes, but they also bring updated drivers. So if Vista does not support turbo out-of-the-box, there is for sure a driver that adds the support.
Without updates it still would probably work.
ernetas wrote:So, dynamic scaling governors are still basically the same thing as userspace, but it's just changes the frequency every "few milliseconds"
So they are basically the same except they're not the same. <- That's exactly what you just said. Of course in the next post you'll deny this, but that *is* exactly what you just said.
Yes, that's exactly what I said. I said "basically" and that does not mean "completely". The difference is in the frequency of CPU throttling.
ernetas wrote:So I assume this implies the same thing as "setting a frequency" and since, as you say, "setting a frequency is setting a frequency", so just as userspace sets a frequency till you manually change it, so does ondemand governor sets a frequency (to fixed) till it is recalculated that it's time to reset it.
My head hurts from all the spinning you're doing here. The big difference is that userspace *will not change the freq on it's own*, it has two settings - "specified fixed freq" and "maximum, including turbo", and it will not deviate from those. Ondemand will constantly change the freq *on it's own*, because that's it's job.
Yes. Did I say it in any significantly different way that you had to repeat it?
Let me quote your words again:
ernetas wrote:It is exactly the same as userspace governor - ondemand governor ALSO fixes a frequency, but it "refixes" it when needed.
That makes no sense.
ernetas wrote:I'm just now locking the frequency to 2.301 GHz.
No, you're not. You're setting a mode that says "turbo allowed". The freq is *not* locked at 2.301, it's at whatever turbo determines it can be. Your video clearly shows that. You're arguing against your own video! I can't help but find this funny.
It's not funny, but a waste of time. Now you say that I DID NOT lock the frequency at 2.301, even though before you said it vice versa:
ernetas wrote:Are you trying to tell me that without CPU frequency scaling in kernel, you can't have Intel Turbo Boost working?
Why does this surprise you?
ernetas wrote:Anyways. ...How do you explain performance and userspace governors are still in the kernel?
The kernel is flexible. Very flexible. It allows for various things, in this case for various cpu governors. They are there to be used *if* one knows what they're doing.
So, according to you, ArchLinux Wiki is bullshit. Please, fix it, then.
ernetas wrote:If I had used my CPU fully at maximum load for the whole time, how is that "screwing"?
But you don't have it at maximum load for the whole time. And your processor has turbo. That's a really bad argument, when you can only make a point by creating an improbable hypothetical scenario.
Hypothetical? Any bigger torrent tracker has MySQL servers running on load higher that the number of cores. Any bigger cheap hosting service has servers running on load higher than the number of cores. At last, I can just write a scientific simulation program in C++ and make my CPU loaded at 100% for all time. BOINC also does that.
Overall:
Before this argument, you said that I cannot have Turbo on with userspace governor and that's why ffmpeg is performing worse while using this governor. But now you know that I can use userspace and Turbo Boost. End of argument. I don't have time to read through this bullshit of word play between us.
Last edited by ernetas (2012-11-04 13:26:25)
Offline