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.hadvabv...@antichef.net wrote:
Hello,
Am Wed, Jun 09, 2021 at 02:23:20PM +0200 schrieb Martin Burnicki -
martin.burni...@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@lists.ntp.org
http://lists.ntp.org/listinfo/questions
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
