``direct'' RS-232 vs. RS-232 via USB vs. PPS decoding cards
Hi
On Feb 18, 2017, at 4:53 AM, David J Taylor david-taylor@blueyonder.co.uk wrote:
Hi,
I was wondering whether there is some data/information available on the
claimed +/- 100 ns jitter?
I guess the previous was not complete enough.
I routinely measure PPS jitter on GPS modules down well below 10 ns on a 53131.
That’s after sawtooth correction is applied. Without sawtooth correction, the +/- 24
or +/- 12 or +/- 1.25 ns of the sawtooth adds into that.
The reference used is an HP 5071 with a high performance tube option.
Bob
Regarding the PPS -> USB (using the CTS line of a FTDI FT232R), I
plotted, using some lines of Python, the time offset as attached. Just
to get an overview how it is 'worst case', i.e., user program, python,
etc. The 1PPS signal comes from a GPS rx.
Looks like a standard deviation of around 150 us.
y-axis: measured pps offset from full second (computer time) in us,
x-axis pps pulse number.
On the long term it looks interesting (while measuring I played with the
NTP server on this computer)
Until ca. second 10000: ntpd synchronization via internet
Until ca. second 17000: made an additional LAN NTP server (GPS) available
Until the end: replaced ntpd with chrony (still using internet and local
servers)
Interesting points:
-It looks surprisingly bad with using the normal ntpd (especially, there
is not really an improvement having an local GPS based server
available, did I do something wrong? Only the offset changes by ca. 3
ms.)
-It looks surprisingly good with chrony. But there are continuously
outliers of up to 4500 us, is this a result of the chrony control loop?
The time is wandering around with ntpd, but has less jitter.
Conclusion:
Despite the 150 us stddev, the using PPS over USB gives some interesting
inside of what the local ntp server is actually doing. It looks to me
like it would be an improvement to use it when using ntpd, but not when
using chrony.
Best regards,
Thomas
DK6KD
SA6CID
PS:
Raw data is here, if you want to zoom in: (1.7 MiB, one row per PPS
offset in us)
http://petig.eu/pps-usb.txt
---================
Thomas,
I've done some tests with PPS over USB with Windows some time back, which showed that PPS?USB could be better than LAN-sync alone, but that also included a reduction of the poll interval from possibly 64 seconds for LAN sync to 16 seconds for PPS sync, which may have influenced the results.
<pet-peeve>It would be helpful to have some units on the axes - 10000 what? I'm guessing microseconds....</pet-peeve>
For comparison, here is a Raspberry Pi running NTP, with the reported offset plotted against time.
http://www.satsignal.eu/mrtg/raspi14_ntp_3.html
This Raspberry Pi (running a seismic detector) is using an Ethernet connection via Power-line Ethernet (yes, I know, QRM etc. etc.), and a couple of switches to a very good stratum-1 server. I would estimate from your graph that the jitter in offset is about 1 millisecond peak-to-peak, but it seems that I get less than that - perhaps 100 microseconds peak-to-peak with occasional excursions outside that. This is with the latest reference version of NTP.
remote refid st t when poll reach delay offset jitter
---============
*192.168.0.20 .GPS. 1 u 17 32 377 12.351 0.000 0.428
+192.168.0.11 .uPPS. 1 u 2 32 377 12.432 -0.106 0.824
-192.168.0.3 .kPPS. 1 u 13 32 377 21.366 -4.524 0.804
+192.168.0.83 .kPPS. 1 u 27 32 377 21.614 -4.511 1.206
uk.pool.ntp.org .POOL. 16 p - 64 0 0.000 0.000 0.001
-193.150.34.2 133.150.251.233 3 u 38 64 137 32.343 2.738 1.477
-80.87.128.17 94.125.129.7 3 u 30 64 375 53.337 -1.225 1.516
-192.146.137.13 82.148.230.254 2 u 56 64 377 46.089 2.220 2.535
-129.250.35.250 249.224.99.213 2 u 169 64 214 42.499 -3.015 12.507
-213.130.44.252 145.238.203.14 2 u 487 64 200 37.210 -0.725 13.232
73,
David GM8ARV
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Hi Bob,
On Sat, Feb 18, 2017 at 08:36:51AM -0500, Bob Camp wrote:
Hi
On Feb 18, 2017, at 4:53 AM, David J Taylor david-taylor@blueyonder.co.uk wrote:
Hi,
I was wondering whether there is some data/information available on the
claimed +/- 100 ns jitter?
I guess the previous was not complete enough.
I routinely measure PPS jitter on GPS modules down well below 10 ns on a 53131.
That’s after sawtooth correction is applied. Without sawtooth correction, the +/- 24
or +/- 12 or +/- 1.25 ns of the sawtooth adds into that.
The reference used is an HP 5071 with a high performance tube option.
I agree, in this setup we get this performance. I also agree that using
timers in capture mode on microprocessors will give this performance, as
you wrote before.
But as we where discussing the performance between capturing some PPS
via PCIe, serial i/o from the chipset, or some USB cable. The reference
clock is here the clock of the CPU, or OS. This clock is of course not
very precise, but the reason for capturing the PPS might be we want to
run some NTP server.
So, I thought actually of the jitter added on the way between our
accurate source (GPS rx), until we can capture our timer. How much can
this be? As far as I see we don't have a capture mode for the HPET. But,
if we have to do it in software, we get more than 100 ns jitter. I just
measured 60-80 ns for a instruction cache miss, with Intels mlc software.
Overall I would guess > 500 ns, are there measurements on this?
This then defines some lower bound of what can be archived for
synchronizing the clock off the OS. Also hardware time stamping on a
dedicated PPS card (or PTP ethernet card) does not help unless the clock
on the card is synchronized to the clock used by the OS.
So, can we do better?
Best regards,
Thomas
DK6KD
SA6CID
Bob
Regarding the PPS -> USB (using the CTS line of a FTDI FT232R), I
plotted, using some lines of Python, the time offset as attached. Just
to get an overview how it is 'worst case', i.e., user program, python,
etc. The 1PPS signal comes from a GPS rx.
Looks like a standard deviation of around 150 us.
y-axis: measured pps offset from full second (computer time) in us,
x-axis pps pulse number.
On the long term it looks interesting (while measuring I played with the
NTP server on this computer)
Until ca. second 10000: ntpd synchronization via internet
Until ca. second 17000: made an additional LAN NTP server (GPS) available
Until the end: replaced ntpd with chrony (still using internet and local
servers)
Interesting points:
-It looks surprisingly bad with using the normal ntpd (especially, there
is not really an improvement having an local GPS based server
available, did I do something wrong? Only the offset changes by ca. 3
ms.)
-It looks surprisingly good with chrony. But there are continuously
outliers of up to 4500 us, is this a result of the chrony control loop?
The time is wandering around with ntpd, but has less jitter.
Conclusion:
Despite the 150 us stddev, the using PPS over USB gives some interesting
inside of what the local ntp server is actually doing. It looks to me
like it would be an improvement to use it when using ntpd, but not when
using chrony.
Best regards,
Thomas
DK6KD
SA6CID
PS:
Raw data is here, if you want to zoom in: (1.7 MiB, one row per PPS
offset in us)
http://petig.eu/pps-usb.txt
---================
Thomas,
I've done some tests with PPS over USB with Windows some time back, which showed that PPS?USB could be better than LAN-sync alone, but that also included a reduction of the poll interval from possibly 64 seconds for LAN sync to 16 seconds for PPS sync, which may have influenced the results.
<pet-peeve>It would be helpful to have some units on the axes - 10000 what? I'm guessing microseconds....</pet-peeve>
For comparison, here is a Raspberry Pi running NTP, with the reported offset plotted against time.
http://www.satsignal.eu/mrtg/raspi14_ntp_3.html
This Raspberry Pi (running a seismic detector) is using an Ethernet connection via Power-line Ethernet (yes, I know, QRM etc. etc.), and a couple of switches to a very good stratum-1 server. I would estimate from your graph that the jitter in offset is about 1 millisecond peak-to-peak, but it seems that I get less than that - perhaps 100 microseconds peak-to-peak with occasional excursions outside that. This is with the latest reference version of NTP.
remote refid st t when poll reach delay offset jitter
---============
*192.168.0.20 .GPS. 1 u 17 32 377 12.351 0.000 0.428
+192.168.0.11 .uPPS. 1 u 2 32 377 12.432 -0.106 0.824
-192.168.0.3 .kPPS. 1 u 13 32 377 21.366 -4.524 0.804
+192.168.0.83 .kPPS. 1 u 27 32 377 21.614 -4.511 1.206
uk.pool.ntp.org .POOL. 16 p - 64 0 0.000 0.000 0.001
-193.150.34.2 133.150.251.233 3 u 38 64 137 32.343 2.738 1.477
-80.87.128.17 94.125.129.7 3 u 30 64 375 53.337 -1.225 1.516
-192.146.137.13 82.148.230.254 2 u 56 64 377 46.089 2.220 2.535
-129.250.35.250 249.224.99.213 2 u 169 64 214 42.499 -3.015 12.507
-213.130.44.252 145.238.203.14 2 u 487 64 200 37.210 -0.725 13.232
73,
David GM8ARV
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Hi
The point is that some chip sets have better access to timer / counters than others do.
One of the Soekris (sp?) boards is an example of this. We also are moving into an era where
fairly fancy ARM CPU’s are grafted onto FPGA’s. Once you have that, you are no longer
dependent on somebody else to brew up the peripheral you need.
Bob
On Feb 18, 2017, at 10:45 AM, Thomas Petig thomas@petig.eu wrote:
Hi Bob,
On Sat, Feb 18, 2017 at 08:36:51AM -0500, Bob Camp wrote:
Hi
On Feb 18, 2017, at 4:53 AM, David J Taylor david-taylor@blueyonder.co.uk wrote:
Hi,
I was wondering whether there is some data/information available on the
claimed +/- 100 ns jitter?
I guess the previous was not complete enough.
I routinely measure PPS jitter on GPS modules down well below 10 ns on a 53131.
That’s after sawtooth correction is applied. Without sawtooth correction, the +/- 24
or +/- 12 or +/- 1.25 ns of the sawtooth adds into that.
The reference used is an HP 5071 with a high performance tube option.
I agree, in this setup we get this performance. I also agree that using
timers in capture mode on microprocessors will give this performance, as
you wrote before.
But as we where discussing the performance between capturing some PPS
via PCIe, serial i/o from the chipset, or some USB cable. The reference
clock is here the clock of the CPU, or OS. This clock is of course not
very precise, but the reason for capturing the PPS might be we want to
run some NTP server.
So, I thought actually of the jitter added on the way between our
accurate source (GPS rx), until we can capture our timer. How much can
this be? As far as I see we don't have a capture mode for the HPET. But,
if we have to do it in software, we get more than 100 ns jitter. I just
measured 60-80 ns for a instruction cache miss, with Intels mlc software.
Overall I would guess > 500 ns, are there measurements on this?
This then defines some lower bound of what can be archived for
synchronizing the clock off the OS. Also hardware time stamping on a
dedicated PPS card (or PTP ethernet card) does not help unless the clock
on the card is synchronized to the clock used by the OS.
So, can we do better?
Best regards,
Thomas
DK6KD
SA6CID
Bob
Regarding the PPS -> USB (using the CTS line of a FTDI FT232R), I
plotted, using some lines of Python, the time offset as attached. Just
to get an overview how it is 'worst case', i.e., user program, python,
etc. The 1PPS signal comes from a GPS rx.
Looks like a standard deviation of around 150 us.
y-axis: measured pps offset from full second (computer time) in us,
x-axis pps pulse number.
On the long term it looks interesting (while measuring I played with the
NTP server on this computer)
Until ca. second 10000: ntpd synchronization via internet
Until ca. second 17000: made an additional LAN NTP server (GPS) available
Until the end: replaced ntpd with chrony (still using internet and local
servers)
Interesting points:
-It looks surprisingly bad with using the normal ntpd (especially, there
is not really an improvement having an local GPS based server
available, did I do something wrong? Only the offset changes by ca. 3
ms.)
-It looks surprisingly good with chrony. But there are continuously
outliers of up to 4500 us, is this a result of the chrony control loop?
The time is wandering around with ntpd, but has less jitter.
Conclusion:
Despite the 150 us stddev, the using PPS over USB gives some interesting
inside of what the local ntp server is actually doing. It looks to me
like it would be an improvement to use it when using ntpd, but not when
using chrony.
Best regards,
Thomas
DK6KD
SA6CID
PS:
Raw data is here, if you want to zoom in: (1.7 MiB, one row per PPS
offset in us)
http://petig.eu/pps-usb.txt
---================
Thomas,
I've done some tests with PPS over USB with Windows some time back, which showed that PPS?USB could be better than LAN-sync alone, but that also included a reduction of the poll interval from possibly 64 seconds for LAN sync to 16 seconds for PPS sync, which may have influenced the results.
<pet-peeve>It would be helpful to have some units on the axes - 10000 what? I'm guessing microseconds....</pet-peeve>
For comparison, here is a Raspberry Pi running NTP, with the reported offset plotted against time.
http://www.satsignal.eu/mrtg/raspi14_ntp_3.html
This Raspberry Pi (running a seismic detector) is using an Ethernet connection via Power-line Ethernet (yes, I know, QRM etc. etc.), and a couple of switches to a very good stratum-1 server. I would estimate from your graph that the jitter in offset is about 1 millisecond peak-to-peak, but it seems that I get less than that - perhaps 100 microseconds peak-to-peak with occasional excursions outside that. This is with the latest reference version of NTP.
remote refid st t when poll reach delay offset jitter
---============
*192.168.0.20 .GPS. 1 u 17 32 377 12.351 0.000 0.428
+192.168.0.11 .uPPS. 1 u 2 32 377 12.432 -0.106 0.824
-192.168.0.3 .kPPS. 1 u 13 32 377 21.366 -4.524 0.804
+192.168.0.83 .kPPS. 1 u 27 32 377 21.614 -4.511 1.206
uk.pool.ntp.org .POOL. 16 p - 64 0 0.000 0.000 0.001
-193.150.34.2 133.150.251.233 3 u 38 64 137 32.343 2.738 1.477
-80.87.128.17 94.125.129.7 3 u 30 64 375 53.337 -1.225 1.516
-192.146.137.13 82.148.230.254 2 u 56 64 377 46.089 2.220 2.535
-129.250.35.250 249.224.99.213 2 u 169 64 214 42.499 -3.015 12.507
-213.130.44.252 145.238.203.14 2 u 487 64 200 37.210 -0.725 13.232
73,
David GM8ARV
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
You are plotting "offset". This is simply the communications path
delay. It does not measure your system's deviation from UTC. NTP
takes into consideration the offset.
Here is the way to understand what NTP does with offset. Let's say
we lived 200 years ago and wanted to set a grandfather clock to match
the one in your friend's house and you have no other clocks. Let's
say the friend lives one mile away. .... The best option is to walk
round trips to your friend's house and measure the time and standard
deviation of the round trip time. Divide this time in half and call
it "offset". Then walk to your friend's house, write down the time
and take it home. Set your clock to this time PLUS the offset.
What you care about is the uncertainty of this process NOT the offset
but the standard deviation of the offset.
On Sat, Feb 18, 2017 at 1:53 AM, David J Taylor
david-taylor@blueyonder.co.uk wrote:
Hi,
I was wondering whether there is some data/information available on the
claimed +/- 100 ns jitter?
Regarding the PPS -> USB (using the CTS line of a FTDI FT232R), I
plotted, using some lines of Python, the time offset as attached. Just
to get an overview how it is 'worst case', i.e., user program, python,
etc. The 1PPS signal comes from a GPS rx.
Looks like a standard deviation of around 150 us.
y-axis: measured pps offset from full second (computer time) in us,
x-axis pps pulse number.
On the long term it looks interesting (while measuring I played with the
NTP server on this computer)
Until ca. second 10000: ntpd synchronization via internet
Until ca. second 17000: made an additional LAN NTP server (GPS) available
Until the end: replaced ntpd with chrony (still using internet and local
servers)
Interesting points:
-It looks surprisingly bad with using the normal ntpd (especially, there
is not really an improvement having an local GPS based server
available, did I do something wrong? Only the offset changes by ca. 3
ms.)
-It looks surprisingly good with chrony. But there are continuously
outliers of up to 4500 us, is this a result of the chrony control loop?
The time is wandering around with ntpd, but has less jitter.
Conclusion:
Despite the 150 us stddev, the using PPS over USB gives some interesting
inside of what the local ntp server is actually doing. It looks to me
like it would be an improvement to use it when using ntpd, but not when
using chrony.
Best regards,
Thomas
DK6KD
SA6CID
PS:
Raw data is here, if you want to zoom in: (1.7 MiB, one row per PPS
offset in us)
http://petig.eu/pps-usb.txt
---================
Thomas,
I've done some tests with PPS over USB with Windows some time back, which
showed that PPS?USB could be better than LAN-sync alone, but that also
included a reduction of the poll interval from possibly 64 seconds for LAN
sync to 16 seconds for PPS sync, which may have influenced the results.
<pet-peeve>It would be helpful to have some units on the axes - 10000 what?
I'm guessing microseconds....</pet-peeve>
For comparison, here is a Raspberry Pi running NTP, with the reported offset
plotted against time.
http://www.satsignal.eu/mrtg/raspi14_ntp_3.html
This Raspberry Pi (running a seismic detector) is using an Ethernet
connection via Power-line Ethernet (yes, I know, QRM etc. etc.), and a
couple of switches to a very good stratum-1 server. I would estimate from
your graph that the jitter in offset is about 1 millisecond peak-to-peak,
but it seems that I get less than that - perhaps 100 microseconds
peak-to-peak with occasional excursions outside that. This is with the
latest reference version of NTP.
remote refid st t when poll reach delay offset jitter
---============
*192.168.0.20 .GPS. 1 u 17 32 377 12.351 0.000 0.428
+192.168.0.11 .uPPS. 1 u 2 32 377 12.432 -0.106 0.824
-192.168.0.3 .kPPS. 1 u 13 32 377 21.366 -4.524 0.804
+192.168.0.83 .kPPS. 1 u 27 32 377 21.614 -4.511 1.206
uk.pool.ntp.org .POOL. 16 p - 64 0 0.000 0.000 0.001
-193.150.34.2 133.150.251.233 3 u 38 64 137 32.343 2.738 1.477
-80.87.128.17 94.125.129.7 3 u 30 64 375 53.337 -1.225 1.516
-192.146.137.13 82.148.230.254 2 u 56 64 377 46.089 2.220 2.535
-129.250.35.250 249.224.99.213 2 u 169 64 214 42.499 -3.015
12.507
-213.130.44.252 145.238.203.14 2 u 487 64 200 37.210 -0.725
13.232
73,
David GM8ARV
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
--
Chris Albertson
Redondo Beach, California
From: Chris Albertson
[]
What you care about is the uncertainty of this process NOT the offset but
the standard deviation of the offset.
.. and in the absence of numerical values of the SD, well-scaled graphs of
offset can show the variation in offset quite well.
Cheers,
David
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv
Time transfer over USB can be improved by timestamping on both ends, then
using a robust estimator for the clock offset. For example, imagine the
USB is a small microprocessor peripheral. It has a local timer, freely
incrementing, based on its local clock. When it gets a USB interrupt from
the host, the timer state is read, and the USB message contains the host
timestamp.
This is enough information for a single-shot clock comparison. It may be
contaminated with operating-system latency or any number of other host
latencies (bus, cache, etc.). But generally, with a lightly loaded host,
the USB transaction goes as fast as it possibly can. A plot of the
clock-pair points will show a heavy line with the best-case transfers and a
smattering of latency events. A robust estimator will ignore the chaff.
So I don't see a problem with submicrosecond time transfer over USB. (I
tried this some time back as a quick hack, with a Teensy board.)
Cheers,
Peter
Peter,
Can you convince me your USB time transfer method works?
It seems to me that if the read path and the write path are different it breaks down. Given how USB works, not to mention all the layers of software involved I can't imagine the paths are equal. There's no doubt you can get great consistency from your method. But turning that into precise time requires some kind of calibration of the actual code path delays. In other words, it sounds to me like your method is valid for frequency transfer but not time transfer.
/tvb
----- Original Message -----
From: "Peter Monta" pmonta@gmail.com
To: "Discussion of precise time and frequency measurement" time-nuts@febo.com
Sent: Monday, February 20, 2017 5:46 AM
Subject: Re: [time-nuts] ``direct'' RS-232 vs. RS-232 via USB vs.PPSdecoding cards
Time transfer over USB can be improved by timestamping on both ends, then
using a robust estimator for the clock offset. For example, imagine the
USB is a small microprocessor peripheral. It has a local timer, freely
incrementing, based on its local clock. When it gets a USB interrupt from
the host, the timer state is read, and the USB message contains the host
timestamp.
This is enough information for a single-shot clock comparison. It may be
contaminated with operating-system latency or any number of other host
latencies (bus, cache, etc.). But generally, with a lightly loaded host,
the USB transaction goes as fast as it possibly can. A plot of the
clock-pair points will show a heavy line with the best-case transfers and a
smattering of latency events. A robust estimator will ignore the chaff.
So I don't see a problem with submicrosecond time transfer over USB. (I
tried this some time back as a quick hack, with a Teensy board.)
Cheers,
Peter
Hi Tom,
[ USB time transfer ]
It seems to me that if the read path and the write path are different it
breaks down.
... But turning that into precise time requires some kind of calibration
of the actual code path delays. In other words, it sounds to me like your
method is valid for frequency transfer but not time transfer.
Yes, but I think the same could be said of other I/O mechanisms. Even a
nominally symmetric physical layer, such as Ethernet, becomes a little
asymmetric once the general-purpose CPU, software, drivers, interrupts are
added in to the Tx and Rx paths. Same for PCIe, although those paths are
nearly all hardware.
I'm sure USB is somewhat worse than PCIe. Let me dig up the old code and
try a one-way calibration against a PCIe GPIO signal. The PCIe write
should get out to the wire in 500 ns or so, and the Teensy (or a TIC) can
measure that against the USB event that comes along later. Should allow a
reasonable estimate of the fixed delay (better than measuring the
round-trip total USB transaction time at the CPU and dividing by 2). The
fixed delay will be system-specific, though, requiring a calibration for
each unique hardware platform, unless the USB round-trip time is small
enough to be ignored by the application.
Certainly PCI, or better, a CPU GPIO pin, is vastly preferable to USB; but
USB is very convenient and available. If USB can be coaxed into good
performance, so much the better.
Cheers,
Peter