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

sandip gangakhedkar sandipfloyd at gmail.com
Sun Sep 13 22:12:26 UTC 2015


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
>


More information about the questions mailing list