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...@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@lists.ntp.org http://lists.ntp.org/listinfo/questions