I believe the issue is arising from the understanding of "what" is being interrupted.
When a UART or GPIO is triggering an interrupt - for the UART it's a FIFO notice that data is available to be pulled out, for the GPIO it's notification of a state change (and optionally, a specific state change: high-low/low-high). When a USB PHY trips an interrupt it's to indicate that carrier data is ready, or for a USB MAC that burst blocks over the link are being decoded. There is an intermediate step between the USB carrier data being received/decoded, and being interpreted by the driver as a specific type of data - and the time that it is made available to the host OS. Because that is handled in the driver, it is subject to all of the other host OS interrupts - so timing is not deterministic for the USB driver. The differences here are key. A 1PPS wired to a GPIO interrupt for the specific pulse edge (rising) will be associated with a very precise correlation to an interrupt vs system tick value. A UART time edge (watching the seconds value increment) will be subject to the rate at which bytes are transferred out of the UART FIFO, then math is done to detect the second transition edge. A USB-to-Serial converter will first encode the bytes and status pin states into a payload compliant with USB trafic standards, transmit that data to a USB Host (PHY/MAC) device, which triggers and interrupt for the driver to decode the data back into meaningful data for the host, then forwards virtual interrupt triggers to the tasks which are watching the states and bytes. Everything on the host-side is subject to system overhead, USB driver optimization, etc. and is thus variable. The host-side backend of the USB transfer is where your variability is coming from IMHO. This is why the recommendation is to use direct (not bridged/adapted) UART+GPIO from most RPi NTP server projects. The timing is most critical to the 1PPS edge, so the most direct correlation possible to a tick value in the OS is the goal. There is nothing saying that the NMEA messages must have such low latency however - in general they merely must arrive in time before the next 1PPS, so USB serial is fine for that traffic. -Tim On Thu, Jul 9, 2020 at 9:00 AM <[email protected]> wrote: > Message: 4 > Date: Wed, 8 Jul 2020 15:02:49 -0500 > From: Steven Sommars <[email protected]> > To: Discussion of precise time and frequency measurement > <[email protected]> > Subject: Re: [time-nuts] Raspberry Pi NTP server > Message-ID: > <CAD4huA65673=wrNAM9dUrqznCWKdc_x=LeYfUsVThj=- > [email protected]> > Content-Type: text/plain; charset="UTF-8" > > My RPi4 (Raspbian Buster) has a GPS+PPS/USB. Serial->USB uses Prolific > PL2303, which supports USB 2.0 > The PPS jitter is 1 msec (e.g., using ppstest). lsusb -v shows: > > Bus 001 Device 008: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial > Port > bInterval 1 > > which means 1 msec polling of the PPS signal. I've been unable to poll > more frequently, that seems to require driver changes. > Petr, what polling rate do you see? Has anyone been able to poll USB @ > 125 ?sec on a stock RPi? > > With the 1 ms polling the PPS reaches the OS between 0 and 1 ms late, in an > unpredictable pattern. Although the PPS jitter is 1 msec, ntpd/chrony on > my RPi4 typically reports low dispersion: 50-150 ?sec. The zero-mean > assumption Achim mentioned is unlikely to be valid. Running chrony + > GPS+PPS/USB I see a ~640?sec offset compared to a GPS+PPS directly > connected to the GPIO pins. That offset will fluctuate, of course. > > Steve Sommars > > > _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
