[LinuxPPS] convergence patch

[Bernhard Schiffner]

On Friday 08 May 2009 03:45:32 Hal V. Engel wrote:
> On Thursday 07 May 2009 11:16:35 am Bernhard Schiffner wrote:
> > I run machines which have little uptime because they are switched on and
> > off regulary. If they can't sync their time to below videoframe-precision
> > within minutes (and hold it there!)
>
> I am not sure what "videoframe-precision" is.  Does this mean +-1
> millisecond or +-100 microsecinds or +-10 mincroseconds or +-1 microsecond
> or something else?  Lots of video work is done on Windows machines and the
> time API there only has a precision of +- 15.6 milliseconds (IE. 1/64th of
> a second).  So just about any *nix machine that is using ntp to sync to
> public time servers on the Internet should do better and machines using PPS
> type reference clocks should be 3 to 4 orders of magnitude better.

(This has nothing to do with LinuxPPS)

Think about 15-30 fps.
This means 30_60 ms(!).
So about 1ms would be fine.

Yesterday I had a netbook (with standard Debian Lenny): after 1 day with 
internet and ntp connection it was off by 56 ms(!).

This indicates, that there are problems. 
I observed the behaviour, John described: starting ntp, calming down a little 
bit, something internal switches, offset rises and comes back to zero over 
_hours_.

If you start a host for doing some "coordinated" measuring you should be sure 
about timekeeping in a scale the others do too very soon (minutes).
(video: 30 ms, machines 10 ms, sound 5ms, networking 1 ms)
It's much better to have some reserves as LinuxPPS provides. 

> The kernel convergence patch should help with startup convergence issues
> for current linux kernels and also help keep offsets low after startup.  In
> addition, I use the --panicgate parm when starting the ntp daemon which
> will cause ntp to sync the system clock to the reference clock at start up.
I missed this. Thanks for this hind!

I watched an ntpd:
1.) it starts
2.) it has a big offest to the ntp server (0,5 s)
3.) it "suddenly" reduces this offset.
4.) it starts long-time behavior.
(seems to grep the drift, use something calculated while booting etc.)
5.) if the "variables" gotten in 4. are wrong estimates it now takes hours to 
correct it.
6.) You switch off before ntpd stabilzes and 5.) will have a problem netxt 
time too.

>  The clock will jump once instead of being slewed if the system clock is
> off by more than 128 milliseconds.   This will be the case on most machines
> that have been powered off for more than a few minutes.  What I find is my
> starting offset is typically under 50 microseconds once ntp causes the time
> to sync with the ref clock when I do this and that ntp without the
> convergence patch will keep offsets below +-100 microseconds as the
> oscillator temperature comes up to normal operating temperature (perhaps 15
> minutes).  I am hoping that ntp will do better during this warm up period
> with the convergence patch in place.
My bet: "Yes, you can!" :-)

>
> By the way this:
>
> # ntptime
> ntp_gettime() returns code 0 (OK)
>   time cdadc497.bcf77680  Thu, May  7 2009 13:35:35.738, (.738151202),
>   maximum error 1004 us, estimated error 0 us, TAI offset 0
> ntp_adjtime() returns code 0 (OK)
>   modes 0x0 (),
>   offset 0.008 us, frequency -38.976 ppm, interval 1 s,
>   maximum error 1004 us, estimated error 0 us,
>   status 0x2001 (PLL,NANO),
>   time constant 4, precision 0.001 us, tolerance 500 ppm,
>
> # ntpq -p
>      remote           refid      st t when poll reach   delay   offset 
> jitter ==============================================
> *GPS_ONCORE(0)   .GPS.            0 l   11   16  377    0.000    0.000  
> 0.001
>
> is how my machine is doing with the convergence patch a few hours after
> restarting the kernel and ntp.  I think I am going to keep the patch in
> place for now.
>
> Hal
BTW: IIRC there was something to teach ntpq etc. output with µs ...


Bernhard