public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* PM-Timer clock source is slow. Try something else: How slow? What other source(s)?
@ 2006-11-30  0:56 Linda Walsh
  2006-11-30  1:32 ` john stultz
  0 siblings, 1 reply; 5+ messages in thread
From: Linda Walsh @ 2006-11-30  0:56 UTC (permalink / raw)
  To: LKML

I recently noticed this message in my bootup that I don't remember
from before:

PCI: Probing PCI hardware (bus 00)
* Found PM-Timer Bug on the chipset. Due to workarounds for a bug,
* this clock source is slow. Consider trying other clock sources
------
    How would this affect my clock?  It says to try another
clock source, what type of clock source would it be suggesting I
use? Another chip already in the computer? It is an Intel 440BX
chipset; on an Dell motherboard. Would that be likely to have
another chip source that is compensating?

I don't notice a significant clock slowdown, but I'm running NTP,
so that could be masking the problem.

NTP values appear: to indicated smallish values for clock variance, but I'm
not sure what is "standardly" considered good or bad, so I don't have 
anything
to compare to.

Relevant ntp time vars show:
leap indicator:       00
stratum:              2
precision:            -20
root distance:        0.01445 s
root dispersion:      0.01372 s
jitter:               0.002335 s
stability:            58.565 ppm
broadcastdelay:       0.003998 s
---
  maximum error 130449 us, estimated error 1923 us
ntp_adjtime() returns code 0 (OK)
  offset 1384.000 us, frequency 74.584 ppm, interval 1 s,
  maximum error 130449 us, estimated error 1923 us,
  status 0x1 (PLL),
  time constant 3, precision 1.000 us, tolerance 512 ppm,

--------
    It seems the estimated error is .1923ms, with a precision
of 1us.
    Is the clock "slowness" indicated by the
"offset 1384us, 74.584ppm @ interval 1s?  I.e. do I read that
as the clock is off by 74.584ppm/s, or ~75us/sec, or do I look
at the offset of 1384us/sec, meaning off by .1384ms/s (wouldn't
that be 1384ppm?).  Seems the stability is fairly low, on the
order of 58.656ppm, or about .058ms/s?

    Seems like fewer questions are being answered these days than
in days past.  Is this because of a change in the list focus (maybe
all the patches being submitted),
- or change in list membership, i.e. fewer people up-to-speed on
older HW,
- or increased specialization in specific kernel areas with fewer
having knowledge outside their specific domain, or
what?

    It it is an ugly tradeoff between development time spent
and answering questions that might increase understanding of
people on the list (or maybe it's such common knowledge that
no one bothers to answer...  dunno...

but thanks for any ideas...especially on the original issue.

Linda W.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: PM-Timer clock source is slow. Try something else: How slow? What other source(s)?
  2006-11-30  0:56 PM-Timer clock source is slow. Try something else: How slow? What other source(s)? Linda Walsh
@ 2006-11-30  1:32 ` john stultz
  2006-11-30  7:00   ` Srinivasa Ds
  0 siblings, 1 reply; 5+ messages in thread
From: john stultz @ 2006-11-30  1:32 UTC (permalink / raw)
  To: Linda Walsh; +Cc: LKML

On Wed, 2006-11-29 at 16:56 -0800, Linda Walsh wrote:
> I recently noticed this message in my bootup that I don't remember
> from before:
> 
> PCI: Probing PCI hardware (bus 00)
> * Found PM-Timer Bug on the chipset. Due to workarounds for a bug,
> * this clock source is slow. Consider trying other clock sources

This basically means that your chipset has a bug which requires the ACPI
PM timer to be read three times in order to get a valid reading.

This will cause gettimeofday/clock_gettime to take longer to execute,
which is what is meant by "slow" (rather then the counter's frequency
being incorrect).

>     How would this affect my clock?  It says to try another
> clock source, what type of clock source would it be suggesting I
> use? Another chip already in the computer? It is an Intel 440BX
> chipset; on an Dell motherboard. Would that be likely to have
> another chip source that is compensating?
> 
> I don't notice a significant clock slowdown, but I'm running NTP,
> so that could be masking the problem.

Unless you're running performance critical programs that utilize
gettimeofday/clock_gettime, you probably won't notice anything. Time
should still function properly.  If you are having performance issues,
you can try using a different clocksource (the TSC is probably safe, but
not necessarily).

thanks
-john




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: PM-Timer clock source is slow. Try something else: How slow? What other source(s)?
  2006-11-30  1:32 ` john stultz
@ 2006-11-30  7:00   ` Srinivasa Ds
  2006-11-30 19:39     ` Linda Walsh
  0 siblings, 1 reply; 5+ messages in thread
From: Srinivasa Ds @ 2006-11-30  7:00 UTC (permalink / raw)
  To: john stultz; +Cc: Linda Walsh, LKML

john stultz wrote:
> On Wed, 2006-11-29 at 16:56 -0800, Linda Walsh wrote:
>   
>> I recently noticed this message in my bootup that I don't remember
>> from before:
>>
>> PCI: Probing PCI hardware (bus 00)
>> * Found PM-Timer Bug on the chipset. Due to workarounds for a bug,
>> * this clock source is slow. Consider trying other clock sources
>>     
>
> This basically means that your chipset has a bug which requires the ACPI
> PM timer to be read three times in order to get a valid reading.
>
> This will cause gettimeofday/clock_gettime to take longer to execute,
> which is what is meant by "slow" (rather then the counter's frequency
> being incorrect).
>
>   
>>     How would this affect my clock?  It says to try another
>> clock source, what type of clock source would it be suggesting I
>> use? Another chip already in the computer? 
Yes.
>> It is an Intel 440BX
>> chipset; on an Dell motherboard. Would that be likely to have
>> another chip source that is compensating?
>>     
You can change the clock source using "clock=" kernel parameter. Please 
refer to  Documentation/kernel-parameters.txt file of kernel source.
>> I don't notice a significant clock slowdown, but I'm running NTP,
>> so that could be masking the problem.
>>     
>
> Unless you're running performance critical programs that utilize
> gettimeofday/clock_gettime, you probably won't notice anything. Time
> should still function properly.  If you are having performance issues,
> you can try using a different clocksource (the TSC is probably safe, but
> not necessarily).
>
> thanks
> -john
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>   
Thanks
 Srinivasa DS

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: PM-Timer clock source is slow. Try something else: How slow? What other source(s)?
  2006-11-30  7:00   ` Srinivasa Ds
@ 2006-11-30 19:39     ` Linda Walsh
  2006-12-01 10:40       ` Dominik Brodowski
  0 siblings, 1 reply; 5+ messages in thread
From: Linda Walsh @ 2006-11-30 19:39 UTC (permalink / raw)
  To: Srinivasa Ds; +Cc: john stultz, LKML

Srinivasa Ds wrote: 
> You can change the clock source using "clock=" kernel parameter. 
> Please refer to  Documentation/kernel-parameters.txt file of kernel 
> source.
---
    Uh, yeah...you mean the "clock=" parameter that is
  "deprecated"    ?   :-)

    *cough*
    *sigh*

thanks,
Linda



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: PM-Timer clock source is slow. Try something else: How slow? What other source(s)?
  2006-11-30 19:39     ` Linda Walsh
@ 2006-12-01 10:40       ` Dominik Brodowski
  0 siblings, 0 replies; 5+ messages in thread
From: Dominik Brodowski @ 2006-12-01 10:40 UTC (permalink / raw)
  To: Linda Walsh; +Cc: Srinivasa Ds, john stultz, LKML

On Thu, Nov 30, 2006 at 11:39:36AM -0800, Linda Walsh wrote:
> Srinivasa Ds wrote: 
> >You can change the clock source using "clock=" kernel parameter. 
> >Please refer to  Documentation/kernel-parameters.txt file of kernel 
> >source.
> ---
>    Uh, yeah...you mean the "clock=" parameter that is
>  "deprecated"    ?   :-)
> 
>    *cough*
>    *sigh*

"clocksource=" is the replacement.

	Dominik

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2006-12-01 10:40 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-11-30  0:56 PM-Timer clock source is slow. Try something else: How slow? What other source(s)? Linda Walsh
2006-11-30  1:32 ` john stultz
2006-11-30  7:00   ` Srinivasa Ds
2006-11-30 19:39     ` Linda Walsh
2006-12-01 10:40       ` Dominik Brodowski

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox