[ntp:hackers] NTP Release Candidate 4.2.8p1-RC1 Released

juergen perlinger juergen.perlinger at t-online.de
Tue Jan 27 19:11:17 UTC 2015

On 01/27/2015 04:51 AM, Gary E. Miller wrote:
> Yo Hal!
> On Mon, 26 Jan 2015 19:39:13 -0800
> Hal Murray <hmurray at megapathdsl.net> wrote:
>> gem at rellim.com said:
>>> robin ntp # fgrep 127.127.46 /var/log/ntp/*
>>> /var/log/ntp/clockstats:57049 10837.938 good=0
>>> badtime=0 baddate=0   badreply=0   recv=0
>> ...
>> The recv=0 says it's not getting anything.
> Yeah.
>>> Any idea why I get clk_fault?
>> That's probably the general not-working/timeout sort of thing.

Yes. A clock that does not deliver anything at all in a poll cycle can 
claim either timeout or fault.  I choose timeout for not getting any 
TPV/PPS records, and fault if the driver cannot establish a working 
socket connection. (That is, the '?VERSION' / '?WATCH=...' stanzas do 
not get a reply that can be recognized.)

> The maintainer should add some better debug info...

I'm getting mixed messages on that topic, but suggestions welcome. 
There's some tension between those who want logging as debugging aid 
(and that means verbose logging) and those who want just the essential 
stuff so the logs are not cluttered. Since there are enough unused mode 
bits, we can have some configurable verbosity

>> Try a netstat -t as another quick sanity check.  (just to make sure
>> the connection is there)
> Nope, no connection. Netcat works, so the gpsd side is fine.
>> What does it look like from the gpsd end?
> Looks like gpsd gave a few nice TPV and PPS's and then the client just
> went away:
> gpsd:CLIENT: => client(0): {"class":"TPV","device":"/dev/gps0","mode":3,"time":"2
> 015-01-27T03:47:27.000Z","ept":0.005,"lat":44.068980006,"lon":-121.314280935,"alt
> ":1147.655,"epx":7.573,"epy":9.171,"epv":26.910,"track":23.3489,"speed":0.060,"cl
> imb":0.001,"eps":1.58,"epc":53.82}\x0d\x0a
> gpsd:IO: UBX: len 26
> gpsd:DATA: NAVDOP: gdop=1.57 pdop=0.79 hdop=1.17 vdop=1.41 tdop=0.67 mask={DOP}
> gpsd:DATA: packet type 11 from /dev/gps0 with {ONLINE|DOP|PACKET}
> gpsd:PROG: Changed mask: {ONLINE|DOP|PACKET} with reliable cycle detection
> gpsd:IO: UBX: len 24
> gpsd:DATA: TIMEGPS: time=1422330447.00 mask={TIME}
> gpsd:DATA: packet type 11 from /dev/gps0 with {ONLINE|TIME|PACKET|PPSTIME}
> gpsd:PROG: Changed mask: {ONLINE|TIME|PACKET|PPSTIME} with reliable cycle detecti
> on
> gpsd:PROG: PPS edge: 0, cycle: 1000026 uSec, duration:  899991 uSec @ 1422330448.
> 003932511
> gpsd:CLIENT: => client(0): {"class":"PPS","device":"/dev/gps0","real_sec":1422330
> 448, "real_nsec":0,"clock_sec":1422330448,"clock_nsec":3932511}\x0d\x0a
> gpsd:INFO: PPS hooks called with accepted 1422330448.003932511 offset -0.00393251
> 1
> gpsd:PROG: PPS edge accepted 1422330448.003932511 offset -0.003932511
> gpsd:PROG: checking client(0)
> gpsd:INFO: detaching ::1 (sub 0, fd 6) in detach_client
> gpsd:WARN: select() bug found, sleeping for 326956 usec
> Full log attached.
> Most odd to see the "select bug found"???

AFAIK the poll/epoll API is the preferred one under Linux. Maybe the 
'select()' API does not interact so well with threaded code? Just a wild 
guess, though.

I really wish I could offer better help here -- it's just I did never 
observe things like that, and they simply don't happen with my equipment:

  - Linux 3.16.0-29-generic #39-Ubuntu SMP Mon Dec 15 22:27:29 UTC 2014 
x86_64 x86_64 x86_64 GNU/Linux
  - AMD Phenom IV 9550 (2.2GHz)
  - Garmin GPS18x LVC
  - gpsd: 3.11 (revision 3.11)

As I said, any hints welcome -- but bugs I cannot reproduce are really 
hard to fix from my side alone. I'll need at least a partner who can 
validate whether the bug is gone or not. Plus a good idea what's 
actually going wrong!


   Juergen 'Pearly' Perlinger

More information about the hackers mailing list