[LinuxPPS] Kernel 2.6.38 and hardpps

[Hal V. Engel]

On Monday, July 04, 2011 11:30:17 AM Udo van den Heuvel wrote:
> On 2011-07-04 01:54, Hal V. Engel wrote:
> > Which is basically saying that hardpps is not supported. by the kernel.
> 
> Are the headerfiles -to build ntp- OK?
> 
> Kind regards,
> Udo

Just an FYI about the new kernel consumer.  After installing the correct 
kernel headers and rebuilding ntp this is now working on my machine.  I have 
tested it enough to report that I am getting good results using the kernel 
consumer in 2.6.38 with my Oncore UT+ most of the time.  

The clock seems very stable as long as the machine has a constant work load.  
But under changing loads the offsets as reported by 

ntpq -p

will jump around rapidly at times and will sometimes fluctuate more than a 
millisecond in a matter of seconds.  But as soon as the load on the machine 
stabilizes to the new level it only takes a few seconds for the reported 
offsets to stabilize in the 1 microsecond range.

Over all I like the results I am getting.  The time converges to very small 
offsets rapidly, with in a few microseconds with in a matter of a few minutes 
of when ntp is started, and most of the time offsets are in the 1 microsecond 
range other than when the work load on the machine is changing.

It looks to me like some additional work is needed to stabilize the clock 
under changing work load conditions.  Hopefully this will be fully sorted out 
sometime soon.  In the mean time the kernel consumer is very usable in spite 
of this issue and I will continue to use it.

By the way when using the kernel consumer ntptime always reports an offset of 
0.000 us even at times when ntpq -p is showing larger offsets.  I am not sure 
that this is correct.  Shouldn't the offsets reported by ntptime and ntpq -p 
more or less agree other than the reporting precision (IE. milliseonds vs. 
microseconds)?  This is the case when not using the kernel consumer.  Could 
this be a bug?

Hal

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

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

# ntptime
ntp_gettime() returns code 0 (OK)
  time d1c2472b.2110d380  Fri, Jul  8 2011 20:19:07.129, (.129163814),
  maximum error 81810 us, estimated error 2621 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset 0.000 us, frequency -37.883 ppm, interval 256 s,
  maximum error 81810 us, estimated error 2621 us,
  status 0x2107 (PLL,PPSFREQ,PPSTIME,PPSSIGNAL,NANO),
  time constant 4, precision 0.001 us, tolerance 500 ppm,
  pps frequency -38.101 ppm, stability 0.023 ppm, jitter 2639.751 us,
  intervals 188, jitter exceeded 16, stability exceeded 9, errors 0.

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

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
xGPS_ONCORE(0)   .GPS.            0 l    3   16  377    0.000    0.000 473.424
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ml.enneenne.com/pipermail/linuxpps/attachments/20110708/27b01987/attachment-0001.htm