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