[LinuxPPS] LinuxPPS and ONCORE receivers.

[Hal V. Engel]

On Tuesday 04 November 2008 16:44:27 Hal V. Engel wrote:
> 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

I did some more checking on TSC timer stuff.  If my CPU had an invariant TSC 
timer I would test it to see how well it works.  I also learned some other 
things about TSC timers.

First to check my CPU in more detail I downloaded and build cpuid from:

http://etallen.com/cpuid.html

Running it I got this relevant info:

Advanced Power Management Features (0x80000007/edx):
      temperature sensing diode      = 0x1 (1)
      frequency ID (FID) control     = 0x1 (1)
      voltage ID (VID) control       = 0x1 (1)
      thermal trip (TTP)             = 0x1 (1)
      thermal monitor (TM)           = 0x0 (0)
      software thermal control (STC) = 0x0 (0)
      TscInvariant                   = 0x0 (0)

The AMD "BIOS and Kernel Developer's Guide (BKDG) For AMD Familiy 11h 
Processors" says that Tscinvariant = 0 means that the TSC clock is not P 
state, C state  and 	STPCLK-throttling invariant.  So it is not suited to use 
for timing applications like ntp unless P state, C state transitions and 
STPCLK-throttling are disabled.  Disabling P state and C state transitions is 
easy but I am not sure about how to disable STPCLK-throttling.

I also learned that for the k8 processors that are Tscinvariant that the TSC 
timer can run at either the base clock rate (200MHz in most cases) or the P(0) 
clock rate which will be 1GHz in most cases. 

I also found this: http://ltt.polymtl.ca/svn/trunk/lttv/doc/developer/tsc.txt

Which has additional info on Intel CPUs.  It looks like starting with later P4 
processors that the TSC in invariant but the TSC clock speed  is 
implementation dependent.

It also appears that for AMD CPUs that the kernel code was marking the TSC 
timer as unstable even on systems with an invariant TSC timer.  There is a 
patch that appears to have been applied to 2.6.27 that corrected this bug but 
I don't know if this actually happened.

http://linux.derkeiler.com/Mailing-Lists/Kernel/2008-09/msg06172.html

So even if you have an AMD CPU with invariant TSC depending on your kernel 
version the kernel might still mark it as unstable and not use it.

Hal