Eugen COCA wrote:
Due to a network problem on our provider, the packets were routed on a
Duplicate thread.
different path than usual yesterday, for several hours. This period,
NTP displayed wrong offsets:
+GPS_NMEA(1) .GPS.0 l 16 16 3770.000
0.001 0.002
ptbtime1.p
In article <51c20190-11b8-4629-a762-cbf95369e...@r18g2000vbs.googlegroups.com>,
Eugen COCA writes:
>Due to a network problem on our provider, the packets were routed on a
>different path than usual yesterday, for several hours. This period,
>NTP displayed wrong offsets:
ntpd assumes the network
Due to a network problem on our provider, the packets were routed on a
different path than usual yesterday, for several hours. This period,
NTP displayed wrong offsets:
+GPS_NMEA(1) .GPS.0 l 16 16 3770.000
0.001 0.002
ptbtime1.ptb.de .PTB.1 u4 64 377
Eugen COCA wrote:
One may observe the delays were also affected during this interval.
Also, the time information served to clients was affected, the
pool.ntp.org monitoring system confirmed the delay -
http://www.pool.ntp.org/scores/80.96.120.252. It is obvious that a
server synchronizing only w
Eugen COCA wrote:
-0.073 0.028
ntp1.oma.be .PPS.1 u 184 256 377 48.966
Note the high offset sources are being rejected, however, unless you
have your local sources marked as prefer, the large number of low
quality sources does introduce a risk that your high quality s
Due to a network problem on our provider, the packets were routed on a
different path than usual yesterday, for several hours. This period,
NTP displayed wrong offsets:
+GPS_NMEA(1) .GPS.0 l 16 16 3770.000
0.001 0.002
ptbtime1.ptb.de .PTB.1 u4 64 377
