On Wed, Sep 14, 2011 at 15:51, Chris Albertson
wrote:
> At least in the case of a GPS reference clock, I don't think priority
> has an effect of accuracy. The PPS signal gets time stamped inside
> the interrupt handler. At long at NTP can process each PPS before the
> next one comes in it should
On 2011-09-14, Fran wrote:
> That then made me think about later stages of ntpd processing where
> ntpd has decided to adjust the clock some amount. What if pre-emptions
> happen in that segment of processing, where the adjustment value was
> calculated but not actually applied yet ? Just guessin
On Wed, Sep 14, 2011 at 11:07 AM, Fran wrote:
> Chris,
>
> That is a good point, I hadn't thought of reference clocks case(s) and
> interrupt level processing which will be at a higher priority than the
> ntpd process. I was thinking all network connections between ntpd
> processes.
>
> That then
Chris,
That is a good point, I hadn't thought of reference clocks case(s) and
interrupt level processing which will be at a higher priority than the
ntpd process. I was thinking all network connections between ntpd
processes.
That then made me think about later stages of ntpd processing where
ntp
At least in the case of a GPS reference clock, I don't think priority
has an effect of accuracy. The PPS signal gets time stamped inside
the interrupt handler. At long at NTP can process each PPS before the
next one comes in it should be fine.
On Wed, Sep 14, 2011 at 7:37 AM, Fran wrote:
> I t
I think it depends on how accurate you need your time synch to be, and what
possible impact that could be on other processes running on the system. High
priority ntpd mean less chances the ntpd process will be pre-empted and
switched out, and should mean better overall time sync (less error).
N
Hello,
I noticed the -N switch today. Should ntpd be run with -N on a
dedicated time server?
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
