[ntp:questions] Help verifying accuracy of NTP server

Weber wsdl at osengr.org
Thu Dec 3 22:54:38 UTC 2015


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<Joachim.Fabini at tuwien.ac.at>:
>>
>> Comments inserted inline below.
>>
>>>>> Am 03.12.2015 um 17:46 schrieb Jan Ceuleers<jan.ceuleers at computer.org>:
>>>> 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: 0x00200000
>>>
>>> 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 at lists.ntp.org
> http://lists.ntp.org/listinfo/questions
>


More information about the questions mailing list