Re: Is it a good idea to use a usb-serial adapter for PPS input? Yes, it is.
On Mon, Sep 09, 2019 at 05:20:25PM +0930, O'Connor, Daniel wrote: > > > > On 8 Sep 2019, at 23:12, Konstantin Belousov wrote: > >> 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. > > I am a bit worried (based on your commit log for r303383) that the code now > relies on it being 2 for correct function, although given I increased it to > 10 and this system works fine perhaps not :) > It means that the sliding window where consumer should reach the writer to read the current timehands is larger. I think that in reality the cases where the latency of get*time*(9) KPI increased are very rare. Still the question is why your system have the negative impact from reducing the number of timehands. Interrupt should never interrupt tc_windup() because it is protected by spinlock. Silly question, are spinlocks functional on this machine ? > > Please see D21563 'Make timehands count selectable at boottime.' > > Looks good to me, I've installed it on the Beaglebone and it seems to be > running OK so far. > > -- > Daniel O'Connor > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > > ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Is it a good idea to use a usb-serial adapter for PPS input? Yes, it is.
> On 8 Sep 2019, at 23:12, Konstantin Belousov wrote: >> 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. I am a bit worried (based on your commit log for r303383) that the code now relies on it being 2 for correct function, although given I increased it to 10 and this system works fine perhaps not :) > Please see D21563 'Make timehands count selectable at boottime.' Looks good to me, I've installed it on the Beaglebone and it seems to be running OK so far. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Is it a good idea to use a usb-serial adapter for PPS input? Yes, it is.
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 > > dar...@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.1214.52.129.403 u 64 64 370.349 -0.631 > > 0.299 > > o127.127.22.0.PPS.0 l 13 16 3770.0001.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.1214.52.129.403 u 35 64 3770.320 -0.348 0.027 > -203.31.81.2 27.124.125.251 3 u 53 64 377 12.1161.311 1.951 > 0.au.pool.ntp.o .POOL. 16 p- 6400.0000.000 0.004 > 1.au.pool.ntp.o .POOL. 16 p- 6400.0000.000 0.004 > 2.au.pool.ntp.o .POOL. 16 p- 6400.0000.000 0.004 > 3.au.pool.ntp.o .POOL. 16 p- 6400.0000.000 0.004 > o127.127.20.0.GPS.0 l6 16 3770.0000.006 0.004 > +13.239.113.24 .GPS.1 u6 64 377 29.971 -0.054 0.074 > *103.51.68.133 .PPS.1 u 56 64 377 45.0184.821 0.143 > -103.38.120.36 130.95.179.802 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.' ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Is it a good idea to use a usb-serial adapter for PPS input? Yes, it is.
> 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 > dar...@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.1214.52.129.403 u 64 64 370.349 -0.631 0.299 > o127.127.22.0.PPS.0 l 13 16 3770.0001.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.1214.52.129.403 u 35 64 3770.320 -0.348 0.027 -203.31.81.2 27.124.125.251 3 u 53 64 377 12.1161.311 1.951 0.au.pool.ntp.o .POOL. 16 p- 6400.0000.000 0.004 1.au.pool.ntp.o .POOL. 16 p- 6400.0000.000 0.004 2.au.pool.ntp.o .POOL. 16 p- 6400.0000.000 0.004 3.au.pool.ntp.o .POOL. 16 p- 6400.0000.000 0.004 o127.127.20.0.GPS.0 l6 16 3770.0000.006 0.004 +13.239.113.24 .GPS.1 u6 64 377 29.971 -0.054 0.074 *103.51.68.133 .PPS.1 u 56 64 377 45.0184.821 0.143 -103.38.120.36 130.95.179.802 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.. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Is it a good idea to use a usb-serial adapter for PPS input? Yes, it is.
> 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 dar...@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.1214.52.129.403 u 64 64 370.349 -0.631 0.299 o127.127.22.0.PPS.0 l 13 16 3770.0001.000 0.106 It certainly seems happier with the PPS than it was before. Next up would be to use the NMEA coming from the GPS engine for time instead of using the LAN host so it's self contained. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Is it a good idea to use a usb-serial adapter for PPS input? Yes, it is.
On Mon, Aug 19, 2019 at 8:26 AM Ian Lepore wrote:
> On Mon, 2019-08-19 at 17:09 +0930, O'Connor, Daniel wrote:
> > > On 12 Aug 2019, at 09:09, O'Connor, Daniel
> > > wrote:
> > > > always get lost on single-core processors which are in cpu_idle()
> > > > at
> > > > the time the hardclock interrupt happens. (But that's fixable by
> > > > just
> > > > increasing the number of timehands, I think at least 4 are
> > > > required.)
> > >
> > > OK, how do I increase the number of clock hands?
> >
> > I am going to try this diff but buildkernel is going to take a
> > while...
> >
> > diff --git a/sys/kern/kern_tc.c b/sys/kern/kern_tc.c
> > index 2656fb4d2..00440b6a2 100644
> > --- a/sys/kern/kern_tc.c
> > +++ b/sys/kern/kern_tc.c
> > @@ -83,8 +83,48 @@ struct timehands {
> > struct timehands*th_next;
> > };
> >
> > -static struct timehands th0;
> > +static struct timehands th2;
> > static struct timehands th1 = {
> > + .th_next =
> > +};
> > +
> > +static struct timehands th3;
> > +static struct timehands th2 = {
> > + .th_next =
> > +};
> > +
> > +static struct timehands th4;
> > +static struct timehands th3 = {
> > + .th_next =
> > +};
> > +
> > +static struct timehands th5;
> > +static struct timehands th4 = {
> > + .th_next =
> > +};
> > +
> > +static struct timehands th6;
> > +static struct timehands th5 = {
> > + .th_next =
> > +};
> > +
> > +static struct timehands th7;
> > +static struct timehands th6 = {
> > + .th_next =
> > +};
> > +
> > +static struct timehands th8;
> > +static struct timehands th7 = {
> > + .th_next =
> > +};
> > +
> > +static struct timehands th9;
> > +static struct timehands th8 = {
> > + .th_next =
> > +};
> > +
> > +static struct timehands th0;
> > +static struct timehands th9 = {
> > .th_next =
> > };
> > static struct timehands th0 = {
> >
>
> Oh, I'm sorry, I forgot to respond about this. Yeah, that patch would
> do it. I think a minimum of 4 sets of timehands are needed for pps
> capture on a single-core system with a latching timecounter like
> dmtpps.
>
Do we have a good (or even a bad) writeup of how to know that 4 is good, or
when 5 or 6 might be needed?
Warner
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Is it a good idea to use a usb-serial adapter for PPS input? Yes, it is.
On Mon, 2019-08-19 at 17:09 +0930, O'Connor, Daniel wrote:
> > On 12 Aug 2019, at 09:09, O'Connor, Daniel
> > wrote:
> > > always get lost on single-core processors which are in cpu_idle()
> > > at
> > > the time the hardclock interrupt happens. (But that's fixable by
> > > just
> > > increasing the number of timehands, I think at least 4 are
> > > required.)
> >
> > OK, how do I increase the number of clock hands?
>
> I am going to try this diff but buildkernel is going to take a
> while...
>
> diff --git a/sys/kern/kern_tc.c b/sys/kern/kern_tc.c
> index 2656fb4d2..00440b6a2 100644
> --- a/sys/kern/kern_tc.c
> +++ b/sys/kern/kern_tc.c
> @@ -83,8 +83,48 @@ struct timehands {
> struct timehands*th_next;
> };
>
> -static struct timehands th0;
> +static struct timehands th2;
> static struct timehands th1 = {
> + .th_next =
> +};
> +
> +static struct timehands th3;
> +static struct timehands th2 = {
> + .th_next =
> +};
> +
> +static struct timehands th4;
> +static struct timehands th3 = {
> + .th_next =
> +};
> +
> +static struct timehands th5;
> +static struct timehands th4 = {
> + .th_next =
> +};
> +
> +static struct timehands th6;
> +static struct timehands th5 = {
> + .th_next =
> +};
> +
> +static struct timehands th7;
> +static struct timehands th6 = {
> + .th_next =
> +};
> +
> +static struct timehands th8;
> +static struct timehands th7 = {
> + .th_next =
> +};
> +
> +static struct timehands th9;
> +static struct timehands th8 = {
> + .th_next =
> +};
> +
> +static struct timehands th0;
> +static struct timehands th9 = {
> .th_next =
> };
> static struct timehands th0 = {
>
Oh, I'm sorry, I forgot to respond about this. Yeah, that patch would
do it. I think a minimum of 4 sets of timehands are needed for pps
capture on a single-core system with a latching timecounter like
dmtpps.
-- Ian
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Is it a good idea to use a usb-serial adapter for PPS input? Yes, it is.
> On 6 Aug 2019, at 00:12, Ian Lepore wrote: > On Mon, 2019-08-05 at 15:28 +0930, O'Connor, Daniel wrote: >>> 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. >> >> Does the USB clock derive from the 10MHz Rb clock? If so that would mean you >> would see a lot less jitter than a 'normal' user where the USB clock is not >> locked too GPS. >> > > No, usb is derived from the same 24mhz crystal that clocks the cpus. I > think usb and its need for clocks at 48 and 480mhz is why so many small > arm systems use a 24mhz main clock. OK, I thought when you used the external clock it was being used to derive the USB clock (eg via a PLL) hence the jitter would be low - if not that is even better. >> Do you have a more detailed write up of things like the NTP configuration >> file? I think I could replicate your test here although I have a Beaglebone >> Black, not a Wanboard so I will need to check if it can take an external >> clock. (We have GPS modules & Rb oscillators at work to create reference >> clock for bi-static meteor applications). >> > The same setup should be possible on a BBB. There is a TCLKIN pin > mentioned in the manual. Some searching on the web yields a few clues > that it might be possible to mux that to a pin on the P9 header [1]. > There is already a dmtpps capture driver for TI, but I'm afraid it may > have bitrotted over the past couple years. Also, even when it last > worked, it just barely worked, because the reduction of kernel > timecounters from 10 to 2 timehands causes the PPS capture to almost > always get lost on single-core processors which are in cpu_idle() at > the time the hardclock interrupt happens. (But that's fixable by just > increasing the number of timehands, I think at least 4 are required.) OK, how do I increase the number of clock hands? I have am335x_dmtpps setup from last year when I tried this previously :) > So all in all, it's doable, but it'll take a bit of work. I can help > with the driver stuff. > > The ntp config is pretty simple, it uses instances of the "atom" clock, > which is a bare-PPS refclock which needs to be paired with any network > peer to operate. The network peer is used to obtain the initial time > of day, then the PPS signal is used to steer phase. The network peer > must be marked 'prefer' for some reason, it's just an ntp rule. In my > test setup I forced ntp to steer to the "perfect" pps signal by marking > all the others as "noselect", otherwise any of the atom clocks would be > eligible to be the system peer. Thanks. My current setup uses gpsd but I think that is complicating things unnecessarily so I'll try it without that and see if I can get it working. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Is it a good idea to use a usb-serial adapter for PPS input? Yes, it is.
On Mon, 2019-08-05 at 15:28 +0930, O'Connor, Daniel wrote: > Hi Ian, > > Firstly, this is a very cool test - thank you for running it :) > > > On 3 Aug 2019, at 06:46, Ian Lepore wrote: > > PPS(2) is an FTDI 232R, a USB 1.1 serial adapter, connected to a port > > on a USB 2.0 hub that's connected to a USB 2.0 host port on the > > Wandboard. > > > > PPS(3) is an FTDI 4232H, a USB 2.0 serial adapter, connected to a port > > on the same USB hub as PPS(2). > > > > > 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. > > Does the USB clock derive from the 10MHz Rb clock? If so that would mean you > would see a lot less jitter than a 'normal' user where the USB clock is not > locked too GPS. > No, usb is derived from the same 24mhz crystal that clocks the cpus. I think usb and its need for clocks at 48 and 480mhz is why so many small arm systems use a 24mhz main clock. > Do you have a more detailed write up of things like the NTP configuration > file? I think I could replicate your test here although I have a Beaglebone > Black, not a Wanboard so I will need to check if it can take an external > clock. (We have GPS modules & Rb oscillators at work to create reference > clock for bi-static meteor applications). > The same setup should be possible on a BBB. There is a TCLKIN pin mentioned in the manual. Some searching on the web yields a few clues that it might be possible to mux that to a pin on the P9 header [1]. There is already a dmtpps capture driver for TI, but I'm afraid it may have bitrotted over the past couple years. Also, even when it last worked, it just barely worked, because the reduction of kernel timecounters from 10 to 2 timehands causes the PPS capture to almost always get lost on single-core processors which are in cpu_idle() at the time the hardclock interrupt happens. (But that's fixable by just increasing the number of timehands, I think at least 4 are required.) So all in all, it's doable, but it'll take a bit of work. I can help with the driver stuff. The ntp config is pretty simple, it uses instances of the "atom" clock, which is a bare-PPS refclock which needs to be paired with any network peer to operate. The network peer is used to obtain the initial time of day, then the PPS signal is used to steer phase. The network peer must be marked 'prefer' for some reason, it's just an ntp rule. In my test setup I forced ntp to steer to the "perfect" pps signal by marking all the others as "noselect", otherwise any of the atom clocks would be eligible to be the system peer. server iburst prefer server 127.127.22.0 minpoll 4 maxpoll 4 fudge 127.127.22.0 stratum 0 refid gpt server 127.127.22.1 minpoll 4 maxpoll 4 noselect fudge 127.127.22.1 stratum 0 refid gpio server 127.127.22.2 minpoll 4 maxpoll 4 noselect fudge 127.127.22.2 stratum 0 refid usb1 server 127.127.22.3 minpoll 4 maxpoll 4 noselect fudge 127.127.22.3 stratum 0 refid usb2 [1] http://e2e.ti.com/support/processors/f/791/t/406121?AM335x-TCLKIN-on-Linux-3-19 -- Ian ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Is it a good idea to use a usb-serial adapter for PPS input? Yes, it is.
Hi Ian, Firstly, this is a very cool test - thank you for running it :) > On 3 Aug 2019, at 06:46, Ian Lepore wrote: > PPS(2) is an FTDI 232R, a USB 1.1 serial adapter, connected to a port > on a USB 2.0 hub that's connected to a USB 2.0 host port on the > Wandboard. > > PPS(3) is an FTDI 4232H, a USB 2.0 serial adapter, connected to a port > on the same USB hub as PPS(2). > 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. Does the USB clock derive from the 10MHz Rb clock? If so that would mean you would see a lot less jitter than a 'normal' user where the USB clock is not locked too GPS. Do you have a more detailed write up of things like the NTP configuration file? I think I could replicate your test here although I have a Beaglebone Black, not a Wanboard so I will need to check if it can take an external clock. (We have GPS modules & Rb oscillators at work to create reference clock for bi-static meteor applications). Thanks again. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Is it a good idea to use a usb-serial adapter for PPS input? Yes, it is.
Since we added support for accepting a PPS signal on a USB-serial adapter a couple years ago, I've seen people express reluctance to use it several times. Usually they cite concerns about latency and jitter. I decided it was time to do some rigorous testing, and post the results. Complete details on the test setup appear below. The tl;dr summary is: A single PPS source is fanned out to 4 different types of inputs on a Wandboard system (armv7, imx6 SoC). Ntpd is configured to steer only to PPS(0), and the offset and jitter numbers for the other sources allow comparing the various PPS processing paths. After running about 12 hours, the results are: remote refid st t when poll reach delay offset jitter = oPPS(0) .gpt. 0 l8 16 3770.0000.000 0.002 PPS(1) .gpio. 0 l7 16 3770.000 -0.002 0.002 PPS(2) .usb1. 0 l6 16 3770.000 -0.201 0.034 PPS(3) .usb2. 0 l5 16 3770.000 -0.215 0.026 *tflex.my.lan.GPS. 1 u 32 64 3770.5680.038 0.061 PPS(0) is fed to a hardware timer block within the imx6 SoC. The PPS pulse triggers hardware capture of the kernel clock, eliminating latency and jitter due to interrupt processing. PPS(1) is fed to a generic gpio input pin on the SoC, handled by the standard gpiopps driver processing a pin-change interrupt. PPS(2) is an FTDI 232R, a USB 1.1 serial adapter, connected to a port on a USB 2.0 hub that's connected to a USB 2.0 host port on the Wandboard. PPS(3) is an FTDI 4232H, a USB 2.0 serial adapter, connected to a port on the same USB hub as PPS(2). Unfortunately, the uart driver for the imx6 SoC doesn't support the CTS or CD signals, so I couldn't measure native uart performance directly. I would expect the performance to be comparable to the gpio pin input. As shown above, there is a 2 microsecond latency and virtually no jitter on the GPIO input. The USB 1.1 and USB 2.0 adapters performed essentially identically to each other, with about 200 microseconds of latency and negligible jitter. There was no difference in performance between using the CTS versus the CD pins on the adapters for input. To see if lots of USB bus activity increased latency or noise, I connected a USB SATA dock containing an SSD drive to the same USB hub as the serial adapters, and ran a continuous dd(1) from the drive to /dev/null. Surprisingly, there was absolutely no difference in the results during that run. 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. Test setup details... PPS measurements are made using the kernel clock. Typically the kernel clock is sourced from a hardware clock which isn't particularly accurate in terms of frequency. All clocks drift; cheap crystals on computer boards drift a lot. Ntpd will align both the frequency and phase of the kernel clock using a PPS signal, but to compare the various processing paths a PPS signal can go through, you must be able to determine how much error came from the reference path and how much from the path being tested. In an ideal world, there would be no measurement jitter, or frequency drift in the kernel clock, and thus all PPS measurements made would be directly comparable to each other without having to ascribe any part of the differences between sources to the kernel clock. I am able to configure a Wandboard imx6 system so that the frequency and phase alignment of kernel time is "perfect" with respect to one of the PPS inputs. Since all the PPS inputs are sourced by fanning out the same source PPS signal, any difference in the offset or jitter reported by ntpd directly represents differences in the processing paths taken by those signals. The test setup consists of a commercial precision timing system which generates a 10 MHz clock signal from a GPS-disciplined rubidium oscillator, and it generates a PPS pulse that is derived from that 10 MHz clock using a simple "divide by 10 million" counter. So the leading edge of the PPS pulse is phase-coherent with the leading edge of one of the clock pulses. The 10 MHz clock signal is fed to an external clock input pin on the imx6 SoC. Within the imx6 timer block, that clock signal drives a 32- bit counter register, and that counter is used to implement a kernel timecounter. The PPS signal is also fed into that imx6 timer block, and the leading edge of the PPS pulse causes the hardware to latch the current value of the 32-bit timecounter into a capture register. This captured value is then used to generate a PPS measurement that doesn't incorporate any interrupt processing latency or jitter. Because the PPS pulse and the
