[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: TSC vs. HPET timecounter priority
On 13 Aug, 2012, at 17:05 , Erik Fair wrote:
> On Aug 13, 2012, at 02:10, Dennis Ferguson wrote:
>> On 13 Aug, 2012, at 07:34 , YAMAMOTO Takashi wrote:
>>>> What about the following patch?
>>>> tc_quality for hpet is set to 2000 so it would have a higher priority.
>>>> Using 1500 leave some room for other implementations to have a higher
>>>> priority then tsc.
>>> please take a look at tsc_tc_init.
>> Yes, it would be better to try to fix that to find more TSC-broken
>> cases, including the one's we're talking about, if possible. If the
>> TSC works on your system it is a really good idea to use it. It is more
>> precise, it is much cheaper to sample (the HPET is off-chip) and it can
>> potentially provide system call free time to applications. Making the
>> HPET the default in all cases, including those where the TSC works well,
>> throws those advantages away for most people.
> In your experience, does the spread spectrum or other fuzzing of CPU clock
> frequencies to meet the FCC EMI emissions limit standard degrade the
> frequency stability of TSC (quite aside from the CPU clock frequency changes
> performed by power management functions) for precision timekeeping (e.g. NTP)?
In theory spread spectrum clocking, if it made it to the TSC, should have
no effect long term average frequency stability, which is all NTP tries
to steer, though it would reduce the effective precision of the TSC
somewhat by making the low order bits suspect. In practice I've not
been able to measure any effect of this on the TSC compared to a fairly precise
interface to a GPSDO. I don't know whether this is because the spread
spectrum clocking is just an external bus thing which is averaged out
of the CPU clock by the CPU's PLL, or that I've not found a measurement
that can distinguish spread-spectrum sample noise from generic
trying-to-do-timing-with-a-computer sample noise. Only averages can
be made reliably accurate, individual samples always seem to come
What I would say, however, is that it wouldn't surprise me if the
HPET clock is derived from the same jittered, spread spectrum bus
clock that the CPU's internal clock is derived from, so if there is
an effect from this there may be no escaping it. In any case,
for over-the-network NTP the precision of both the TSC and the HPET,
with SS jitter noise in the low order bits or not, is probably more
than adequate except for bragging; the thing I value more about the
TSC is the cheap-to-sample part, which improves everything including,
but not limited to, NTP.
Main Index |
Thread Index |