On 2017-11-05, valizadeh...@gmail.com <valizadeh...@gmail.com> wrote: > On Friday, November 3, 2017 at 1:01:26 AM UTC+3:30, Martin Burnicki wrote: >> valizade...@gmail.com wrote: >> > i have a ntp server based on Raspberry Pi3 with PPS (from u-blox6 ). i >> > have also added a hardware clock to this system. >> > >> > >> > SOME times there is a large offset(3-18 sec) on the SHM (ntp driver 28). >> > i did some experiments and figured out it is related to "leap seconds". >> > when i COLD-RESET the ublox(via USB through u-center) this offset appears >> > on the ntp and both PPS and SHM become false-tickers. >> >> GPS internal system time is off UTC by an integral number of seconds >> corresponding to the number of leap seconds that have been observed >> since 1980. >> >> As Jakob has already pointed out, the satellites send this information >> once every ~12 minutes. >> >> The GPS receiver needs this information to convert the raw GPS time >> received from the satellites to UTC, so it usually store this >> information in its non-volatile memory to have it available right after >> power-up. >> >> However, if you force the GPS receiver into cold boot mode then this >> information gets lost, so the receiver outputs GPS time instead of UTC. >> I'm not sure if the output contains some status that indicates that the >> time sent by the receiver is not UTC. >> >> Anyway, gpsd seems to accept the raw GPS time as UTC time, feeds it to >> ntpd, and ntpd sets the Linux system time off by a number of seconds. >> >> Up to 12 minutes later, after the GPS receiver has seen the UTC >> correction parameters from the satellites, the GPS receiver starts to >> convert GPS time to true UTC, and the time output jumps by a number of >> seconds. >> >> ntpd observes the sudden time step by a number of seconds, but accepts >> it only after it has persisted by a certain interval, by default ~15 >> minutes. So your system time should be stepped to the correct time, but >> only after up to 12 + 15 minutes after power-up. > > yes, you are almost right but "sometimes"(i dont know why!) ntp is not able > to correct the time and as you may see in my first post system time has 2-11 > seconds offset not only after 15 minutes even after 24 hours. i think ntp > does not accept the time from GPS and mark it as false-ticker because its > time has jumped after it has already been recognized a truechimers before > leap-second's effect.
2-11 seconds does NOT seem to have anything to do with leapseconds. You seem to have gps as your ONLY source, except for LOCAL. That means that it should not be a false chimer. As has been emphasised time and again, get rid of your LOCAL time source. It is NOT the hardware clock. It has nothing to do with the hardware clock. It is the system clock itself. Get rid of it. Then gps will be your only source and it can never be a false chimer. Then for testing purposes, put in some ntp network sources so you can test against something. >> >> I think the best solution would be to provide your GPS receiver with a >> backup battery, if the device supports this, to make sure the UTC >> correction parameters don't get lost while the system is powered off. >> > i am thinking of a solution in which ntp update system time after leap second > have been observed by the GPS. > any ideas? And you would know when that occurs how? If the gps receiver (I have no idea what your receiver does) gives a flag saying "I now have UTC time" then you should not be using the time from GPS before that anyway-- ie the receiver should not be used as a source until you are sure it is giving proper time. > _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
