2.6.2: P4 ClockMod speed

2.6.2: P4 ClockMod speed

[dual_bereta_r0x]

Hello all.

I have a P4 2.4 running @ 3.12GHz. 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.

Is there anything to do so i can reuse old fashioned way?

Please c/c me as i'm not on list.

TIA.

hquest@phoenix:/proc$ more cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Pentium(R) 4 CPU 2.40GHz
stepping        : 9
cpu MHz         : 3124.376
cache size      : 512 KB
physical id     : 0
siblings        : 2
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid
bogomips        : 6176.76

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Pentium(R) 4 CPU 2.40GHz
stepping        : 9
cpu MHz         : 3124.376
cache size      : 512 KB
physical id     : 0
siblings        : 2
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid
bogomips        : 6242.30

hquest@phoenix:/proc$ speedfreq
Current policy is performance
hquest@phoenix:/proc$ speedfreq -c
CPU speed: min 300MHz, max 2400MHZ, current 2400MHz; 0.00% idle
hquest@phoenix:/proc$ cd /sys/devices/system/cpu/cpu0/cpufreq
hquest@phoenix:/sys/devices/system/cpu/cpu0/cpufreq$ more *
::::::::::::::
cpuinfo_max_freq
::::::::::::::
2400000
::::::::::::::
cpuinfo_min_freq
::::::::::::::
300000
::::::::::::::
scaling_available_frequencies
::::::::::::::
300000 600000 900000 1200000 1500000 1800000 2100000 2400000
::::::::::::::
scaling_available_governors
::::::::::::::
userspace performance
::::::::::::::
scaling_driver
::::::::::::::
p4-clockmod
::::::::::::::
scaling_governor
::::::::::::::
performance
::::::::::::::
scaling_max_freq
::::::::::::::
2400000
::::::::::::::
scaling_min_freq
::::::::::::::
300000
hquest@phoenix:/sys/devices/system/cpu/cpu0/cpufreq$ _

-- 
dual_bereta_r0x -- Alexandre Hautequest
ArenaNetwork Lan House & Cyber -- www.arenanetwork.com.br

Re: 2.6.2: P4 ClockMod speed

[Dominik Brodowski]

[-- Attachment #1: Type: text/plain, Size: 1049 bytes --]

Hi,

> I have a P4 2.4 running @ 3.12GHz.

So you overclock your CPU but then throttle it down... strange, but well...

> 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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.6.2: P4 ClockMod speed

[dual_bereta_r0x]

Dominik Brodowski wrote:
> Hi,
> 
> 
>>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.

>>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... [*]

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?

> 	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.

Indeed. I'll showing in LCD a lower speed than the running.

-- 
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.

Re: 2.6.2: P4 ClockMod speed

[Bruno Ducrot]

On Mon, Feb 16, 2004 at 09:48:25PM +0000, dual_bereta_r0x wrote:
> Dominik Brodowski wrote:
> >Hi,
> >
> >
> >>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.

/proc/cpuinfo is lying.

Use something like bogomips, and look if that's actually make a difference.

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: 2.6.2: P4 ClockMod speed

[Dominik Brodowski]

[-- Attachment #1: Type: text/plain, Size: 1693 bytes --]

On Mon, Feb 16, 2004 at 09:48:25PM +0000, dual_bereta_r0x wrote:
> >>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... [*]
> 
> 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.

> >[*] 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.
> 
> 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...

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.6.2: P4 ClockMod speed

[Pavel Machek]

Hi!

> 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... [*]
... 
> [*] 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.

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
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: 2.6.2: P4 ClockMod speed

[dual_bereta_r0x]

Dominik Brodowski wrote:

> 
> 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."

-- 
dual_bereta_r0x -- Alexandre Hautequest
ArenaNetwork Lan House & Cyber -- www.arenanetwork.com.br

Re: 2.6.2: P4 ClockMod speed

[Bruno Ducrot]

On Thu, Feb 26, 2004 at 01:28:51AM +0000, dual_bereta_r0x wrote:
> Dominik Brodowski wrote:
> 
> >
> >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."
> 

The problem is that you can not trust /proc/cpuinfo when you compile
with SMP.  Go UP and that should be ok.

Cheers,

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.