[LinuxPPS] Recommendation / Re: Stats & architectures

[Remco den Besten]

Hello Robert,

Eh well... I am more into hardware than into software actually ;-)
Anyway, look at the performance. Normally the (software) PLL
has to lock, and -depending upon your 'previously formed driftfile'-
it'll take more or less time to sync and lock. Making some plots
with mrtg or rrdtool might clarify issues.

I also did some trial and error research and found out that by
'seperating the problem', i.e. driver issues and PPS-issues, the ATOM driver
has the 'least amount of interdepedencies' with the overall PPS-core.

I might not use the right jargon. Excuse me, in my 'normal life' I am a 
manager ;-)

Cheers,

Remco



> Hi Remco,
> many thanks for that info.
>
> I've rebuilt ntp to include the Atom refclock and enabled that in 
> ntp.conf.
> I also disabled PPS for the NMEA refclock.
>
> This is the first time I've ever started ntpd without it jumping or 
> hunting,
> even when it's previously been in lock and had a valid drift file.
> It's immediately showing an offset of just 0.003 and jitter 0.001
>
> In lock within a couple of minutes 'oPPS(0)' and so far looking dead 
> stable!
>
> It does possibly show up a bug in the NMEA refclock? With 'flag3 0' it 
> seems
> to still be trying to use PPS -
>
> Mar 11 18:53:39 gate ntpd[28986]: kernel time sync status 0040
> Mar 11 18:53:39 gate ntpd[28986]: refclock_atom: time_pps_kcbind failed:
> Operation not supported
> Mar 11 18:53:39 gate ntpd[28986]: refclock_nmea: found GPS source
> "/dev/gps0"
> Mar 11 18:53:39 gate ntpd[28986]: refclock_nmea: try alternate PPS device
> "/dev/pps0"
> Mar 11 18:53:39 gate ntpd[28986]: refclock_nmea: found PPS source
> "/dev/pps0" <<<<<<<
> Mar 11 18:53:39 gate ntpd[28986]: frequency initialized -66.028 PPM from
> /var/lib/ntp/drift
> Mar 11 18:54:30 gate ntpd[28986]: synchronized to GPS_NMEA(0), stratum 9
> Mar 11 18:54:30 gate ntpd[28986]: kernel time sync status change 0001
> Mar 11 18:55:21 gate ntpd[28986]: synchronized to PPS(0), stratum 0
>
> Overall this looks much, much better - the error and jitter are (so far)
> staying low and the poll interval to other machines is ramping up - it was
> rarely above the minimums previously, presumably due to the poor jitter
> values.
>
>
> Thanks again,
> Robert.
>