Re: [gpsd-dev] ntpshmmon

[Nuno Gonçalves]

Hi,

Thanks. This works fine for me. Just a question: the usleep value is a
tradeoff between activation frequency and print latency. Since this is
a monitoring tool, do we need to activate it a 1KHz? I wouldn't see a
problem of runing it at 10Hz or even 1Hz. For the user it doesn't
really matter if the results are printed with 100ms or 1s delay...

What are the weird data you are looking? Cycle misses? Delays above a
threshold? Delays that are statistically inconsistent?

Thanks,
Nuno

On Thu, Jun 16, 2016 at 3:12 AM, Gary E. Miller <address@hidden> wrote:
> Yo Nuno!
>
> I just uploaded a fix for the problem.  And removed the problematic
> 'cycle' variable.
>
> ntpshmmon now outputs only when a segment changed the tvr and tvr.
>
> The results show how flakey the usleep() function is...
>
> Give it a shot and see how it works for you.
>
> Next is to add an option to only print 'weird' values.
>
> On Wed, 15 Jun 2016 14:30:11 +0100
> Nuno Gonçalves <address@hidden> wrote:
>
>> On Wed, Jun 15, 2016 at 12:03 AM, Gary E. Miller <address@hidden>
>> wrote:
>> >> Aren't we saying the same thing? This value is created at the shm
>> >> client side, so, when it is sampled and printed.
>> >
>> > CNo that is on gpsd server side.
>>
>> ntpshmmon.c gets it from enum segstat_t status = ntp_read(segments[i],
>> &shm_stat, false);.
>> ntp_read() is at ntpshmread.c and gets it from
>> clock_gettime(CLOCK_REALTIME, &shm_stat->tvc);.
>>
>> Dos this look to come from gpsd?
>>
>> I don't see any other bug related to the problem I reported. I'm sure
>> there are, but they don't seem to have any effects at this specific
>> problem...
>>
>
>
>
>
> RGDS
> GARY
> ---------------------------------------------------------------------------
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
>         address@hidden  Tel:+1 541 382 8588