E-Mail Sent to this address will be added to the BlackLists wrote: > Martin Burnicki wrote: >>> clients to independently set LI=00 during, say the first >>> half of the month, and to ignore the LI value from >>> servers during that time. > > I think you would have to be more exact than that. > > LI is used for more than one thing. > > <http://www.eecis.udel.edu/~mills/ntp/html/decode.html> > > According to the doc, LI only applies to the current day?
If we are going to discuss this absolutely in detail the even more things need to be taken into account, e.g. where the leap second warnings come from, how long they persist, and how they are passed to NTP. E.g. the GPS satellites usually start to send information about an upcoming leap second about 6 months before the leap second event actually occurs, shortly after the IERS has sent its bulletin C which announces this. The sats don't simply send a warning flag but the exact UTC time *when* this is going to happen. So GPS receivers know about the leap second long before it becomes interesting for NTP. It depends on the GPS receiver at which time it starts to output a leap second warning so ntpd can become aware of it, which protocol is used to pass GPS time to NTP, and if the selected protocol even supports leap second warnings. Correct me if I'm wrong, but as far as I know there is e.g. no NMEA sentence providing a leap second warning before the leap second actually occurs. For operation with NTP it is not sufficient just to send second 60 *during* the leaps second, i.e. when the leap second is already in progress. On the other hand there are string formats supported by the parse river (driver 8) which do support this. The German longwave transmitter DCF77 starts to send out a leap second warning flag only 1 hour before the leap second occurs. This interval may be long enough to provide the leap warning for stratum 1 and eventually stratum 2 servers, but it is probably too short for clients at a lower stratum level if large polling intervals are used, simply because the worst case summary of polling intervals exceeds the announcement interval. If IRIG signals are used for refclocks then things are even worse since most IRIG frame formats don't even support leap second warnings. Only IRIG formats with extension IEEE 1344 or its successor, IEEE C37.118 support this, but the announcement interval is only 1 minute or so, which is definitely to short to pass a leap second warning reliably from an IRIG controlled stratum-1 NTP server down to a chain of secondaries and clients. So in some cases like this a leap second file (which needs to be updated regularly) should at least be a way to get the leap second be handled reliably. On the other hand, if you are using a GPS receiver and a serial string format providing ntpd with a leap second warning early enough, then you don't have to care about leap seconds since the GPS receiver gets the warnings from the satellites, and you don't have to worry if your leap second file is updated regularly. If it comes to NTP then you should always mention the version of NTP you are talking about since the behaviour of leap second handling has changed across versions, e.g. - when ntpd starts to accept a leap warning - from which sources it accepts a leap warning under which conditions: from a single upstream server (earlier NTP versions) or only from a majority (current NTP versions), from refclocks, from a leap second file, and which priorities come into effect if there are upstream servers *and* one or more refclocks *and* a leap second file, or another combination of those. - which plausibilty checks ntpd does to avoid erraneaous leap second warnings: earlier NTP versions inserted a leapsecond only at the end of June or the end of December, but supported also leap second deletions which could occur in theory and can also be warned about by GPS, while current versions of ntpd accept leap second warning for the end of *any* month, but (as far as I know) don't support leap second deletion anymore at all. Of course, all of the above is valid only in the absence of firmware bugs or NTP bugs which can mess up everything. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
