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-tay...@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.
