gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] ntpshmmon


From: Nuno Gonçalves
Subject: Re: [gpsd-dev] ntpshmmon
Date: Tue, 14 Jun 2016 10:52:31 +0100

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]