On Sat, Sep 07, 2019 at 09:18:59AM +0930, O'Connor, Daniel wrote: > > > > 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.. >
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.' _______________________________________________ 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"
