[LinuxPPS] LinuxPPS comparable to FreeBSD here

[Hal V. Engel]

On Thursday 17 June 2010 03:25:24 pm Remco dB wrote:
> Dear all,
> 
> For some time now I run my LinuxPPS (thermostatised!) system with kernel
> 2.6.34, CONFIG_NO_HZ and CONFIG_HZ=1000 set and no hardpps.
> 
> Compared to my (also thermostatised) FreeBSD system (with hardpps) LinuxPPS
> performs almost equally.
> 
> See http remco.org/ntp
> 
> What I see it that the jitter (or 'rrdtool average') of LinuxPPS is less
>  than my FreeBSD jitter (i.e. freebsd and helium).
> 
> Both freebsd and helium are within the +/- 2 us range, roughly.
> 
> ntp2.remco.org runs also 2.6.34, CONFIG_NO_HZ, CONFIG_HZ=1000 and no
>  hardpps on a (remote) system, using an old 450 MHz machine with a PIT
>  timer. The system is not thermostatised and shows some temperature
>  dependencies, but the jitter far less than my other systems. Interesting .
>  . .
> Perhaps, when thermostatised it would produce a 'flat liner' ?
> 
> So I wonder, would adding hardpps _improve_ the LinuxPPS performance,
> considering 'general hardware boundary conditions'?
> 
> Currently I can't find out ;-(
> 
> Maybe Alexander is willing to publish a cookbook recipe to apply his kcbind
> patches, modified timepps.h etc etc so that the whole arrangement will
>  compile for somebody who is more into hardware? ;-)
> 
> Remco

Short HOWTO:

Get the kernel sources for 2.6.34.

Patch with the patch-2.6.34-ts13 located here:

http://github.com/ago/linux-2.6/downloads

Then patch with the attracted patch from this list that was submitted by 
Vitezslav Samel.  In my case I had to manually add the last line because it 
failed with patch.  YMMV.  But this is a very simple patch that only adds 
three lines to pps_kernel.h so doing it by hand is simple.

Configure, build and install the kernel.   Make sure to install the headers for 
2.6.34 in /usr/include.

Copy the patched pps.h to make it available for building ntp and other tools:

cp /usr/src/linux/include/linux/pps.h /usr/include/linux/pps.h

Get a kernel consumer version of timepps.h from here:

http://github.com/ago/pps-tools/raw/master/timepps.h

and put it into /usr/include.

Rebuild ntp.  

For the oncore add hardpps to the /etc/ntp.oncore* file.

That should be all you need to get this built and to have ntp and the kernel 
consumer make the connection.  

This was running on my machine for about 12 hours starting yesterday 
afternoon.  I am using the Oncore driver with a UT+.  It took it awhile 
(perhaps 10 minutes) to not show errors for ntp_adjtime() and ntp_gettime() 
when running ntptime.    After about 12 hours the clock still had offsets of 2 
to 3 microseconds and it never got below 2 microseconds at any time when 
running ntpq -p.

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
oGPS_ONCORE(0)   .GPS.            0 l    2   16  377    0.000    0.003   0.001

ntptime always showed an offset of 0.000 us?

# ntptime
ntp_gettime() returns code 0 (OK)
  time cfc61292.26fac5f4  Fri, Jun 18 2010  8:43:14.152, (.152264848),
  maximum error 3236 us, estimated error 2 us
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset 0.000 us, frequency -38.732 ppm, interval 256 s,
  maximum error 3236 us, estimated error 2 us,
  status 0x2107 (PLL,PPSFREQ,PPSTIME,PPSSIGNAL,NANO),
  time constant 4, precision 0.001 us, tolerance 500 ppm,
  pps frequency -38.741 ppm, stability 0.021 ppm, jitter 2.606 us,
  intervals 272, jitter exceeded 9, stability exceeded 0, errors 1.

With hardpps ntp did get the offset down to low values quickly and it was below 
10 microseconds in a matter of minutes.  So this is much quicker than without 
hardpps.

But there appears to be some issues with hardpps.  When I run without hardpps 
this system will have offsets of less than 1 microsecond most of the time once 
things have stabilized (IE. after about 1 hour) if it is lightly loaded.  
ntptime also shows offset values when not using hardpps.  So it appears that on 
this system that I will have better time keeping not using hardpps at least 
when the machine is lightly loaded and temperature stable   

Here are what things look like with hardpps turned off after about 1 hour.

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
oGPS_ONCORE(0)   .GPS.            0 l    2   16  377    0.000    0.001   0.000

# ntptime
ntp_gettime() returns code 0 (OK)
  time cfc63094.c4eef170  Fri, Jun 18 2010 10:51:16.769, (.769271226),
  maximum error 233 us, estimated error 0 us
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset -0.110 us, frequency -38.632 ppm, interval 256 s,
  maximum error 233 us, estimated error 0 us,
  status 0x2101 (PLL,PPSSIGNAL,NANO),
  time constant 4, precision 0.001 us, tolerance 500 ppm,
  pps frequency -38.624 ppm, stability 0.009 ppm, jitter 2.867 us,
  intervals 302, jitter exceeded 10, stability exceeded 0, errors 1.

One other thing that I notice about the hardpps vs. no hardpps is that the 
stability numbers (next to last line of the ntptime output) are much lower 
with no hardpps (0.009 ppm vs. 0.021 ppm).  Not sure what the significance of 
this is if any. 

My kernel is currently configured with CONFIG_NO_HZ and CONFIG_HZ=1000.

Hal 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: k-comsumer.patch
Type: text/x-patch
Size: 570 bytes
Desc: not available
Url : http://ml.enneenne.com/pipermail/linuxpps/attachments/20100618/8f5a7311/attachment.bin