From owner-freebsd-arm@freebsd.org Sun Aug 18 21:46:00 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 4A076D21BB for ; Sun, 18 Aug 2019 21:46:00 +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 46BVx36JrWz419n for ; Sun, 18 Aug 2019 21:45:59 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1566164758; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=wKOa/be2SUo1ADaPZdjJLudZcwsPIB6XJKuGeblI7Lm1ncYkGhVB5E9sfldPukVcv6trdlxKg7Tf7 fqqdchyx2WCnp+8rg3Ee4xJcitTLd34beCOCMYwSZBuPvnr9iwpDRfXuEPiiiFYlJMb2OZrNvivBai GJwTlDBorLof/utgsFKhl6wCY+n9Gwtsr6qcnGlIuIVQ3JdaeNJZo4htLeJ322yPL4oq45hm0kFpk3 fvbPuhil4Wb0dRw6eoHNj8/DhKoK7oSN7XF8ktRyPoq9S4jXqBqTdeJWCgu6UXKdwSqx5YNpXSAz/u 95C+LwYwNh4LitTSg2rMqVvdmeIDugw== 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:to:from:subject:message-id:dkim-signature:from; bh=5BxlUEQeczJB/RLYG3Xp0hZVVJ5lapbfxS/mupg09+I=; b=kkktc4OutFRk7KqmbkGOYRp+lolrzD/Y2oxslgRnOos7+35r+i1JZm8HyUDjRaqGesxtiqWOL1dcp ocLSy3sqd34IeuHz3L1q68w8jBFrJLz7iUouLFmDnWqHkWZZB56RYcibLyMO4nMiFns7NcveZNbFwN gizx95ydC/6mdwQ2us/w39Su0aI+emwAMYPPKYzxgUuern1kC8COhC9WETIImZGD5fxywlULbKGQFD H37CX9CCEvn5BqDEjlDhWlduZk1ddxr86S/8kY+BI6/imd3HdAPDkwzuWfHD0IGzyXKaUHiy6bjyHo 47tjS8oZruOV26VEFBEog3+0PR9TnrA== 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:to:from:subject:message-id:from; bh=5BxlUEQeczJB/RLYG3Xp0hZVVJ5lapbfxS/mupg09+I=; b=WlNuK1C0NwlffmiemrvP22icfr/zdL31ydFzXlI59wYbJMsx9v3NcO3I250qL6fWX2zsW0/d9zE6m OuHHypV+GOiP6ZqditbuGxSVX8XlfFrNEJTKjsvDkABq0n2pPPGawd2K6A3zlP67efYPvtUJSdsI7x 0koOxOOVBIaWdyJKmGhzaRARjdt//JRSlwJHCcc7eFlOunt3y8JJqglPq8rDYk9HjqEUPmA+EnT8mr +WG3mhoyadakUGvhI3V4J/WqVDCG0fAdNt4CnX65QlcTMQwjb1FdN4RhxXmtMs6EmXOC8f4gLcDFln isgbqfIv+enjw7Bz0VTgWpMGg52h9bA== X-MHO-RoutePath: aGlwcGll X-MHO-User: 8e2f4f86-c201-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 8e2f4f86-c201-11e9-b67b-cdd75d6ce7a8; Sun, 18 Aug 2019 21:45:56 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x7ILjsq2073110; Sun, 18 Aug 2019 15:45:54 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <804cfca3edf6d8d40a72257b4f1e876200721c48.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: Ross Alexander , freebsd-arm@freebsd.org Date: Sun, 18 Aug 2019 15:45:54 -0600 In-Reply-To: References: 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: 46BVx36JrWz419n 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_SHORT(-0.98)[-0.984,0]; NEURAL_HAM_LONG(-1.00)[-1.000,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: Sun, 18 Aug 2019 21:46:00 -0000 On Thu, 2019-08-15 at 16:02 -0600, Ross Alexander wrote: > In <24b0eaf25b64d6098b390df092866c69e352d859.camel@freebsd.org>, > Ian Lepore writes: > > > [... ed.] I arranged to use a very stable nearly-drift-free > > frequency source instead of a cheap crystal for counting time in the > > kernel. > > You have my complete and focussed attention. Say on. > I detailed the design of the measurement system in the original message. Basically it involves feeding a very stable external clock signal to a block of timer hardware within the imx6 SoC and using that timer hardware as the kernel clock. The source of the stable external clock has these specs: https://www.microsemi.com/product-directory/gps-instruments/4152-syncsystem-4380a I'm a software engineer for the division of Microsemi that makes those devices. If it wasn't the clock source you wanted to hear more about, then let me know in more detail what you'd like to know. > > [WRT USB 2, ed.] the polling happens in time slots that are 125 > > microseconds wide. There's just no reason for a lot of jitter or > > latency. > > 125 microseconds is a lot of jitter. Latency is a don't care, you can > fudge that out. Looking at a Pi 1b+, running some consumer grade > Ublocks GPS module, a five year old Linux, and with a view of only > half the sky (but using PPS on a GPIO pin): > It's negligible jitter for everyday computer use. It's a lot if you're doing something like timestamping financial transactions, or recording radio-astronomy observations, but the people doing that sort of thing usually aren't using ntpd to sync their clocks (they're using ieee- 1588, or custom solutions such as PCI irig input cards). But, as I detailed in the previous followup to Per Hedelund's post, I don't think there is a 125us latency or jitter introduced due to the usb bus frame rate. At least on the FTDI usb-serial chips I tested with, usb bulk transfers are used, and those are not limited to one transfer per bus frame or microframe. I'm still trying to find more info on the low-level usb part of this, because I was expecting to see average latency and jitter on the order of 50-60us each. That was based on an assumption I held until recently that on a usb 2.0 bus any given device would get an opportunity to deliver new data at most once every 125us, but now I don't think that limitation exists, at least for bulk transfers. > > autopsy:/u0/rwa > ntpq chime > > > > ntpq> lpee > > remote refid st t when poll reach delay offset jitter > > ============================================================================== > > oPPS(0) .PPS. 0 l 8 16 377 0.000 0.001 0.002 > > *SHM(0) .GPS. 5 l 6 16 377 0.000 419.464 310.013 > > > > ntpq> rl &1 > > associd=10146 status=911a conf, reach, sel_falsetick, 1 event, sys_peer, > > srcadr=PPS(0), srcport=123, dstadr=127.0.0.1, dstport=123, leap=00, > > stratum=0, precision=-20, rootdelay=0.000, rootdisp=0.000, refid=PPS, > > reftime=e1005453.fffff7a5 Thu, Aug 15 2019 15:59:47.999, > > rec=e1005454.debc0ef4 Thu, Aug 15 2019 15:59:48.870, reach=377, > > unreach=0, hmode=3, pmode=4, hpoll=4, ppoll=4, headway=0, flash=00 ok, > > keyid=0, ttl=0, offset=0.001, delay=0.000, dispersion=0.233, > > jitter=0.002, > > filtdelay= 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00, > > filtoffset= 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00, > > filtdisp= 0.00 0.24 0.48 0.72 0.96 1.20 1.44 1.68 > > > > ntpq> rl > > associd=0 status=0413 leap_none, sync_uhf_radio, 1 event, spike_detect, > > version="ntpd 4.2.7p397@1.2483-o Sun May 3 05:32:19 UTC 2015 (1)", > > processor="armv7l", system="Linux/4.1.12-v7+", leap=00, stratum=6, > > precision=-19, rootdelay=0.000, rootdisp=733.955, refid=SHM(0), > > reftime=e1005456.debbfb5d Thu, Aug 15 2019 15:59:50.870, > > clock=e100545c.084cd64c Thu, Aug 15 2019 15:59:56.032, peer=10147, tc=4, > > mintc=3, offset=0.000921, frequency=0.047, sys_jitter=310.013202, > > clk_jitter=0.000, clk_wander=0.000 > > The jitter is expressed in units of 1 millisecond, unless I am badly > mistaken; for which possibility I apologize in advance. > Yes, it's reported in milliseconds. The jitter number is the RMS of the differences between the offset from the measurement with the lowest delay for that peer and the other 7 offsets for that peer in the 8-step filter. That is, it finds the lowest delay, then it does, roughly: jitter = 0; for offset in {the other 7 samples that aren't the lowest delay} jitter += SQUARE(offset - lowest_delay_offset) then the final number is jitter = SQRT(jitter / 7) > (as an aside, has editing quotation text gone utterly out of style? > Present company excepted, of course.) > I tend to err on the side of not trimming away too much context when replying, so that people finding the thread from a web search some day will have enough context to interpret the hit they found without having to track down the entire thread and start from the beginning. > regards, > Ross >