[ntp:questions] Popcorn on prefer takes out system clock
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:
>>>>>> 22.214.171.124 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
>> Interestingly the same remote server just popcorned again but this time
>> the number was still huge though less than a full overflow:
>> 126.96.36.199 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
>> And another popcorned recently, too, but it was much more sane:
>> 188.8.131.52 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
More information about the questions