Whoops, sent the first reply just to Joachim...here it is for the list:
Joachim,
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
client request
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
standard
ntpd distribution will tolerate the padded request packet.
Not sure, but it looks like that might be the receive() routine in
ntp_proto.c?
Looks like it might consider the padding to be an extension field and
would likely
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.
Joachim
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@lists.ntp.org
http://lists.ntp.org/listinfo/questions
_______________________________________________
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
