[EMAIL PROTECTED] (Nicola Berndt) writes: >Unruh schrieb: >> [EMAIL PROTECTED] (Nicola Berndt) writes: >> >>>>> remote refid st t when poll reach delay offset >>>>> jitter >>>>> ============================================================================== >>>>> GPS_NMEA(0) .GPS. 0 l 9 64 37 0.000 -580.75 >>>>> 3965.19 >>>> You've not had your first 8 samples yet. You haven't actually had >>>> enough for ntpd to act on the data. You can speed that up with iburst, >>>> but ntpd will still take a long time to get a very tight lock. jitter >>>> will reduce as you get to the eight samples. The good? think, is that >>>> you are more than 128ms out, so that ntpd will step the time, to zero >>>> the offset, once it gets enough samples. >> >> >>> Just tried the iburst option, but I had to figure it only works with the >>> server command, not on refclocks. >> >> Oops forgot you have a gps clock. chrony does not work with refclocks. >> >> >>> What really puzzles me, is the stoical 600 ms offset after rebooting. >>> Since it is always returning having more or less the same amount, I >>> should really be able to get rid of it, no? >> >> It sounds like your rtc has problems. You can use hwclock to compensate for >> rtc problems.
>Well, I tried 'hwclock --systohc' with no different result. More >suggestions? Try using the --directisa option both when you write the rtc on shutdown and when you read it on bootup. If you have a very modermn machine with HPET the rtc driver is badly munged. It should only be out by about 13ms, not 600 however. Also look at the /etc/adjtime file >[EMAIL PROTECTED] >tel: +49 30 / 6730 1395 >fax: +49 30 / 6730 1394 >gsm: +49 163 / 243 6802 >________________________________ _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
