There is good article to read
http://cs.stackexchange.com/questions/103/clock-synchronization-in-a-network-with-asymmetric-delays
Probably NTPD uses a weighting schema when processing the measurements.
However, beyond a certain level of delay the measurements are likely to
be so corrupted as to be useless.
On 2016-10-11 13:09, Thomas Valerio wrote:
I was going to post my ntp output and ask for an opinion, then this
discussion popped up. It would appear that asymmetric delays are the
exact explanation for what I am seeing. Is that a reasonable
assumption?
It does seem to be rather consistent throughout the day, however. The
reason for checking against the net when I have a GPS source is that I
want ntp to continue if/when there is no PPS. Is there any way to
inform
ntp of the asymmetry?
Thanks,
-- Thomas Valerio
Every 20.0s: /usr/sbin/ntpq -n -c pe pe Tue Oct 11
12:37:33
2016
remote refid st t when poll reach delay offset
jitter
==============================================================================
x127.127.28.0 .NMEA. 0 l 4 16 377 0.000 -30.300
36.009
*127.127.28.1 .PPS. 0 l 3 16 377 0.000 0.001
0.000
-208.53.158.34 216.93.242.12 3 u 9 64 377 17.202 2.907
0.188
+208.100.4.52 216.86.146.46 2 u 64 64 377 16.612 2.332
0.193
+208.69.120.241 142.66.101.13 2 u 5 64 377 24.258 1.688
0.223
-128.118.25.3 130.207.244.240 2 u 53 64 377 40.429 4.956
2.577
Hi
NTP can *not* detect âcommon modeâ asymmetric delay. Having
a local
GPS does not count in this respect. What does count is an NTP client /
server sitting in your home trying to figure out what time it is only
by hooking to the internet.
To do this it must do a few things:
1) Get a signal out through the (slow / long lag) upload channel on
your
modem.
2) Route that signal through the cable guyâs low capacity
upstream
network to
one of his (at best) two or three gateways to your local empire.
These may
or may not be in the same state you live in.
3) Fly the signal over the backbone to whatever server is involved.
4) Fly a signal back over the backbone to possibly another set of
gateways.
5) Route that signal through the cable guyâs high capacity
downstream
network.
6) Run it through the (quite fast / low lag) downstream channel on
your
modem.
Steps 1,2,5 and 6 are common to every single server you try to access.
If your
modem has an âupstreamâ lag of (say) 101 ms and a
âdownstreamâ lag
of (say) 1 ms, every server you contact will have a round trip time of
at
least 102 ms. They *may* have more than this, but none will ever have
less.
As the day progresses and various groups pop on and off the system in
your state,
the usage of the upstream and downstream channels changes. It is not
unreasonable
to guess that both change as a percentage. If that guess is correct,
your upstream
varies by significantly more than your downstream. That will get into
NTPâs loop
correction stuff as well.
You *might* ask, how about pings? Well, you *might* look into it and
find that
your local cable system recognizes pings at a very low level and
preferentially
routes them. Yes, thatâs hogwash and nobody would ever do it
â¦.. except
thatâs the way it works here with my internet. The network can be
completely
dead and pings (along with other ICMP traffic) will get through.
Hmmmâ¦..
You are indeed a guy with 5 watches to check against. The gotcha is
that
every
single one of them has been set fast or slow by the same amount.
Bob
On Oct 6, 2016, at 11:03 AM, Chris Albertson
<albertson.ch...@gmail.com>
wrote:
I still think NTP can detect asymmetric delays. Only it can't know
that
is
what it is detecting. What else generate those offset numbers?
Yes
it
could very well be that MRS is running slow but I doubt that is the
case.
And I really doubt your GPS' PPS is off by even one microsecond.
A
good
bet is that ALL the results we see is because the real-world
communication
path is different from the assumption NTP makes about communications
paths.
In practice what NTP sees is all due to the Internet and not so much
the
reference clocks. Your data shows this. 162.23.41.10 .MRS has
different
stat depending on who is looking at it. So those billboards are
showing
network stats not server stats. (but NTP can't know that for certain
so
it
is obliged to call them server stats)
This is 2016. Almost any reference clock you are likely to use will
be
pretty much dead-on, at least to within the precision that NTP works
with.
So anything those billboards say is really about the communications
paths.
But NTP has no theoretical right to assume the cause of what it sees.
Theory and practice differs, In theory NTP can not detect
asymmetric
delay but in practice that is about all it detects Maybe I should
say
NTP
detects asymmetric delay just like the speedometer in my car deters
engine
failure.
All that said, if the OP is still reading this it should be very good
news
for him because your data shows that NTP can give him his required
accuracy
even without a GPS if he has an Internet connection as good as yours
In fact what you are showing is that NTP using the Internet can beat
GPS
over USB to Winows. and can certainly beat any software the "jam
sets"
the
clock. All you need is your Internet connection, no aded hardware.
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
--
WBW,
V.P.
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
