From owner-freebsd-arm@freebsd.org Sun Sep 8 13:42:44 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9F0DCF36D5; Sun, 8 Sep 2019 13:42:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46RCCh2PSXz3QnD; Sun, 8 Sep 2019 13:42:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x88Dg9aK022697 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 8 Sep 2019 16:42:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x88Dg9aK022697 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x88Dg5Vc022692; Sun, 8 Sep 2019 16:42:05 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 8 Sep 2019 16:42:05 +0300 From: Konstantin Belousov To: "O'Connor, Daniel" Cc: Ian Lepore , "usb@freebsd.org" , "freebsd-arm@FreeBSD.org" Subject: Re: Is it a good idea to use a usb-serial adapter for PPS input? Yes, it is. Message-ID: <20190908134205.GO2559@kib.kiev.ua> References: <61B1AAF3-40F6-47BC-8F05-7491C13BF288@dons.net.au> <9E142F1A-5E8C-4410-91F5-7C80B3D0A15B@dons.net.au> <9D2ACA87-C2DB-40D9-9638-B0E215A4EEC0@dons.net.au> <0A7796DA-508B-4FE6-B5C0-391EC5F46C86@dons.net.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0A7796DA-508B-4FE6-B5C0-391EC5F46C86@dons.net.au> User-Agent: Mutt/1.12.1 (2019-06-15) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-Rspamd-Queue-Id: 46RCCh2PSXz3QnD X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-2.94 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_SPF_SOFTFAIL(0.00)[~all]; IP_SCORE_FREEMAIL(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.94)[-0.942,0]; IP_SCORE(0.00)[ip: (-2.63), ipnet: 2001:470::/32(-4.45), asn: 6939(-3.15), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; SUBJECT_HAS_QUESTION(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Sep 2019 13:42:44 -0000 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 darius@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.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.'