Re: [gpsd-dev] ntpshmmon

[Nuno Gonçalves]

You are correct. My patch was sleeping for <cycle>, because we had
that input and assumption that was the max frequency we were
searching.

Since we lost that assumption (fortunately), we have to pool the
memory fast to look for the signals. Actually my comments didn't make
any sense considering the changes with your patch. Sorry.

BTW, I'm only using SHM to count seconds, I don't rely on gpsd for
PPS. So our perspectives and interests are not exactly the same.

Thanks,
Nuno

On Fri, Jun 17, 2016 at 12:12 AM, Gary E. Miller <address@hidden> wrote:
> Yo Nuno!
>
> On Thu, 16 Jun 2016 23:23:07 +0100
> Nuno Gonçalves <address@hidden> wrote:
>
>> 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?
>
> Not exactly, this is more a test tool than a monitoring tool.  No one
> is gonna look at ntpshmmon for more than a few minutes.
>
> As I noted in a code comment, the Garmin GPS-18x may output PPS at
> 5Hz, with a minimum pulse width of 20 milliSec.  Some GPS are much
> faster, even 20 Hz.  We don't want to miss any bad behavior, and bad
> behaviour is not where you expect it.
>
> A simple wake-up and check is not much CPU load.  On the Pi3 ntpshmmon
> is 2.6% of 1 CPU, out of 4 CPUs.  So less than 1% of the Pi3's power.
>
> As a diagnostic, not production, tool that is very acceptable.  With some
> effort, if anyone cared, that could be improved a lot.
>
>> I wouldn't see a
>> problem of runing it at 10Hz or even 1Hz.
>
> Think Nyquist.  Just to see 5Hz square wave you gotta run at 10 Hz.  And
> we are not talking square waves.  A 20 Hz PPS needs at least 40 Hz, much
> shorter due to the pulse nature of it.
>
> Remember, this is trying to catch glitches that are hard for humans to see.
>
> OTOH, if we could figure out how fast ntpd polls the SHms, we could use
> that as a guide to how fast ntpshmmon needs to check.  But we would still
> want to be at least 2x that, because of our friend Nyquist and because this
> is a debug tool.
>
> And people keep reseting the cycle to 1Hz, and rediscovering why it does
> not work.  that is why the comments are in the code, and will shout
> louder and louder everytime somone ignores them.
>
>> For the user it doesn't
>> really matter if the results are printed with 100ms or 1s delay...
>
> True, but when we miss a pulse, we got a big problem.  We are trying to
> get PPS goo dto better than 1 microSec!
>
>> What are the weird data you are looking? Cycle misses? Delays above a
>> threshold? Delays that are statistically inconsistent?
>
> PPS that is one second early or late.  I'm not really sure since I need
> a good tool to find it.  I see on 3 well instrument hosts that ntpd
> goes weird by 1 second now and then, but I don't see why.
>
> RGDS
> GARY
> ---------------------------------------------------------------------------
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
>         address@hidden  Tel:+1 541 382 8588