[ntp:questions] Synchronize distributed PCs with GPS 1 PPS and NTPD for OWD measurements

Joachim Fabini Joachim.Fabini at tuwien.ac.at
Mon Sep 14 06:50:45 UTC 2015


Sandip,

relative synchronization over the wireless link is a mess. I use Linux
desktop systems with GPS/PPS receivers for measuring one-way delay in
mobile setups and it works. Imho any PPS-capable GPS receiver on the
market should satisfy your needs when you integrate it correctly into a
Linux desktop environment. Simplest is to issue a tcpdump on both
computers, store the capture files and later on combine them offline
using a script.

So a short howto:
- plug a RS232 serial PCI card into your PC (do NOT use a serial-to-USB
converter!)
- Choose a GPS/PPS receiver that fits your budget. It might be required
to change voltage levels and/or PPS pulse width. Some time ago I built a
receiver based on an EM-406A, a SparkFun eval board
(https://www.sparkfun.com/products/retired/8334) and the circuit shown
in Fig. 2 of
http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6070154 for PPS
pulse width adaption - total costs around US$50.
- Make sure that the serial cable connects the PPS pin.
- Re-compile your kernel for LinuxPPS support, following the
instructions on http://linuxpps.org/wiki/index.php/LinuxPPS_installation
. I also set the kernel Hz value to 1000Hz, it improved the
responsiveness of the system.
- Re-compile ntpd for supporting the PPS/NMEA clock (Instructions on
http://linuxpps.org/wiki/index.php/LinuxPPS_NTPD_support ) Pay attention
to the port that your serial PCI card uses - typically it should be
ttyS4 and ttyS5 - you must change the ttyS0 occurrences accordingly.
- Install ntpd, adapt your /etc/init.d/ntp and /etc/ntp.conf scripts.

With this setup, even in non-optimum reception conditions any box should
synchronize better than 50µs to UTC, so you get a relative offset of
below than 100µs.

Joachim

On 14.09.2015 00:12, sandip gangakhedkar wrote:
> Thanks Charles S. and Charles E. for your valuable comments.
> 
> Let me clarify that the two nodes *do not* have access to the internet, but
> only to each other, over an unreliable wireless link. So I did not consider
> the option of choosing NTP sync during the measurements.
> 
> Of course, here I am assuming you want to measure the flight times of NTP
>> packets.
> 
> 
> No, I want to measure the flight times of UDP packets which are sent from
> one node to the other over the direct wireless link.
> 
> On a slightly different aspect of your goal, I urge you to pay close
>> attention
>> to Charles Swiger's advice, to wit:    "Heck, if you choose your upstream
>> NTP
>> servers well, you can even get a stratum-2 server without a refclock
>> to maintain ~1ms accuracy, but that depends on having a decent net link
>> also."
> 
> 
> Since I do not have a decent net link, I can safely rule out the option of
> using a nearby Stratum-1 server for either node. I guess I can also safely
> rule out using one node as a reference to the other due to the unreliable
> link between the two.
> 
> My only hope then, if I use a purely NTP-based solution, would be to sync
> one node to a Stratum-1 server and then sync the second node to the first
> one using a direct cable. This would have to be done prior to starting the
> field tests, during which, I have to hope that the relative offset/jitter
> between the two system clocks is below 1ms, which is clearly not a
> certainty.
> 
> Hence the idea of using the two nodes as two Stratum-1 servers.
> 
> I am still not clear what is the best way to solve the problem.
> 
> 
> ~Sandip
> 
> 
> On Sun, Sep 13, 2015 at 2:13 PM, Charles Elliott <elliott.ch at comcast.net>
> wrote:
> 
>>>
>>> The goal is to have a setup for measuring One Way Delay of UDP packets
>>> between two moving nodes, over a long-range wireless network.
>>>
>>
>> I understand that you are trying to measure accurately the packet
>> flight times between two computers over a long-range wireless network.
>> You know, of course, of ntpd's monitoring options, which are described
>> in "monopt.html" which comes with the ntpd distribution in the
>> ...\ntp\doc\HTML folder.  To secure the data you need you can perform
>> a "join" (in the SQL sense) of the rawstats files of the two computers,
>> which will give you the actual send and receive times of the packets,
>> and/or a "join" of the peerstats files, which will give you what NTPD
>> thinks
>>
>> are the delay times.  For the rawstats files, the join can be performed on
>> the packet IP address and the packet times; the send IP address on one
>> computer must match exactly the receive IP address of the other computer,
>> and vice versa.  To make sure the two rawstats files are measuring the same
>> packet, you need to choose the packets with the closest times.  The same is
>> roughly true if you use the peerstats data.  Of course, here I am assuming
>> you want to measure the flight times of NTP packets.  This joining process
>> can be confusing.  I first did it with a spreadsheet, and then once I got
>> the technique straight in my mind, I wrote a short Java program to perform
>> the join automatically, and more consistently correctly than a human can
>> achieve alone.  Parenthetically, I set ntpd's statistics facility to output
>> weekly reports, rather than daily; there is a lot less paper shuffling that
>> way.
>>
>> On a slightly different aspect of your goal, I urge you to pay close
>> attention
>> to Charles Swiger's advice, to wit:    "Heck, if you choose your upstream
>> NTP
>> servers well, you can even get a stratum-2 server without a refclock
>> to maintain ~1ms accuracy, but that depends on having a decent net link
>> also."
>>
>> I am only running three computers at present 192.168.0.1, ... 78, and ...
>> 100.
>> 78 gets its time from five close by stratum 1 servers and two stratum 2
>> servers.
>> I access NTP with a 30 Mbps cable connection.
>> I chose these servers after a several-week period of measuring the delay
>> and
>>
>> jitter of many stratum 1 and 2 NTP servers, and chose the ones with the
>> lowest
>> delay and jitter, and that were consistently selected by ntpd as
>> "true-chimers."
>> 78's average offset (the difference between the best outside clock and its
>> clock)
>> is normally between + and - 0.2 ms, and almost always between +- 0.6 ms.
>> Its
>> measured average jitter is 0.25 ms.  (I will try to send you a copy of its
>> offset
>> v. time graph for 9/2 thru 9/6 so you can see these numbers for yourself.)
>>
>> Much better news is 192.168.0.100's performance; 100 gets its time from 78.
>> 100's
>> offset is normally within +- 50 microseconds (us), and almost always within
>> +- 200 us.
>> 100's average jitter is about 30 us.
>>
>> Based on Swiger's advice and my experience, I urge you to consider setting
>> up
>> two ntpd client/server machines (one remote and one local) to access their
>> time from up to 9 (per each) carefully chosen external sources (or GPS).
>> Then
>> attach a client computer to each of the client/server machines, and measure
>> the
>> packet flight times between the two clients.  The use of the client
>> computers
>> has a smoothing effect of greatly reducing any jitter in your measurements.
>>
>> I believe you can achieve all the accuracy you need this way without the
>> expense of buying and setting up two GPS sources of time.  GPS is great on
>> paper,
>> (and in real life, if you can afford expensive receivers) but unless you
>> have
>> fairly good craftsmanship skills, it can be incredibly difficult (and/or
>> expensive) to get GPS to work well and consistently.
>>
>> Charles Elliott
>>
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions
> 


More information about the questions mailing list