[ntp:questions] Help verifying accuracy of NTP server
wsdl at osengr.org
Wed Dec 2 23:01:56 UTC 2015
Whoops, sent the first reply just to Joachim...here it is for the list:
Thanks very much. Your paper "M2M Communication Delay Challenges" is a good
read. I'm afraid I don't have the resources available to make some of those
one-way delay measurements.
One idea did occur to me however which may not go anywhere but here it is:
Since the uplink delay is a strong function of packet size, if the
packet were padded with fill bytes to make it larger,
one might be able to "tune-out" the difference in delay. This would
require a modification of ntpd to pad a request packet with extra bytes.
I might be able to hack that here locally, but it would only work if the
ntpd distribution will tolerate the padded request packet.
Not sure, but it looks like that might be the receive() routine in
Looks like it might consider the padding to be an extension field and
toss the padded packet.
Cheers and thanks for the info!
On 12/2/2015 12:00 PM, Joachim Fabini wrote:
> NTP algorithms rely on symmetric connection delay but DSL delay is
> commonly highly asymmetrical. In measurements for my setup (VDSL;
> 8Mbit/s DL, 768kbit/s UL), the VDSL one-way delay at low packet payload
> averages 12ms for DL and 6ms for UL. Very surprising if you consider the
> DL/UL capacity ratio of larger than 10:1. Reason is activated
> interleaving on DL; you can use the diagrams on slide 3 of
> https://irtf.org/raim-2015-slides/fman/fabini.pdf as guidance and find
> some related text in the referenced paper.
> The specific DL/UL one-way delay depends on your specific VDSL UL/DL
> line capacity and configuration, as well as on the NTP packet size
> (please note the distinct y axis ranges on the two referenced diagrams).
> But the offset you've reported matches the order of magnitude of VDSL
> line asymmetry that I've measured.
> Without detailed measurements you can't be sure. But based on your data
> and my measurement results, my best guess is that the offset you're
> seeing can be (and most likely is) caused by VDSL delay asymmetry.
> On 02.12.2015 01:06, Weber wrote:
>> I could use some advice about verifying the performance of a home-built
>> stratum-1 NTP server.
>> The server is based on an HP55300A reference clock. The PPS signal and
>> time-of-day serial port are connected to an Arduino Mega with an
>> Ethernet shield and some miscellaneous interface circuitry. The Mega
>> tracks time from the PPS signal generally within +-500ns by using
>> internal timers, and a software-based PLL controlling a software-based
>> fractional-N divider. There are hardware timestamps on incoming NTP
>> requests. Transmit timestamps are not hardware generated but as best I
>> can figure, are accurate to 10us worst case and probably just a couple
>> of us in reality.
>> At least I ***think*** that's how accurate this thing is. In an attempt
>> at independent verification, I've been running ntpd 4.8.2 on a Win7 PC.
>> It is configured to use the Arduino NTP server (which is on the same
>> network hub as the PC). Also configured are three internet stratum-1
>> servers over a DSL connection (one is ACTS, the other two are GPS ref
>> clocks). Polling between 16 and 32 seconds on each. The PC's loop stats
>> look fine -- it tracks within 500us typically and jitter is around 300us
>> or so.
>> Offset data in peerstats shows the two stratum-1 GPS servers have a -4ms
>> time offset relative to the Arduino server. Pretty much exactly the same
>> offset in fact. Peerstats shows a very stable delay to these two servers
>> -- 30ms on one and 65ms for the other. This data was taken over a
>> 12-hour period.
>> So, here's my question: If the Arduino NTP server is accurate to better
>> than 100us, is it believable that these two internet servers would show
>> almost the same exact -4ms offset? Is this something to do with DSL? Or
>> should I be digging into the Arduino server looking for bugs? Does
>> anyone have suggestions for other experiments?
>> I've left out lots of details to keep the message shorter. I'll be glad
>> to provide more info.
>> Thanks in advance if anyone can help out.
>> questions mailing list
>> questions at lists.ntp.org
> questions mailing list
> questions at lists.ntp.org
More information about the questions