On 12/30/2011 4:02 PM, Tomi Lehto wrote:
Nickolay Orekhov<[email protected]> wrote:
1. If you mark clocks as "true" you somehow fool yourself :-). Because now
if the clocks are real falsetickers you won't even know about it and your
system
will be out of sync and for ex. will show low offset from some falseticker
maybe.
Yes, reading about the "true" option I got the impression that it is "wrong"
way to deal with this. I removed them form the clocks and added tos mindist
with large enough value, now it is set to 0.400 (I don't know if that is
insanely large for the purpose...)
2. NTPD can choose 2 of 3 clock sources but he can't choose 1 of 2 clocks.
So you have to combine NMEA and PPS in one source
or add another ntp server for selection algorithm to work.
With this system the only clock sources will be the local clock and gps, so
no other ntp servers are available. I guess I could try adding 127.0.0.1
as one server?
3. When starting ntpd will at first STEP time to some clock source. I can
suppose It will be NMEA. But later ntpd will choose
PPS because of low jitter and spike detection algorithm can take place. It
will wait for 15 minutes and then make another STEP. To skip this
15 minutes, set time1 to real value.
OK, I watched the system and ntpd seems to pick up PPS either within the
first minute, or after ~15 or 16 minutes from ntpd startup. The NMEA source
is selected pretty quickly and ntpq -p shows small offset for NMEA from
the start (samples are 20 seconds apart):
remote refid st t when poll reach delay offset jitter
==============================================================================
*GPS_NMEA(0) .GPS. 10 l 10 16 377 0.000 0.032 2.680
PPS(0) .PPS. 0 l - 16 0 0.000 0.000 0.000
remote refid st t when poll reach delay offset jitter
==============================================================================
*GPS_NMEA(0) .GPS. 10 l 14 16 377 0.000 0.029 2.117
PPS(0) .PPS. 0 l - 16 0 0.000 0.000 0.000
remote refid st t when poll reach delay offset jitter
==============================================================================
*GPS_NMEA(0) .GPS. 10 l 2 16 377 0.000 0.032 1.059
PPS(0) .PPS. 0 l - 16 0 0.000 0.000 0.000
remote refid st t when poll reach delay offset jitter
and after about 15 minutes the PPS is selected.
remote refid st t when poll reach delay offset jitter
==============================================================================
*GPS_NMEA(0) .GPS. 10 l 14 16 377 0.000 3.266 3.055
PPS(0) .PPS. 0 l - 16 0 0.000 0.000 0.000
remote refid st t when poll reach delay offset jitter
==============================================================================
*GPS_NMEA(0) .GPS. 10 l 2 16 377 0.000 11.005 6.203
oPPS(0) .PPS. 0 l 1 16 3 0.000 -340.79 1.406
remote refid st t when poll reach delay offset jitter
==============================================================================
*GPS_NMEA(0) .GPS. 10 l 6 16 377 0.000 6.842 3.767
oPPS(0) .PPS. 0 l 5 16 7 0.000 -343.03 3.024
remote refid st t when poll reach delay offset jitter
==============================================================================
*GPS_NMEA(0) .GPS. 10 l 10 16 377 0.000 4.044 4.705
oPPS(0) .PPS. 0 l 9 16 17 0.000 -344.79 4.006
remote refid st t when poll reach delay offset jitter
==============================================================================
*GPS_NMEA(0) .GPS. 10 l 14 16 377 0.000 -0.024 7.511
oPPS(0) .PPS. 0 l 13 16 37 0.000 -346.15 4.634
remote refid st t when poll reach delay offset jitter
If I understand correctly ntpd adjusts the system clock slowly instead of
quickly setting it to desired time. But how quickly I can expect it to adjust
the system clock if it is within couple of hundred msec from "real" time and
ntpd has got NMEA and PPS available?
NTPD can and will "jump" the clock if the error is greater than some
small value; I don't recall the exact value.
A properly configured NTPD should not need manual correction unless the
circumstances are really extreme!
That's just a wild guess.
To be more specific, please, could you post your full config first of all,
and then ntpq output
of commands such as "pe", "rv", "cv" and so on short after restart and then
after about half an hour? I think there's some problem in configs. C
I will post output from ntpq commands next year! :)
ntp.conf looks like this:
(I set NMEA time1 to 0.200 to see if the PPS offset would be smaller when
ntpd picks up the PPS -- so far I didn't see much impovement there)
-----------------
statsdir /tmp/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
enable auth stats monitor
logfile /tmp/ntpd-log
server 127.127.20.0 mode 18 prefer minpoll 4
fudge 127.127.20.0 time1 0.200
fudge 127.127.20.0 stratum 10
server 127.127.22.0 minpoll 4
fudge 127.127.22.0 flag3 0 flag2 0
fudge 127.127.22.0 stratum 0
tos mindist 0.400
driftfile /tmp/ntp.drift
-------------------
Thanks for your help!
Tomi
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
