On Tue, Nov 8, 2011 at 23:26, Chuck Swiger <cswi...@mac.com> wrote: > If you've set ntpd's priority above 100 via realtime scheduling class, > then it has priority over the system kernel threads which service > network interrupts. select() might be legitimately returning zero > because ntpd is running before the NTP packet gets processed > by the network stack. > > If you continue to run ntpd bound to processor 0, but change priority > to 59 fixed-priority, does it see the packets then?
Chuck advice to ensure ntpd's priority is lower than the interrupt-processing thread(s) seems wise to me. Moreover, there's not a lot to be gained by running ntpd at elevated priority when your synchronized to network peers on systems which support SO_TIMESTAMP, as most Unix systems do and Solaris does. With SO_TIMESTAMP, ntpd's packet receive timestamp comes from a timeval (usec resolution) captured by the network stack at interrupt time or shortly thereafter, rather than by ntpd querying the clock after select() returns. When using a reference clock, or on a system without SO_TIMESTAMP such as Windows, elevated priority improves the latency of the receive timestamps. Cheers, Dave Hart _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions