[ntp:questions] NTP+GPS gone haywire

[A C]

I just received all these emails today.  I guess the mail gateway was 
stuck and not sending messages to the group.

Still working on the problem but there was already an issue with my copy 
of libc having a broken dtoa.  Compiling in a workaround.


On 1/30/2012 13:29, E-Mail Sent to this address will be added to the 
BlackLists wrote:
> A C wrote:
>> I finally rebuilt my NetBSD box after having lost the
>>   partition table on the disk.
>> I installed 4.2.7-p236 again and everything seemed fine
>>   all day yesterday.  Suddenly I get this:
>>> $ ntpq -pn
>>>       remote          refid     st t when poll reach delay offset jitter
>>> ========================================================================
>>> x127.127.22.0   .PPS.           0 l   2   16  377  0.000 -244.18 351.567
>>>   127.127.28.0   .GPSD.          0 l  65  128  377  0.000 -131866 2837.34
>>>   74.118.152.85  69.36.224.15    2 u 185  512  377 42.681 -128790 9459.57
>>>   64.16.211.38   142.3.100.15    3 u 328  512  377 86.417 -122725 6592.50
>>>   173.244.211.10 131.107.13.100  2 u 196  512  377 55.746 -123465 6503.82
>>>   130.207.165.28 130.207.244.240 2 u 114  512  377 78.525 -131743 11757.9
>>>   131.144.4.10   130.207.244.240 2 u 488  512  377 87.644 -129888 11647.1
>>
>> This happened sometime late last night
>>   (I'll have to look at the peer and loop files to see when).
>> No cron jobs fired off during this period,
>>   they had already run yesterday afternoon.
>> Before this I had offsets for the remote servers in the
>>   few milliseconds range and an offset on the PPS signal of
>>   only a couple microseconds.
>>
>> Anyone have any ideas?
>> Note that the GPSD refclock is set as "noselect" currently.
>> I'm trying to test the static navigation feature of the GPS
>>   to see if the time offsets calm down on that.
>> PPS is supplied by the kernel itself.
>
> I noticed something similar, and mentioned in in
>   <http://bugs.ntp.org/show_bug.cgi?id=1798>
>
> So far have been unable to cause it to happen for troubleshooting,
>   and IIRC, I've only seen it occur one other time
>   (on a different but similar system).
>
>
> {I ran across it while duplicating some ntpq mrv issues}
> <http://bugs.ntp.org/show_bug.cgi?id=1799>
> <http://bugs.ntp.org/show_bug.cgi?id=1801>
>