From owner-freebsd-arm@freebsd.org Thu Aug 15 15:49:13 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 BC475ACE57 for ; Thu, 15 Aug 2019 15:49:13 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound3d.ore.mailhop.org (outbound3d.ore.mailhop.org [54.186.57.195]) (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 468W8n2WdKz40c2 for ; Thu, 15 Aug 2019 15:49:13 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1565884152; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=Rc/r9rw9QZIdQRkji0Kn4a817OB9tYJf0JBvLwYzb2pEOs7cTQkIo3aow5xrJmNxzMOYqVFBdID6g S76VB2/HlDZH2Ns7KFqeWV1cOBXEmyPkyIlXLJ03c6WvduM2dFYKuZSyxyYdcdYa9xIm6Eq7047SgG x/ufi6YzCJoRUh3yejYarEjQ7UE9OjtAd9EXFphbgRB3P+DN5V4oaelcfaSB4nD6Kb8huZTL9zArhc 4N4FuxyDSrZ956DF8BfuamqRaiCZykZanvSjniy4X0wjR4m0VFsSHNaFC3mF+zwLVESQcgexqyqKX0 6XwRQ+lMnZTZmKOcpjzRX2P/U6219zw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=XiPycb5w43Vt2bBteymHovsSCmvl6MggeTErsW580p0=; b=TdLv1iSgVeCdeL0RgmUSDhGkrGb/DV3pfcZMyXySgixik7WnwsZ/6SrzCBKPuaqvsetZanbAf3vui 5ogAIIPEldTm6wflm2ib3RrsOfLdc7CczV+8gml5Swyl6CNuSb7yd/eTfn7Iw6JNfxsTYQ65inivK0 C3XSauKa/JaAU73oIz+pxC0whPBFAyBo2CW2wX0sMe537GmoOVcqxizAnhT+7DSeIWagTsqEV+ZcAn tqoqyItEvs/hyRiiWZyCE/zNxWN5FNnRPkPwWeoty3uDP4SNNeHF3iyby7eePByBi5w+XRx9fz24DD qfhjiCtqztBNk7ok84s8TsAAOfugbwg== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=XiPycb5w43Vt2bBteymHovsSCmvl6MggeTErsW580p0=; b=qnrOZ6gf32gElnIiLm5kT70zOzJFq8artNMA3MmjAo9cREWaOEw+TbceEcvAg8U3nBxsSRz7ppbaX DhwvuVKOAuxwvuYbGV5mlrSEwFhzXrWDDNmHMvv0VDhZ61AfbZargAhOTdsgyu3cYpfnEOtshHqlbQ ca7bs4cpFQ8+3YesffWPxslB3YFlwxJRdtjmhMhFwzZdC1ByPn9qmvDS92CN+WwTBIImejy5+l5cMQ Td+GxPlom2AHmJ169bXgmp83XBolEMOyAFm+OI7ijW7Srp1dA6pQnsUtTIQsxKz4iyNllU4SBZLxAq eq6oI/HTaR9OcWtKEGsDE7YrPLmpI6A== X-MHO-RoutePath: aGlwcGll X-MHO-User: 37a81477-bf74-11e9-b67b-cdd75d6ce7a8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 37a81477-bf74-11e9-b67b-cdd75d6ce7a8; Thu, 15 Aug 2019 15:49:09 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x7FFn8uV059591; Thu, 15 Aug 2019 09:49:08 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <24b0eaf25b64d6098b390df092866c69e352d859.camel@freebsd.org> Subject: Re: Is it a good idea to use a usb-serial adapter for PPS? Yes, it is. From: Ian Lepore To: Per Hedeland Cc: freebsd-arm@freebsd.org Date: Thu, 15 Aug 2019 09:49:08 -0600 In-Reply-To: <0426fc8b-5398-d8ab-561e-7823c24403a5@hedeland.org> References: <69a9bed3-4d0a-f8f6-91af-a8f7d84ee307@hedeland.org> <345bae77417c2495f55799b4c7ca2784f4ece9ed.camel@freebsd.org> <7312032d-2908-9414-0445-6b442c3a02e5@hedeland.org> <523b6f0a0fa5f2aeec298fa74df25d3c4af66acc.camel@freebsd.org> <0426fc8b-5398-d8ab-561e-7823c24403a5@hedeland.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 468W8n2WdKz40c2 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.983,0]; ASN(0.00)[asn:16509, ipnet:54.186.0.0/15, country:US] 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: Thu, 15 Aug 2019 15:49:13 -0000 On Thu, 2019-08-15 at 13:46 +0200, Per Hedeland wrote: > On 2019-08-09 22:17, Ian Lepore wrote: > > On Fri, 2019-08-09 at 21:36 +0200, Per Hedeland wrote: > > > On 2019-08-09 17:28, Ian Lepore wrote: > > > > On Thu, 2019-08-08 at 22:26 +0200, Per Hedeland wrote: > > > > > On 2019-08-07 18:53, Ross Alexander wrote: > > > > > > In Message-ID: < > > > > > > B9EFA4D4-C1AD-4181-B421-F6BD53434FA5@dons.net.au>, > > > > > > someone wrote [sorry, attrib trail is a little blurry ed.]: > > > > > > > > > > > > > > Most people are not worried about their kernel clock > > > > > > > > being > > > > > > > > 200 > > > > > > > > microseconds off from UTC, even if they're using the > > > > > > > > PPS > > > > > > > > signal > > > > > > > > from a > > > > > > > > GPS receiver. So I think most people should feel > > > > > > > > completely at > > > > > > > > ease > > > > > > > > using a USB serial adapter as the input device for a > > > > > > > > PPS > > > > > > > > signal. > > > > > > > > > > > > Some people do worry, although getting PPS to work over USB > > > > > > is > > > > > > a > > > > > > fine > > > > > > first step and I'm grateful for the breadcrumb trail. > > > > > > > > > > For those that do worry, you can of course tell ntpd to > > > > > correct > > > > > for a > > > > > semi-fixed offset (via the 'time1' option to the 'fudge' > > > > > command) > > > > > - > > > > > once you know how large the offset is... More important is a > > > > > low > > > > > jitter, and 20-30 microseconds seems quite good. > > [snip] > > > > Would you object to > > > me posting an article with a *link* to your message > > > (i.e. > > > https://lists.freebsd.org/pipermail/freebsd-arm/2019-August/020263.html > > > ) > > > in the newsgroup? > > > > It might be better to use the link to the copy I sent to the > > freebsd- > > usb list, since it's more directly on-topic: > > > > https://lists.freebsd.org/pipermail/freebsd-usb/2019-August/016078.html > > > > I also think it would be wise to add a caveat that the results are > > for > > FreeBSD. I would expect linux performance to be similar. But for > > Windows, all bets are off; Windows drivers for usb-serial devices > > are > > said to vary wildly in quality depending on the vendor. > > OK, I took it to the newsgroup, and while the initial comments were > pretty much "it's impossible to get good results via USB" even though > your test seemed to show that it wasn't, after some discussion it > seems quite strange to me too that you get a pretty much fixed offset > and low jitter, since the USB communication including DCD/CTS > detection is apparently based on polling from the host. > > I have a theory that your making the kernel clock be based on the 10 > MHz clock also ended up locking the USB poll frequency to that clock, > and thus to the PPS signal - this would certainly explain the result. > Do you think this is a possibility? Would it be possible for you to > re-run the test without modifying the kernel clock? (I do understand > that the results will be harder to interpret with the drift, and > ntpd's correction of it, coming into play.) > > --Per > I'm not sure what you mean by "modifying the kernel clock". The kernel clock always runs on some frequency source. Typically it's derived from the cheap 24 MHz crystal that clocks the SoC, sometimes after being scaled up to 66 MHz by a phase-fractional PLL within the SoC. I arranged to use a very stable nearly-drift-free frequency source instead of a cheap crystal for counting time in the kernel. The kernel clock has nothing to do with usb, including polling intervals; the usb controller hardware handles that, and the root source clock for that is the cheap 24 MHz crystal. I think people are massively confused by usb. A usb 2.0 bus runs at 480MHz. That means the time to transmit a packet describing a usb serial pin-change event takes literally a dozen or so nanoseconds. The time it takes to transmit an entire sector of disk data is 2 microseconds; even if continuous disk data is flowing, the usb serial adapter gets its round-robin opportunity to send a packet on the bus in between them. A USB 2.0 bus spends most of its time idle. The devices on the bus are polled, but the polling happens in time slots that are 125 microseconds wide. There's just no reason for a lot of jitter or latency. I'm not on a crusade to change the minds of people who make judgements based on gut feelings and reject objective measurements. I put the measurements out there, and I described the measurement methodology. (Precision timing is what I do for a living, btw.) I'm perfectly willing to explain the methodology in more detail or help interpret the results, but I'm not going to butt heads with people who just reject data they don't like for emotional reasons. -- Ian