> On 20 Aug 2019, at 11:37, O'Connor, Daniel <dar...@dons.net.au> wrote:
>
>
>
>> On 19 Aug 2019, at 17:09, O'Connor, Daniel <dar...@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
> dar...@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..
--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
_______________________________________________
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
