Re: 2.6.2: P4 ClockMod speed

Re: 2.6.2: P4 ClockMod speed

[Dominik Brodowski]

[-- Attachment #1.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 #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Cpufreq mailing list
Cpufreq@www.linux.org.uk
http://www.linux.org.uk/mailman/listinfo/cpufreq

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.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 #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Cpufreq mailing list
Cpufreq@www.linux.org.uk
http://www.linux.org.uk/mailman/listinfo/cpufreq

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.

Re: 2.6.2: P4 ClockMod speed

[Dominik Brodowski]

[-- Attachment #1.1: Type: text/plain, Size: 1862 bytes --]

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

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

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

On Wed, Feb 25, 2004 at 06:43:27PM +0100, Pavel Machek wrote:
> 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

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

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Cpufreq mailing list
Cpufreq@www.linux.org.uk
http://www.linux.org.uk/mailman/listinfo/cpufreq

Re: 2.6.2: P4 ClockMod speed

[Pavel Machek]

Hi!

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

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: 2.6.2: P4 ClockMod speed

[Dominik Brodowski]

[-- Attachment #1.1: Type: text/plain, Size: 503 bytes --]

On Sun, Mar 14, 2004 at 10:23:04PM +0100, Pavel Machek wrote:
> Hi!
> 
> > > 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?

cpu_khz may be zero if the PIT is used as primary time source.

	Dominik

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

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Cpufreq mailing list
Cpufreq@www.linux.org.uk
http://www.linux.org.uk/mailman/listinfo/cpufreq

Re: 2.6.2: P4 ClockMod speed

[Pavel Machek]

> On Sun, Mar 14, 2004 at 10:23:04PM +0100, Pavel Machek wrote:
> > Hi!
> > 
> > > > 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?
> 
> cpu_khz may be zero if the PIT is used as primary time source.

But that's a bug to be fixed, right?
								Pavel
-- 
Horseback riding is like software...
...vgf orggre jura vgf serr.

Re: 2.6.2: P4 ClockMod speed

[Dominik Brodowski]

[-- Attachment #1.1: Type: text/plain, Size: 883 bytes --]

On Mon, Mar 15, 2004 at 01:44:06PM +0100, Pavel Machek wrote:
> > On Sun, Mar 14, 2004 at 10:23:04PM +0100, Pavel Machek wrote:
> > > Hi!
> > > 
> > > > > 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?
> > 
> > cpu_khz may 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

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

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Cpufreq mailing list
Cpufreq@www.linux.org.uk
http://www.linux.org.uk/mailman/listinfo/cpufreq

Re: 2.6.2: P4 ClockMod speed

[Pavel Machek]

On Po 15-03-04 14:59:27, Dominik Brodowski wrote:
> On Mon, Mar 15, 2004 at 01:44:06PM +0100, Pavel Machek wrote:
> > > On Sun, Mar 14, 2004 at 10:23:04PM +0100, Pavel Machek wrote:
> > > > Hi!
> > > > 
> > > > > > 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?
> > > 
> > > cpu_khz may 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...

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