Is it a good idea to use a usb-serial adapter for PPS input? Yes, it is.

[Konstantin Belousov]

On Sat, Sep 07, 2019 at 09:18:59AM +0930, O'Connor, Daniel wrote:
> 
> 
> > On 20 Aug 2019, at 11:37, O'Connor, Daniel <darius at dons.net.au> wrote:
> > 
> > 
> > 
> >> On 19 Aug 2019, at 17:09, O'Connor, Daniel <darius at dons.net.au> wrote:
> >> I am going to try this diff but buildkernel is going to take a while...
> > 
> > Was a lot faster cross building, so I installed it this morning:
> > [gps 1:56] ~ >uname -a
> > FreeBSD gps 13.0-CURRENT FreeBSD 13.0-CURRENT #1 41a4c010326-c262109(master)-dirty: Tue Aug 20 11:04:57 ACST 2019     darius at midget.dons.net.au:/usr/obj/arm-src/arm.armv7/sys/GENERIC  arm
> > 
> > [gps 1:57] ~ >dmesg|grep pps
> > am335x_dmtpps0: <AM335x PPS-Capture DMTimer4> mem 0x48044000-0x480443ff irq 30 on simplebus0
> > [gps 1:58] ~ >ll /dev/pps0 /dev/dmtpps
> > crw-rw----  1 root  ntpd   0x41 20 Aug 01:09 /dev/dmtpps
> > lrwxr-xr-x  1 root  wheel     6 20 Aug 01:09 /dev/pps0 -> dmtpps
> > 
> > [gps 1:58] ~ >cat /etc/ntp.conf
> > server 10.0.2.1 iburst prefer
> > 
> > server 127.127.22.0 minpoll 4 maxpoll 4
> > fudge  127.127.22.0 refid PPS
> > 
> > [gps 1:59] ~ >ntpq -nc pe
> >     remote           refid      st t when poll reach   delay   offset  jitter
> > ==============================================================================
> > *10.0.2.1        214.52.129.40    3 u   64   64   37    0.349   -0.631   0.299
> > o127.127.22.0    .PPS.            0 l   13   16  377    0.000    1.000   0.106
> > 
> > It certainly seems happier with the PPS than it was before.
> 
> Reader, it was not happy after a longer wait.
> 
> I ended up getting a newer GPS engine (u-Blox NEO-M8T) and connecting it, and after a run overnight I get:
>      remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
> +10.0.2.1        214.52.129.40    3 u   35   64  377    0.320   -0.348   0.027
> -203.31.81.2     27.124.125.251   3 u   53   64  377   12.116    1.311   1.951
>  0.au.pool.ntp.o .POOL.          16 p    -   64    0    0.000    0.000   0.004
>  1.au.pool.ntp.o .POOL.          16 p    -   64    0    0.000    0.000   0.004
>  2.au.pool.ntp.o .POOL.          16 p    -   64    0    0.000    0.000   0.004
>  3.au.pool.ntp.o .POOL.          16 p    -   64    0    0.000    0.000   0.004
> o127.127.20.0    .GPS.            0 l    6   16  377    0.000    0.006   0.004
> +13.239.113.24   .GPS.            1 u    6   64  377   29.971   -0.054   0.074
> *103.51.68.133   .PPS.            1 u   56   64  377   45.018    4.821   0.143
> -103.38.120.36   130.95.179.80    2 u   63   64  377   57.946   -8.622   0.242
> 
> Which seems quite a lot better :)
> 
> Is there a reason to *not* increase the number of time hands in the kernel by default?
> 
> I suppose it would be good to change it to the same structure as the feed forward clock stuff, that way it is much easier to change the number of hands at compile time..
> 

The reason to not increase it by default is the same as the reason why it
was reduced.  But since I did still not provided the analysis why increasing
timehands count helps for Ian' and your case, I think that making it easy
to increase the timehands number is due.

Please see D21563 'Make timehands count selectable at boottime.'