[time-nuts] ``direct'' RS-232 vs. RS-232 via USB vs. PPS decoding cards

Bob Camp kb8tq at n1k.org
Sat Feb 18 12:13:23 EST 2017


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 at 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 at 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 at blueyonder.co.uk
>>> Twitter: @gm8arv
>>> _______________________________________________
>>> time-nuts mailing list -- time-nuts at 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 at 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 at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.



More information about the time-nuts mailing list