Sandip, relative synchronization over the wireless link is a mess. I use Linux desktop systems with GPS/PPS receivers for measuring one-way delay in mobile setups and it works. Imho any PPS-capable GPS receiver on the market should satisfy your needs when you integrate it correctly into a Linux desktop environment. Simplest is to issue a tcpdump on both computers, store the capture files and later on combine them offline using a script.
So a short howto: - plug a RS232 serial PCI card into your PC (do NOT use a serial-to-USB converter!) - Choose a GPS/PPS receiver that fits your budget. It might be required to change voltage levels and/or PPS pulse width. Some time ago I built a receiver based on an EM-406A, a SparkFun eval board (https://www.sparkfun.com/products/retired/8334) and the circuit shown in Fig. 2 of http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6070154 for PPS pulse width adaption - total costs around US$50. - Make sure that the serial cable connects the PPS pin. - Re-compile your kernel for LinuxPPS support, following the instructions on http://linuxpps.org/wiki/index.php/LinuxPPS_installation . I also set the kernel Hz value to 1000Hz, it improved the responsiveness of the system. - Re-compile ntpd for supporting the PPS/NMEA clock (Instructions on http://linuxpps.org/wiki/index.php/LinuxPPS_NTPD_support ) Pay attention to the port that your serial PCI card uses - typically it should be ttyS4 and ttyS5 - you must change the ttyS0 occurrences accordingly. - Install ntpd, adapt your /etc/init.d/ntp and /etc/ntp.conf scripts. With this setup, even in non-optimum reception conditions any box should synchronize better than 50µs to UTC, so you get a relative offset of below than 100µs. Joachim On 14.09.2015 00:12, sandip gangakhedkar wrote: > 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 > _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
