Re: [ntp:questions] Help verifying accuracy of NTP server

[Jan Ceuleers]

On 02/12/15 21:00, 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.

For what it's worth, this is what my VDSL2 modem is telling me:

Extended Port Status
=
Bme: 1 Port: 1
Downstream line rate: 37792 kbps
Upstream line rate: 4960 kbps
Bearer0 Downstream payload rate: 0 kbps
Bearer1 Downstream payload rate: 30064 kbps
Bearer0 Upstream payload rate: 0 kbps
Bearer1 Upstream payload rate: 4048 kbps
Downstream attainable payload rate: 34368 kbps
Downstream attainable line rate: 46112 kbps
Downstream Training Margin: 9.5 dB
Downstream Line Protection (Bearer1 Path): 3.0 DMT Symbols
Upstream Line Protection (Bearer1 Path): 1.0 DMT Symbols
Near-end ITU Vendor Id: 0xb500494b4e530200
Far-end ITU Vendor Id: 0xb500494b4e530200
Downstream delay: 9.7 ms
Upstream delay: 5.4 ms
Tx total power -7.9 dbm
FE Tx total power 10.8 dbm
VDSL Estimated Loop Length : 1901 ft
G.Hs Estimated Near End Loop Length : 3187 ft
G.Hs Estimated Far End Loop Length :1881 ft
Current framing mode: 0x10
Bandplan Type...: 2
No. of Upstream Bands...: 2
No. of Downstream Bands.: 2
Line Type: 0x0020

So 9.7ms down and 5.4ms up. These account for the coding, interleaving
and transmission delay; they don't yet account for the delay incurred by
the layers above (but this delay should be the same in both directions).

So do these numbers merit being called highly asymmetrical? I suppose
so, but they're also pretty small in comparison with delays deeper in
the network and they don't end up causing appreciable asymmetry in the
end-to-end paths to and from internet-based NTP servers.

Jan
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Help verifying accuracy of NTP server

[Weber]

Thanks for all the info folks. I've been tracking the offsets to several 
GPS-based stratum-1 servers at different places around the US and they 
all show the same offset. This seems like the most likely explanation of 
what's going on.


I see that others have considered mods to allow offsets for individual 
servers in ntpd (applying fudge to a server instead of a clock) but it 
is apparently a significant job and nobody has stepped up to the plate. 
I'd consider helping but I think someone who is familiar with bison is 
required, and that ain't me... :-). I could help out with other parts of 
the task but not with the config changes.


Cheers,


On 12/3/2015 2:14 PM, Joachim Fabini wrote:

One more observation: the reported delay figures suggest that your DL operates 
interleaved while the UL is non-interleaved - same scenario like shown in the 
diagrams but with distinct capacities. Interesting is the fact that (in theory) 
the payload/delay lines for UL and DL will come close but not intersect for 
your setup. For hypothetical 1500 byte frames the payload-caused uplink penalty 
will be about 3ms at 4Mbit/s. The initial offset UL/DL (at 0 bytes) being 
4.3ms, the UL delay for all Ethernet frames (below MTU) will be lower than the 
DL delay of 0-size payload frames.
Joachim


Am 03.12.2015 um 22:10 schrieb Joachim Fabini:

Comments inserted inline below.


Am 03.12.2015 um 17:46 schrieb Jan Ceuleers:

On 02/12/15 21:00, 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.

For what it's worth, this is what my VDSL2 modem is telling me:

Extended Port Status
=
Bme: 1 Port: 1
Downstream line rate: 37792 kbps
Upstream line rate: 4960 kbps
Bearer0 Downstream payload rate: 0 kbps
Bearer1 Downstream payload rate: 30064 kbps
Bearer0 Upstream payload rate: 0 kbps
Bearer1 Upstream payload rate: 4048 kbps
Downstream attainable payload rate: 34368 kbps
Downstream attainable line rate: 46112 kbps
Downstream Training Margin: 9.5 dB
Downstream Line Protection (Bearer1 Path): 3.0 DMT Symbols
Upstream Line Protection (Bearer1 Path): 1.0 DMT Symbols
Near-end ITU Vendor Id: 0xb500494b4e530200
Far-end ITU Vendor Id: 0xb500494b4e530200
Downstream delay: 9.7 ms
Upstream delay: 5.4 ms
Tx total power -7.9 dbm
FE Tx total power 10.8 dbm
VDSL Estimated Loop Length : 1901 ft
G.Hs Estimated Near End Loop Length : 3187 ft
G.Hs Estimated Far End Loop Length :1881 ft
Current framing mode: 0x10
Bandplan Type...: 2
No. of Upstream Bands...: 2
No. of Downstream Bands.: 2
Line Type: 0x0020

So 9.7ms down and 5.4ms up. These account for the coding, interleaving
and transmission delay; they don't yet account for the delay incurred by
the layers above (but this delay should be the same in both directions).

The delay figures need some more detail. I'd guess that what is reported here 
is the initial delay (equivalent to transfer of a packet with payload size 0 at 
link layer). As visible in the diagrams referenced in my previous message, the 
1:10 ratio of UL/DL capacity results in an increase of the gap, i.e., more 
pronounced asymmetry for larger payloads.


So do these numbers merit being called highly asymmetrical? I suppose
so, but they're also pretty small in comparison with delays deeper in
the network and they don't end up causing appreciable asymmetry in the
end-to-end paths to and from internet-based NTP servers.

The difference to queuing delays in symmetric core network links is the 
consistent asymmetry. Whereas NTP algorithms can detect and handle delay 
variations (that in symmetrical links might level out), they are not capable to 
detect consistent delay asymmetry like for VDSL UL/DL.

The initial request asked about possible reasons for a consistent 4 ms offset 
of network-acquired NTP time vs. GPS/PPS sync. Wrt to this order of magnitude, 
I consider the asymmetry of DSL to be substantial and a likely reason for the 
offset. Moreover because both NTP servers show the same offset despite distinct 
delays.
Joachim

___
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

[ntp:questions] Help verifying accuracy of NTP server

[Weber]

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

Re: [ntp:questions] Help verifying accuracy of NTP server

[Joachim Fabini]

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

Re: [ntp:questions] Help verifying accuracy of NTP server

[Weber]

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