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

A C agcarver+ntp at acarver.net
Thu Mar 8 01:47:57 UTC 2012


On 3/7/2012 15:38, unruh wrote:
> 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:
>>>>>> 130.207.165.28 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:
>>
>>
>> 130.207.165.28 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)

No KOD that I can see.  I don't know what version of ntpd it's running 
but I assume it's reasonably up to date.  After the popcorn the peer 
billboard looks the same with no obvious ill effects (of course that 
system was no longer flagged as prefer).

I can probably dig through the peers file to see what it said.  It's in 
there somewhere.

>> And another popcorned recently, too, but it was much more sane:
>>
>> 208.53.158.34 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.

That's what I'm likely going to do, just use something else and avoid 
the popcorn server.

>
>
>
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions
>



More information about the questions mailing list