cpuinfo wrong report ?

[David Bandel]

On 1/30/07, Vu Pham <vu at sivell.com> wrote:
> On Tue, 2007-01-30 at 10:25 -0500, David Bandel wrote:
> > On 1/30/07, Vu Pham <vu at sivell.com> wrote:
> > > I am playing some settings of the new motherboard.
> > >
> > > When I change the clock multiplier, /proc/cpuinfo does show the change
> > > of CPU Mhz accordingly and shows the same value that the motherboard
> > > shows ( 3.2Ghz )
> > >
> > > But when I change ( increase ) the host clock, the cpuinfo shows the cpu
> > > mhz dropped dramtically : 600 Mhz ( less than 1Ghz ) instead of 3.54
> > > Ghz.
> > >
> > > In both cases, the bpgomips values increase as expected.
> > >
> > > Is it a bug ?
> >
> > Is it a bug that apples and oranges taste different?
>
> David, I thought when the physical CPU speed increases then the tool
> will show that increase, not decrease. In this case, it does show the
> increase when the CPU speed  increases by the multiplier, and decrease
> when the CPU speed increases by the host clock. In both cases, the CPU
> speed does increase, why it shows different results ? I am sure that I
> am missing something here, so any explanation is really appreciated.

bogomips is running its own code to produce its result.  cpuinfo, if
I'm not mistaken, is reading something from the hardware.  How,
exactly, the hardware is interpreting what it sees is anybody's guess.
 In this case it looks like for some reason it's dividing the real
speed by 6.  At any rate, since the two results come from two
different places and are arrived at by different means, it's hard to
compare them without knowing exactly how they are related.

>
>
> > > The second question: this Intel CPU will run at lower clock  ( 1.6 Ghz )
> > > when there is little load and moves to a higher (3.2Ghz) when there is
> > > more load. Is there any kernel settings that can keep the cpu always at
> > > high frequency clock ?
> >
> > Why, when the CPU is idle (over 80% of the time) would you want to run
> > it hotter?
>
> No, I do not want it to run hotter. As you see, I use cpuinfo to check
> the  physical cpu speed. When the cpu is not in the high-load mode,
> cpuinfo shows me the lower speed, and I do not know if it is the speed
> for the low load or high load.
>
> > Besides, do you know that Linux (but not all OS's) sends the the Halt
> > command to the CPU?  Perhaps you'd like to kill that too?
> >
> > Stepping the processor down and halting it while it's not working
> > extends the CPU life, reduces power consumption, but does not hurt
> > performance.
> > Why do you:
> > a.  insist on overclocking rather than just buying a faster board and processor?
> > b.  want to defeat mechanisms that don't hurt performance?
>
> In general I do not need to overclock my systems and when I need
> something faster, I often try some faster board and processor, if I ( or
> my company ) can afford.
>
> In this particular case, I have to finish my project in a pretty short
> time, and the tool I am using runs pretty slow in debugging mode. It
> seems the system bottleneck is the cpu and I already got the fatest cpu
> ( X6800) for my workstation ( I may be wrong, as I often am ). Just hope
> the CPU does not die before I finish the project :).
>
> In fact, Google shows many people overclock it up to 4 Ghz and I only
> try to 3.5Ghz. Perhaps I am not so mean as them. :)

So because they're probably going to burn out their CPU in a year or
so, you want to as well.  Point is, the chip has an operating
envelope.  When you exceed that envelope, you stress the chip and
shorten its life.  Perhaps not enough to worry about, but an
overclocked chip is not covered by warranty and could cause programs
to segfault or otherwise act strangely.  I'm not saying don't, I'm
saying understand what problems you might face and ask yourself is it
worth the small gain in performance.

You know, your bottleneck might be elsewhere (bus, IO, etc.)

>
>
> > If you want to destroy your CPU, a hammer will do it faster and you
> > won't have to worry about errors, random lockups that have no apparent
> > cause, etc., as the system dies a tortured death.
>
> I did, not by hammer, but by sweat. About 20 years ago I was working on
> an Apple II installing my ADC board, my sweat ( no AC where I
> practiced ) dropped onto the pins of the chip 6502, IIRC, and I had to
> spend almost my salary to buy that chip back.

Always best to ensure a board is dry before applying power.
Experience is a tough teacher.

Ciao,

David A. Bandel
-- 
Focus on the dream, not the competition.
            - Nemesis Air Racing Team motto