On Wed, Sep 14, 2011 at 15:51, Chris Albertson <[email protected]> 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 be fine.
Correct, with a PPS source, priority of ntpd matters much less. Similarly, most systems provide the SO_TIMESTAMP socket option which ntpd uses to request the IP stack timestamp the arrival of NTP packets. Where SO_TIMESTAMP is not available, ntpd takes a timestamp when it processes the packet and treats it as the arrival timestamp, so higher priority helps. Windows does not offer SO_TIMESTAMP, and in fact the port of ntpd to Windows ignores -N and always attempts to raise its priority, though it will proceed with a warning logged if not allowed. -N is ignored because historically the ntpd Windows port's priority-raising code failed to take it into account, and always attempted. Cheers, Dave Hart _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
