PPS and selection algorithm issues

[Jim Pennino]

On Sun, Sep 22, 2024 at 01:29:26PM -0700, Hal Murray wrote:
> 
> users at ntpsec.org said:
> > *NMEA(0)     .GPS.        0 l    3   16  377   0.0000   0.2415 0.3372
> > xPPS(0)      .PPS.        0 l    2   16  377   0.0000 -0.7080   0.0497 
> 
> The x says it isn't using the PPS driver.
> 

Yes, I know, and that is the issue.

However now there are realistic values for reach, delay, offset and
jitter where there were not before the mentioned patches.

> > refclock nmea flag1 0 baud 9600 minpoll 4 time2 0.097
> > refclock pps minpoll 4 flag2 0 time1 0.002 
> 
> Try adding a prefer to the nmea line.  THe PPS driver needs some place to 
> get the seconds.  The prefer keyword is a hack to do that.

I think tried prefer for both in separate tests, but don't remember
exactly what happened.

I'll try it again and note the results.

> 
> ------
> 
> If you want to get geeky, turning on flag3 for the PPS driver will move 
> the PLL into the kernel.  That makes a significant difference.  I should 
> make some pretty grapsh.
> 
> That isn't supported on the kernels shipped by most Linux distros -- it 
> conflicts with power saving (or something like that).  If you want to 
> build your own kernel, it needs:
>   CONFIG_NTP_PPS=y
> Or you can try FreeBSD.  The kernel they ship is ready to go.

I know it is not supported by Ubuntu and I have no desire to be building
kernels.

I have thought about switching to BSD as it still supports legacy ntp
and does support PLL, but I would think the BSD people will eventually
also deprecate legacy ntp.