In article <[EMAIL PROTECTED]>, Eric Liu <[EMAIL PROTECTED]> wrote:
> The offset threhold is 128ms by default. I think it is a so large value. > I want 1ms accuracy among all clients over LAN. So, do I have to set it to a > smaller value? As for 1ms accuracy, set it to 0.5ms. You DO NOT want to do that. The 128ms is a panic threshold after which ntpd starts taking drastic measures to work round a presumed broken time source. It will take around quarter of hour to do so and throw away most of what it has learned. If you set this value any less than 30ms on the system you have, it will really start to have bad times on the clients. (Also, setting many of these sort of parameters, turns off the more sophisticated algorithms.) The single most important thing you can do is to eliminate Windows completely from any timing critical part of the system. If you are running any application on Windows that needs better than 20ms (more realistically 40ms) accuracy, you have made a fundamental design error, or you know so much about timekeeping software that you wouldn't be asking these questions. The next thing you need to do is to do a thorough interrupt and scheduling latency analysis on the PC 104 systems, to make sure that whatever external event you are measuring to 1ms accuracy actually will cause the code that reads the clock to be scheduled in rather less than 1ms. You should then do a similar analysis on the LAN, to ensure that LAN induced jitter on NTP packets is acceptable. Operating in broadcast mode may be advantageous, if you have a broadcast network, as all the client will see the same jitter pattern. What you do next depends on the maximum time between measurements for which you need 1ms accuracy. If it's of the order of a second or less, you can use the local clock on a Linux or FreeBSD machine, dedicated as a timeserver. If you are measuring over extended periods, you will need a true UTC time source. As noted before, offset represents sampling variations, it doesn't measure the true clock error. PS Please note that this mailing list is gatewayed to USENET and USENET is the primary forum. Although the gateway is known to be broken, you should still not keep starting explicit new threads. The gateway manages to break threads without anyone's help! If at all possible, use the USENET forum directly, or through Google groups. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
