Re: [gpsd-dev] ntpshmmon

[Gary E. Miller]

Yo Nuno!

That looks good to me.  Or at least ntpshmmon is doing the right thing.
ntpshmmon is showing exactly what is in the SHMs.

That is a bug in gpsd.  I've seen a few other reports of it.

The root problem is gpsd is double sending the NMEA tix time.  That
got unhinged in the not too distant past.  You need to chase down why
the gpsd is not locking out the second time.

On Tue, 14 Jun 2016 10:52:31 +0100
Nuno Gonçalves <address@hidden> wrote:

> On Tue, Jun 14, 2016 at 7:57 AM, Gary E. Miller <address@hidden>
> wrote:
> > Yo Nuno!
> >
> > I am not seeing the symptom you describe.  What is different about
> > yout setup?  Maybe you can provide samples of the bad output.  
> 
> I think this have already been discussed on this thread and confirmed
> by you. Anyway, current HEAD:
> 
> $ ntpshmmon
> ntpshmmon version 1
> #      Name   Seen@                Clock                Real
>     L Prec
> sample NTP0 1465896597.099572315 1465896596.127321084
> 1465896596.000000000 0  -1 sample NTP0 1465896597.599910826
> 1465896597.131568720 1465896597.000000000 0  -1 sample NTP0
> 1465896598.100108190 1465896597.131568720 1465896597.000000000 0  -1
> sample NTP0 1465896598.600334941 1465896598.129354454
> 1465896598.000000000 0  -1 sample NTP0 1465896599.101255248
> 1465896598.129354454 1465896598.000000000 0  -1 sample NTP0
> 1465896599.601668135 1465896599.114003660 1465896599.000000000 0  -1
> 
> $ntpshmmon -c 5
> ntpshmmon version 1
> #      Name   Seen@                Clock                Real
>     L Prec
> sample NTP0 1465896618.041483335 1465896617.131087169
> 1465896617.000000000 0  -1 sample NTP0 1465896620.545864791
> 1465896620.137888563 1465896620.000000000 0  -1 sample NTP0
> 1465896623.046377775 1465896622.103522734 1465896622.000000000 0  -1
> sample NTP0 1465896625.547381610 1465896625.101492958
> 1465896625.000000000 0  -1 sample NTP0 1465896628.051179741
> 1465896627.137969769 1465896627.000000000 0  -1
> 
> The first prints about 2 samples per second (duplicates) and the
> second prints about 0,4 samples per second.
> 
> > You are removing very important code comments.  
> 
> The comments were about a specification that is not implemented at
> all. If they are important they are as a TODO, but as so they are also
> a ambiguous specification. They only consider NTPD case, and don't
> account for all the other clock discipline variances, but more
> importantly they recognize a problem but don't say what is more
> desirable: to oversample or undersample, since it is no possible/cheap
> to exact sample.
> 
> I can on the other hand add comments about my implementation and it's
> shortcomings if you think that is desirable.
> 
> I can also list all the possible cases and where it undersamples and
> oversamples...but... If users were happy with the code as it is, it's
> because they don't really care about this.
> 
> Also a downside of my code it doesn't print the messages in realtime,
> it can have a latency of up to <cycle> seconds for printing it. That
> is because it was activating before at 1KHz and I've reduced it to a
> period of <cycle>.
> 
> Once again...there is no clear specification of what is
> required/expected, so I think this is the simpler and cheaper code to
> do the job.
> 
> And for last, for my use I only really care about the default case (-c
> 1), and the default case is solved just by fixing the clear bug,
> change tvc to tvr at the following two lines:
> 
> >diff = timespec_diff_ns(shm_stat.tvc, tick[i]);
> >tick[i] = shm_stat.tvc;  
> 
> Thanks!
> Nuno
> 




RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

pgpSYU_KeUg2C.pgp
Description: OpenPGP digital signature