Last week I tested the ping between computers on the same local network and found that the round trip time of a packet inconsistently ranged between 3.4 ms to 588 ms. Typically, packets sent within the same local network should be less than 10 ms, but for some unknown reason the latency in our network is an order of magnitude greater. As a fallback plan, I wanted to use NTP to synchronize the system clocks of the computers in the network and base our timestamps and synchronization on each computer’s local clock instead.
While NTP itself reported the estimated time difference between the local clock and the time server it synchronizes to, this value may not be accurate because of the inconsistent delays in our network.
My strategy for measuring the discrepancy between the local clocks was to configure each computer to send a signal when their respective clocks reached a predefined timestamp. Then using an oscilloscope, I would compare the time difference between the two signals.
We had an oscilloscope in the form of a NI myDAQ in the lab, but no way of easily connecting it so that the computer could send a signal for it to measure. Instead, I took the feather modules we already had on hand and configured them as a relay that would interpret a serial message from the computer and output signal on one of its digital I/O pins that could be measured by the myDAQ.
However, I noted that adding the Feather modules could introduce its own timing inconsistency into the measurements. I needed to make sure that the delay added by the Feather modules was consistent enough or at least within the margin of error for the measurements that we wanted to make.
As a test, I had the Feather modules programmed to echo a message it receives over serial to measure the round trip time. I repeated this measurement 1000 times at irregular intervals between 0 to 1 second for a total of approximately 8 minutes.
Mean: 0.336 ms
StDev: 0.184 ms
Max: 4.489 ms
Min: 0.114 ms
Mean: 1.785 ms
StDev: 6.759 ms
Max: 49.089 ms
Min: 0.237 ms
Mean: 1.670 ms
StDev: 6.554 ms
Max: 48.594 ms
Min: 0.298 ms
While there was a difference between my computer and the compute sticks, the distribution was well within the margin of error (10 ms). When run on the compute sticks, there were several outliers in the 10's of milliseconds, but since these are relatively rare (~5-7) per 1000 trials, I can compensate in the accuracy test later with more trials.
Finally, we get to the accuracy tests which gave me different results depending on how I configured NTP.
When NTP was set to synchronize against a computer on the local network, the discrepancy ranged from approximately -30ms to 30ms.
When NTP was configured to use Google’s NTP server at 216.239.35.0, the discpreancy was almost immeasurable by the myDAQ (approximately 0 or 1.2 ms difference, but this may be due to my cursor placement). This result was consistently reproduced over 30 different trials.
My intuition was that synchronizing to a computer on the local network should yield better results since there are fewer network hops that could introduce uncertainty to the round trip time that NTP uses to correct for the delay and synchronize the local clock. On the other hand, I should have expected this result because our local network had previously went against my expectation that sending a packet to a computer on the same network would be faster than sending one to a server on the internet.
Regardless of why our local network has this behavior, this test shows that relying on local clocks synchronzied with NTP in reference to Google's time server provides more than enough accuracy for our purposes.