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

Charles Elliott elliott.ch at comcast.net
Sun Sep 13 12:13:16 UTC 2015


> 
> 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


More information about the questions mailing list