[ntp:questions] Popcorn on prefer takes out system clock

unruh unruh at invalid.ca
Wed Mar 7 23:38:00 UTC 2012

On 2012-03-07, A C <agcarver+ntp at acarver.net> wrote:
> On 3/6/2012 20:34, Dave Hart wrote:
>> On Wed, Mar 7, 2012 at 01:32,<Null at blacklist.anitech-systems.invalid>  wrote:
>>> Dave Hart wrote:
>>>> A C<agcarver+ntp at acarver.net>  wrote:
>>>>> 944d 8d popcorn 2147483647.997598 s
>>>> I assume you mean in the local ntpd log on your sparc box
>>>>   referring to the IP address that used to be marked prefer.
>>>> I realize not everyone is a programmer, but the number
>>>>   above jumped out at me as suspiciously round in hex
>>>>   and binary.  Sure enough, round it to whole seconds
>>>>   and you have 2^31 or 0x80000000.  Incredible coincidence?
>>> -0.002402 ?
>> Nope.  NTP's 32:32 l_fp is used for both unsigned timestamps and
>> signed differences between timestamps (intervals or offsets).  In both
>> cases the fractional part is unsigned and positive.  For offsets, the
>> integer part is signed, so -0.002402 would be -1 seconds plus
>> 0.997598, or in hex 0xffffffff.0xf.......  In this case we have an
>> unambiguously positive value 0x7fffffff.0xf....... or just over +68
>> years.
> Interestingly the same remote server just popcorned again but this time 
> the number was still huge though less than a full overflow:
> 901d 8d popcorn 202238.338413 s

Is it delivering a KOD packet? What is that server running? Do you have
peers enabled and can you look at the output of the peers file when that
weird measurement comes in? It would be nice if one could see all four
times in the ntp packet for that situation, to see if it is your machine
or the remote machine that is putting in absurd times into the packet
(or if ntpd is misinterpreting something and causing the problem
itself.) Unfortunately I do not think that there is any debug flag that
can tell ntpd to report all four of those times on a bad packet. (I
suppose you could hack the source to have it do that)

> And another popcorned recently, too, but it was much more sane:
> 933d 8d popcorn 0.039998 s
> So it looks like that one remote server just has problems but nothing 
> wrong with my own system other than it not liking exceptionally large 
> popcorn values from the prefer peer.
> If the ATOM driver would actually run without a prefer and allow the 
> normal clock selection process to choose then this would probably not be 
> an issue.

Well, maybe you want to use gpsd or shmpps to deliver the time from the
pps to the system. They at least has filters to throw away absurd
events, and do not require Preferred peers.


More information about the questions mailing list