On Sat, Sep 07, 2019 at 09:18:59AM +0930, O'Connor, Daniel wrote:
>
>
> > On 20 Aug 2019, at 11:37, O'Connor, Daniel wrote:
> >
> >
> >
> >> On 19 Aug 2019, at 17:09, O'Connor, Daniel 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: 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.1214.52.129.403 u 64 64 370.349 -0.631
> > 0.299
> > o127.127.22.0.PPS.0 l 13 16 3770.0001.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.1214.52.129.403 u 35 64 3770.320 -0.348 0.027
> -203.31.81.2 27.124.125.251 3 u 53 64 377 12.1161.311 1.951
> 0.au.pool.ntp.o .POOL. 16 p- 6400.0000.000 0.004
> 1.au.pool.ntp.o .POOL. 16 p- 6400.0000.000 0.004
> 2.au.pool.ntp.o .POOL. 16 p- 6400.0000.000 0.004
> 3.au.pool.ntp.o .POOL. 16 p- 6400.0000.000 0.004
> o127.127.20.0.GPS.0 l6 16 3770.0000.006 0.004
> +13.239.113.24 .GPS.1 u6 64 377 29.971 -0.054 0.074
> *103.51.68.133 .PPS.1 u 56 64 377 45.0184.821 0.143
> -103.38.120.36 130.95.179.802 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"
