2.6.2: P4 ClockMod speed
Hi,
Quoted 1 line
I have a P4 2.4 running @ 3.12GHz.
So you overclock your CPU but then throttle it down... strange, but well...
Quoted 3 lines
In 2.6.0, i could change it frequency
via speedfreqd(8) up to its actual speed. Since 2.6.1, its max speed is locked on cpu *real* speed.
It's just a change of appearance -- the cpufreq driver uses the theoretical speed of the CPU for its calculations; the actual CPU speed isn't affected. You can verify this by looking at /proc/cpuinfo which still tells 3124.376 MHz.
By doing so it becomes easier to enter different frequencies e.g. into /sys/devices/system/cpu/cpufreq/scaling_setspeed -- on my desktop, typing in 1200000 is easier than 12121224... [*]
Dominik
[*] The _actual_ CPU speed should be used on all cpufreq drivers where this specific CPU frequency has implications to external components, e.g. LCD, memory or pcmcia devices. Where only the _frequency ratio_ is of importance [for loops_per_jiffy and friends] such "rounding" is acceptable, as long as the ratio is constant.
Quoted 7 lines · Dominik Brodowski
Hi,
Quoted 1 line
I have a P4 2.4 running @ 3.12GHz.
So you overclock your CPU but then throttle it down... strange, but well...
Actually it isn't throttled down, only sysfs is showing it with low speed. It *is* running @ 3.12 (or /proc/cpuinfo and boot messages are lying to me) when in full power.
Quoted 11 lines
Quoted 1 line
In 2.6.0, i could change it frequency via speedfreqd(8) up to its actual speed. Since 2.6.1, its max speed is locked on cpu *real* speed.
It's just a change of appearance -- the cpufreq driver uses the theoretical speed of the CPU for its calculations; the actual CPU speed isn't affected. You can verify this by looking at
/proc/cpuinfowhich still tells 3124.376 MHz.By doing so it becomes easier to enter different frequencies e.g. into
/sys/devices/system/cpu/cpufreq/scaling_setspeed-- on my desktop, typing in 1200000 is easier than 12121224... [*]
Sure but if i want to downgrade it, for example, by night, to a lower speed, and then next day return it to full power? Will I stuck at 2.4GHz?
Quoted 7 lines
Dominik
[*] The _actual_ CPU speed should be used on all cpufreq drivers where this specific CPU frequency has implications to external components, e.g. LCD, memory or pcmcia devices. Where only the
_frequencyratio_is of importance [forloops_per_jiffyand friends] such "rounding" is acceptable, as long as the ratio is constant.
Indeed. I'll showing in LCD a lower speed than the running.
Signature · 11 lines
dual_bereta_r0x -- Alexandre Hautequest ArenaNetwork Lan House & Cyber -- www.arenanetwork.com.br Três anéis para os Reis Élficos sob este céu, Sete para os Senhores-Anões em seus rochosos corredores, Nove para Homens Mortais, fadados ao eternos sono, Um para o Senhor do Escuro em seu escuro trono Na Terra de Mordor onde as Sombras se deitam. Um Anel para a todos governar, Um Anel para encontrá-los, Um Anel para a todos trazer e na escuridão aprisioná-los Na Terra de Mordor onde as Sombras se deitam.
Quoted 4 lines · On Mon, Feb 16, 2004 at 09:48:25PM +0000, dual_bereta_r0x wrote:
Quoted 3 lines · Dominik Brodowski
Hi,
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
I have a P4 2.4 running @ 3.12GHz.
So you overclock your CPU but then throttle it down... strange, but well...
Actually it isn't throttled down, only sysfs is showing it with low speed. It *is* running @ 3.12 (or
/proc/cpuinfoand boot messages are lying to me) when in full power.
/proc/cpuinfo is lying.
Use something like bogomips, and look if that's actually make a difference.
Signature · 4 lines
Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Quoted 8 lines · On Mon, Feb 16, 2004 at 09:48:25PM +0000, dual_bereta_r0x wrote:
Quoted 8 lines
Quoted 1 line
locked on cpu *real* speed.
It's just a change of appearance -- the cpufreq driver uses the theoretical speed of the CPU for its calculations; the actual CPU speed isn't affected. You can verify this by looking at
/proc/cpuinfowhich still tells 3124.376 MHz.
Quoted 7 lines
Quoted 4 lines
By doing so it becomes easier to enter different frequencies e.g. into
/sys/devices/system/cpu/cpufreq/scaling_setspeed-- on my desktop, typing in
1200000 is easier than 12121224... [*]Sure but if i want to downgrade it, for example, by night, to a lower speed, and then next day return it to full power? Will I stuck at 2.4GHz?
No, it will run at the same speed as before -- the ratio between actual cpu_khz and cpufreq/scaling_setspeed will always be the same.
Quoted 7 lines
Quoted 5 lines
[*] The _actual_ CPU speed should be used on all cpufreq drivers where this specific CPU frequency has implications to external components, e.g. LCD, memory or pcmcia devices. Where only the
_frequencyratio_is of importance [forloops_per_jiffyand friends] such "rounding" is acceptable, as long as the ratio is constant.Indeed. I'll showing in LCD a lower speed than the running.
That's not the point: some hardware (e.g. ARM) needs different memory settings and different settings of the LCD controller for different CPU frequencies, as the Front Side Bus of the CPU is closely related to the CPU frequency. On x86, all cpufreq techniques I've
seen so far do not modify the FSB [*], so memory settings etc. do not need to be modified.
Dominik
[*] or scaling the FSB didn't work...
_______________________________________________
Cpufreq mailing list
[email protected]
http://www.linux.org.uk/mailman/listinfo/cpufreq
Quoted 9 lines · Dominik Brodowski
That's not the point: some hardware (e.g. ARM) needs different memory
settings and different settings of the LCD controller for different CPU frequencies, as the Front Side Bus of the CPU is closely related to the CPU frequency. On x86, all cpufreq techniques I've seen so far do not modify the FSB [*], so memory settings etc. do not need
to be modified.Dominik
[*] or scaling the FSB didn't work...
In x86 world, this info is wrong. The *multiplier* is locked inside processor (Intel P4) or by some "dips" on cpu core (AMD Athlon XP) -- unless you have such as "enginering samples", with didn't have this lock --, but front-side-bus is changeable via MoBo BIOS. Also, if you just add 0.5v in your CPU you can made it running faster than designed. The same applies to memory. That's why we bought DDR533 mems to run in DDR400 hardwares. We increase FSB and our mems could run with this new FSB.
Again, showing *max* from manufacturer instead of *actual* speed is wrong. Even if the machine has or not capabilities to run with more/less power than it has designed for, is not up to the OS decide it. The OS should run or not, but the user has chosen this path; it must only tell him what's *really* happening. "Your actual clock differs from manufacturer. Its *your* fault if any component fail or malfunctions/bugs arrives because of this."
Signature · 2 lines
dual_bereta_r0x -- Alexandre Hautequest ArenaNetwork Lan House & Cyber -- www.arenanetwork.com.br
Quoted 22 lines · On Thu, Feb 26, 2004 at 01:28:51AM +0000, dual_bereta_r0x wrote:
Quoted 11 lines · Dominik Brodowski
That's not the point: some hardware (e.g. ARM) needs different memory settings and different settings of the LCD controller for different CPU frequencies, as the Front Side Bus of the CPU is closely related to the CPU frequency. On x86, all cpufreq techniques I've
seen so far do not modify the FSB [*], so memory settings etc. do not need to be modified.Dominik
[*] or scaling the FSB didn't work...
In x86 world, this info is wrong. The *multiplier* is locked inside processor (Intel P4) or by some "dips" on cpu core (AMD Athlon XP) -- unless you have such as "enginering samples", with didn't have this lock --, but front-side-bus is changeable via MoBo BIOS. Also, if you just add 0.5v in your CPU you can made it running faster than designed. The same applies to memory. That's why we bought DDR533 mems to run in DDR400 hardwares. We increase FSB and our mems could run with this new FSB.
Quoted 8 lines
Again, showing *max* from manufacturer instead of *actual* speed is wrong. Even if the machine has or not capabilities to run with more/less power than it has designed for, is not up to the OS decide it. The OS should run or not, but the user has chosen this path; it must only tell him what's *really* happening. "Your actual clock differs from manufacturer. Its *your* fault if any component fail or malfunctions/bugs arrives because of this."
The problem is that you can not trust /proc/cpuinfo when you compile with SMP. Go UP and that should be ok.
Cheers,
Signature · 4 lines
Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Hi!
Quoted 3 lines
By doing so it becomes easier to enter different frequencies e.g. into
/sys/devices/system/cpu/cpufreq/scaling_setspeed-- on my desktop, typing in 1200000 is easier than 12121224... [*]
...
Quoted 5 lines
[*] The _actual_ CPU speed should be used on all cpufreq drivers where this specific CPU frequency has implications to external components, e.g. LCD, memory or pcmcia devices. Where only the
_frequencyratio_is of importance [forloops_per_jiffyand friends] such "rounding" is acceptable, as long as the ratio is constant.
Hey, that's ugly. Values should be real.
If you have troubles typing real frequency, you can either use /proc/cpufreq and specify values in percent, or modify scaling_setspeed to go for nearest lower frequency, or create bash scripts "hi_speed" and "low_speed"; but please don't break interface....
Pavel
Signature · 2 lines
When do you have a heart between your knees? [Johanka's followup: and *two* hearts?]
Quoted 4 lines · On Thu, Feb 26, 2004 at 01:28:51AM +0000, dual_bereta_r0x wrote:
In x86 world, this info is wrong. The *multiplier* is locked inside processor (Intel P4) or by some "dips" on cpu core (AMD Athlon XP) -- unless you have such as "enginering samples", with didn't have this lock --, but front-side-bus is changeable via MoBo BIOS.
Depends...
Quoted 9 lines
Also, if you just
add 0.5v in your CPU you can made it running faster than designed. The same applies to memory. That's why we bought DDR533 mems to run in DDR400 hardwares. We increase FSB and our mems could run with this new FSB.Again, showing *max* from manufacturer instead of *actual* speed is wrong. Even if the machine has or not capabilities to run with more/less power than it has designed for, is not up to the OS decide it. The OS should run or not,
The OS runs, the p4-clockmod driver runs, so that is besides the point here.
Quoted 4 lines
but the user has chosen this path; it must only tell him what's *really* happening. "Your actual clock differs from manufacturer. Its *your* fault if any component fail or malfunctions/bugs arrives because of this."
The problem is that cpu_khz is partly unreliable, partly not available, so there's no reliable way to detect _actual_ CPU speed for the p4-clockmod driver. Also, there's the need to warn users about the lack of usefullness of the p4-clockmod driver in the very most cases, and to avoid code duplication the speedstep_detect function is used. Then we get the _reliable_ detection of "specification speed", which is in most cases equal to the "actual speed", almost for free.
Quoted 1 line · Pavel Machek
Hey, that's ugly. Values should be real.
Indeed. But if they're not known (and cpu_khz _is_ unreliable), what should be done?
Dominik
_______________________________________________
Cpufreq mailing list
[email protected]
http://www.linux.org.uk/mailman/listinfo/cpufreq
Hi!
Quoted 4 lines
Quoted 1 line
Hey, that's ugly. Values should be real.
Indeed. But if they're not known (and
cpu_khz_is_ unreliable), what should be done?
Is it possible to measure cpu_khz with arbitrary precision if we make measurement slower? I think so; if cpu_khz is too unreliable, perhaps we can make measurement slower but more precise?
Pavel
Signature · 2 lines
When do you have a heart between your knees? [Johanka's followup: and *two* hearts?]
Quoted 10 lines · Pavel Machek
Hi!
Quoted 4 lines
Quoted 1 line
Hey, that's ugly. Values should be real.
Indeed. But if they're not known (and
cpu_khz_is_ unreliable), what should be done?Is it possible to measure
cpu_khzwith arbitrary precision if we make measurement slower? I think so; ifcpu_khzis too unreliable, perhaps we can make measurement slower but more precise?
cpu_khz may be zero if the PIT is used as primary time source.
Dominik
_______________________________________________
Cpufreq mailing list
[email protected]
http://www.linux.org.uk/mailman/listinfo/cpufreq
Quoted 5 lines · Pavel Machek
Quoted 4 lines
Hi!
Quoted 2 lines
Quoted 1 line
Hey, that's ugly. Values should be real.
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
Indeed. But if they're not known (and
cpu_khz_is_ unreliable), what should be done?Is it possible to measure
cpu_khzwith arbitrary precision if we make measurement slower? I think so; ifcpu_khzis too unreliable, perhaps we can make measurement slower but more precise?
cpu_khzmay be zero if the PIT is used as primary time source.
But that's a bug to be fixed, right?
Pavel
Signature · 2 lines
Horseback riding is like software... ...vgf orggre jura vgf serr.
Quoted 8 lines · Pavel Machek
Quoted 8 lines · Pavel Machek
Quoted 7 lines
Hi!
Quoted 4 lines
Quoted 1 line
Hey, that's ugly. Values should be real.
Indeed. But if they're not known (and
cpu_khz_is_ unreliable), what should be done?
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
Is it possible to measure
cpu_khzwith arbitrary precision if we make measurement slower? I think so; ifcpu_khzis too unreliable, perhaps we can make measurement slower but more precise?
cpu_khzmay be zero if the PIT is used as primary time source.But that's a bug to be fixed, right?
Not necessarily: if the PIT is used and the TSC is disabled [there are some such systems, even modern ones...], you can't use the current cpu_khz detection routine. And please don't try to deduce it from BogoMIPS...
Dominik
_______________________________________________
Cpufreq mailing list
[email protected]
http://www.linux.org.uk/mailman/listinfo/cpufreq
Quoted 13 lines · Dominik Brodowski
Quoted 12 lines · Pavel Machek
Quoted 12 lines · Pavel Machek
Quoted 10 lines
Hi!
Quoted 4 lines
Quoted 1 line
Hey, that's ugly. Values should be real.
Indeed. But if they're not known (and
cpu_khz_is_ unreliable), what should be done?Is it possible to measure
cpu_khzwith arbitrary precision if we make measurement slower? I think so; ifcpu_khzis too unreliable, perhaps we can make measurement slower but more precise?
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
cpu_khzmay be zero if the PIT is used as primary time source.But that's a bug to be fixed, right?
Not necessarily: if the PIT is used and the TSC is disabled [there are some such systems, even modern ones...], you can't use the current
cpu_khzdetection routine. And please don't try to deduce it from BogoMIPS...
Ahha, I see. notsc. But, even if TSC is disabled for normal timekeeping, it should be okay to use it to determine cpu_khz.
I believe that every CPU supported by cpufreq has TSC working good-enough to measuring cpu_khz. While measuring cpu_khz, you are not issuing halt, not changing cpu frequency, and you do not have problems with unsynchronizes TSCs.
Pavel
Signature · 2 lines
When do you have a heart between your knees? [Johanka's followup: and *two* hearts?]