[LinuxPPS] LinuxPPS and ONCORE receivers.

[Hal V. Engel]

On Tuesday 04 November 2008 14:47:18 Remco den Besten wrote:
> --remainder of the posting--
>
> From now on ntpdc -c kern shows offsets in the order of +/- 1 usec with the
> ACPI_PM timer and with a ntpd patched for
> nano precision.  As of now jitter remains at 2 usec, and the temperature
> dependency seems 'increasingly less' than with the TSC clocksource.
>
> My frequency of the PLL changed from +/- 49 (TSC) to 18.5 ppm (ACPI_PM),
> and the (early) results indicate that this PLL frequency is significantly
> more stable than the TSC option.
>
> I am curious how HPET will perform when I might be able to activate it
> on/with my processor.
>
> Thanks,
>
> Remco

I think that the HPET vs. ACPI_PM question is likely to be hardware dependent.

My understanding from what I have read is that the TSC timer uses a built in 
CPU counter that increments with each tick of the CPU clock.  There are a 
number of issues with this for timing applications such as ntp.  First the CPU 
clock will run at different rates on machines that have power management 
features enabled which means that the time base of the counter is not 
constant.  Second on multi-CPU/core machines it is difficult to assure that 
you are always using the same CPU for this counter and different CPUs may have 
had the counters drift over time.  Some newer processors have constant rate 
TSC timers that do not have these issues.  This is likely the case for newer 
(Late 2005 or later) AMD K8 processors.  

On the other hand there are some possible advantages to using the TSC timer if 
your machine does not change the CPU clock and you have a uni-processor system 
or if you have a newer processor that has a constant rate TSC timer.  First 
since this is basically a register in the CPU reading it is very fast.  One 
source I found said it was on the order of 1000 times as fast as reading the 
HPET or ACPI_PM timers which are external to the CPU. Another source claimed 
that in a tight loop he could read the TSC timer as it incremented by 2 (IE. 
every two CUP cycles).   This has the potential to reduce the latency of 
reading the time in the PPS interrupt handler but I don't know by how much or 
what part of the interrupt latency is caused by timer read latency.  Second 
the resolution of this counter is equal to the CPU frequency or for constant 
rate TSC timers some very high clock rate that is on the same order of 
magnitude.  So on a 1GHz machine this is a 1 nanosecond resolution which is 
considerably more fine grained than the HPET or ACPI_PM timers.  The 
resolution of the ACPI_PM timer is about 300 nanoseconds so it is worse than 
the HPET timer which has a minimum resolution of 100 nanoseconds.  Many HPET 
timers are somewhat better than this.  Since my HPET timer has a 40 nanosecond 
resolution I suspect that this is the reason that I am seeing better results 
using the HPET timer even though the HPET and ACIP_PM timers are both likely 
to be driven by the same oscillator.

Your TSC timer may have been exhibiting some of the issues listed above and if 
it was it would be very unstable for time keeping.   You might want to have a 
look here http://groups.google.com/group/fa.linux.kernel/msg/c8ae85a08ebd3aa4 
for some info from AMD about TSC timer issues.

Hal