[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