[ntp:questions] Score is low and not raising

Derek Barnes derek at barnesmob.nz
Thu Jun 10 02:16:34 UTC 2021


I am not so sure your reasoning is correct here, Martin.

Even though the "bandwidth" is greater in one direction, that only 
affects the "speed" of packet transfer when the link is reaching its 
maximum capacity.
With low traffic, packets go at the same % of the speed of light in both 
directions.

For example, if roadworkers close half the lanes of a freeway at 2am, a 
single driver can still drive at the same speed as the night before; but 
at 9am, there will be a traffic jam and everyone has to slow down.

Google  "speed of data when bandwidth is different"
=============================================================================

On 10/06/2021 3:02 am, Martin Burnicki wrote:
> lvzwlcykh5uctsy5.t.hadvabvobs at antichef.net wrote:
>> Hello,
>>
>> Am Wed, Jun 09, 2021 at 02:23:20PM +0200 schrieb Martin Burnicki - 
>> martin.burnicki at burnicki.net:
>>>
>>> That sounds like a systematic time offset due to an asymmetric internet
>>> connection, where the download link has more bandwidth than the upload 
> link.
>>>
>>> See, for example, here:
>>> https://kb.meinbergglobal.com/kb/time_sync/time_synchronization_errors_caused_by_network_asymmetries 
>>>
>>>
>>
>> I had exactly the same thought. I pondered this in the newsgroup, 
>> also mentioning that it would have been easy enough for me to monitor 
>> this for 
> a while anf then apply a fudge in ntpd to compensate for the offset. 
> The governing opinion in the NG however was that they would prefer 
> believing in the PPS signal ignoring the offset. Since I use a proper, 
> designated serial port for the PPS it is probably as good as it gets.
>>
>> Plus: if it were latency then correcting or not for the -3 ms would 
>> be just cosmetics - since ntp is disciplined by PPS (which, as the 
>> verdict was, is fine), the other servers with -3 ms offset would not 
>> be used anyway. The big question for me was if I could believe my 4 
>> Euro ublox pinger. 
> "Ignore the others" is not really a proof.
>>
>> It is true, I am on a houshold DSL line with big out-of-balance between 
> upland and download speeds. However, when I did a few - probably 
> rather naive - sums I came to the conclusion that the -3 ms is too 
> much to be explained with asymetry alone. Your article that you were 
> friendly enough to share explains the fundamental dilema nicely, but 
> doens't further substantiate the 5 ms that are mentioned there. And it 
> also mentions the central question: we can't really tell if the ublox 
> is right.
>
> I even think the problem is a little more difficult.
>
> If you internal NTP server is accurately synchronized using a 1 PPS 
> signal:
>
> - All other devices on your the internal network can get precise time 
> from it, because usually there is no asymmetry in your local subnet.
>
> - Devices on the outside that you are monitoring seem to have a time 
> offset.
>
> - For devices on the internet that monitor *your* NTP server, it looks 
> like *your* server has a time offset, in the same range, but with 
> inverted sign.
>
> If you fudge your internal server so that there doesn't seem to be an 
> offset, compared to the servers on the internet:
>
> - The time of *your* internal server is off by the number of 
> milliseconds you observed
>
> - Other devices on your local network get an inaccurate time if they 
> synchronize to your server.
>
>
> The only proper solution that comes to my mind is to be able to 
> configure time compensation values depending on IP address ranges, 
> e.g. 0 ms for the IP address range of your local subnet, and 3 ms as 
> default for all other IP addresses that are connected via the router 
> to the outside world.
>
> However, an NTP daemon needs to support such kind of configuration. 
> I've proposed this on the NTP news group (comp.protocols.time.ntp) 
> many years ago, but as far as I know, this has never been implemented.
>
>
> Martin
>
>
>
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions



More information about the questions mailing list