From owner-freebsd-arm@freebsd.org Sun Aug 18 21:57:57 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 535D9D285E for ; Sun, 18 Aug 2019 21:57:57 +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 46BWBs11XZz41rB for ; Sun, 18 Aug 2019 21:57:56 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1566165475; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=aPFaiVp7G7IIcgWkAhpdgTlo7gt+j0XcCLx9QCEl4yNtMjFtZA1dPyB0CR7b1X1i+j35uFBb1gaSU ZNrrr183+kBE/J8PBCAcdVx+306I4dmCcmJqhohQkIRowXzgC6hbYJdtLjmHf37s+ItVsgUZj8WbPP AwLKclmEp6rGcH8oeaGT044ClH2UXjyHvI/NEmnAjc9NbklQBHV1NUKawhF2zoyBmAVmSEwvtAMay/ A8mJxijOj7faylQxYTNUX+a/X039h/0KejVXz6Qkbr3T34I78UKumEcJ9UUHl5OaHAZ1vMk+onIjxw F5JMar4Kzv0B1K/lrtK0i/hhN+OdFvg== 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=S5ZzNmDn1vy3IDDRu1dxPXW2p74atwavG0VeogbSHls=; b=MJrNzEn153OuUIke0jHh11mcLSWDhw4pmZ3BuXaCMYTT2+WoRjY83krsNuhKsbCMDpHc/1HLtOq03 0Y/O8WE2JgkqF0dpivh3B8mW3k7DMlJAYMsJ6Loy5kgGzPgCvKxBGotWEDLr0pRXYxRUBlxtM7i2t0 XXU0F33inxECh3ZnS2gzU3LKXIcFoSLsslJNLpmIa9CLeAhXKE8CRnUazLDsMszteA96Bpbbi5rdeG evo0eRLP1gsWVZZn7T8cAAv62YgMMuu3FdEqqvXDyRlDvnx5iN2JbA26Hgv2nSHQF/u3DCBJvfmpzc pceKQEZXhEXq1ur//qsjOTlpKL1GqBQ== 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=S5ZzNmDn1vy3IDDRu1dxPXW2p74atwavG0VeogbSHls=; b=sB8YVV/sWmmN1Fyg30cjC+hxy/bZVQjLBDebJA0p9K3Fz4+3lwFvRliw5p3EjaZx4IN6897Sr6Xm6 ihhVNw6WuLQCY869bbHx0xae91aUBEMzUrNdGYgY12L4d3iegvT5arafrO63qvfY/W1XLhbeb+BFbf 4US7X5Abt/0AOSDjS3ULjLmtm2mVcxbS0EOsgEJKgTkCzs+2FeNwBuif97qZezkFUGjMJUnpLswV+c 8yvZx1/zFH8okyc9loErJYlYmnYSudH8p36flRUO49Vg03sHcOMPMBfo9gl2dbmxAiFOUWr6JnpY7N 1UrM/4FRIw7yCmsWx6Yf1WRU3/1oZxA== X-MHO-RoutePath: aGlwcGll X-MHO-User: 3a3bde78-c203-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 3a3bde78-c203-11e9-b67b-cdd75d6ce7a8; Sun, 18 Aug 2019 21:57:54 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x7ILvqsZ073138; Sun, 18 Aug 2019 15:57:52 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: 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, Hans Petter Selasky Date: Sun, 18 Aug 2019 15:57:52 -0600 In-Reply-To: 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> <24b0eaf25b64d6098b390df092866c69e352d859.camel@freebsd.org> <16c91be1-6f2a-b26d-22c7-be8e4ba8eec0@hedeland.org> <72a964c78cbfc36be2345919633ca2196f0783e3.camel@freebsd.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: 46BWBs11XZz41rB 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: Sun, 18 Aug 2019 21:57:57 -0000 On Sun, 2019-08-18 at 22:53 +0200, Per Hedeland wrote: > > > > I probably should have been clearer that I meant there was no > > correlation between the kernel clock and the usb polling on the system > > I was using as a testbed. On most SoCs, and probably even modern x86 > > systems, the same frequency source (typically a 24MHz crystal) will be > > the root clock for both the usb controller hardware and the timer > > hardware from which the kernel clock is derived. However, the kernel > > clock is numerically steered to be more stable in frequency and > > accurate in phase, so once ntpd has been running for long enough to > > capture and disipline the kernel clock, the situation will change. The > > usb polling will still be happening at the drifting frequency of the > > underlying crystal, while the kernel timestamps used to mark the PPS > > pulse time will not be drifting at that rate. > > Understood. What I don't understand is if, and if so how, your > "replacing" the kernel clock with an "exact" frequency from your 10 > MHz clock might affect the USB polling. I don't think there is any connection at all. As I vaguely understand it, the usb ehci driver sets up lists of transfers to be done in memory and hands the ehci hardware a pointer to that list, and the hardware executes everything based on its own internal timers (which are ultimately sourced from the 24mhz clock). It's not like the OS has to periodically wake up and tell the ehci hardware "now is the time to do some polling". > > I think there is some confusion around the concept of usb 1.x devices > > on a usb 2.0 bus. I think there may even be some confusion when a 1.x > > bus is involved. And then adding to the confusion is the likelyhood > > that different usb-serial adapters use different usb transfer types > > (bulk vs interrupt)_to communicate line-state changes. > > > > A usb 1.x bus is divided into 1ms frames. A 2.0 bus is divided into > > 125us (micro-)frames. For interrupt endpoints, a usb 1.x bus limits > > devices to 1 interrupt transfer per frame, and that may imply that > > there is up to 1ms of latency for reporting a DCD change on such a 1.x > > bus. A 2.0 bus allows up to 3 interrupt transfers per microframe, > > implying latency of up to 125us. > > > > However, there is no limit on either 1.x or 2.0 busses for how many > > bulk transfers can happen to a given endpoint during a frame. The > > controller needs to fill a frame with transactions in a way that first > > provides all the g'teed bandwidth that is promised to control, > > interrupt, and isochronous transfers. It is then free to fill all the > > remaining time with bulk transfers. > > > > To me, this implies that you may end up with nearly no latency (and > > negligible jitter) if you have a usb 2.0 bus that has just one or two > > devices on it which are communicating via bulk-transfer endpoints. The > > controller would be continuously sending BULK IN tokens to the one or > > two devices, so that as soon as one of them has data, it gets an > > opportunity to deliver it almost immediately (meaning within a few > > microseconds). > > > > The results I see with FTDI usb-serial adapters which use bulk > > transfers provide some evidence that my theory may be correct. I think > > the bus looks like this: > > > > BULK IN token to usb 1.x device (do you have anything to say?) > > 1.x device NAKs > > BULK IN token to usb 2.0 device > > 2.0 device NAKs > > > > BULK IN token to usb 1.x device > > 1.x device NAKs > > ... (repeat forever) > > > > In other words, the device(s) aren't getting 1 chance per frame to > > transfer data, they are getting many thousands of chances per second. > > I think the bus overhead of the BULK-IN token followed by a NAK from > > the device, along with the various framing bits and crc and all that > > probably adds up to less than 64 bytes per poll. But assuming it took > > as much as 64 bytes to do that, if there was one usb-serial device on a > > usb 2.0 bus, it would be getting asked about 1 million times per second > > whether it had anything to say. > > This is extremely interesting - if it really is the case that the > will poll "as fast as it can", as opposed to always doing it with a > fixed frequency, it would definitely change the picture. Unfortunately > I haven't seen any documentation to support that this is the case. > > I'd welcome input from low-level USB gurus about the bus and controller > > behavior in this regard. > > I'm afraid we have lost freebsd-usb@ in this sub-thread (it was actually > the case before my first comment, but it would probably have happened > anyway, since I'm not subscribed to that list). Unless you know that > "low-level USB gurus" are also subscribed to freebsd-arm@, it might make > sense to forward your message to freebsd-usb@. I think HPS reads the arm@ list, but I'll cc him directly on this reply, just in case he has time to weigh in on this stuff. -- Ian