Kay Hayen wrote: >> Please tell us what you are trying to do. You are telling us your solution >> ( which sounds really bad) instead of the problem you are trying to solve, >> and then trying to convince the whole communtity to impliment your >> solution. > > Uhm, well you are right. > > We need to assess NTP status information. We consider the details of every > peer of the system, reachability, jitter, etc. > > Ideally as it occurs with no delays. Ideally we would be able to poll() some > file descriptor whenever something has changed for an ntpd. I don't think > such an interface exists. Short of that we would check it with reasonable > frequency. > > We need to do it for many hosts to calculate a "CLOCK" status for the host, > and the clock status would e.g. be bad if an ntpd is synchronized to an > internal host, but not one the allowed external hosts. There is a set of > criterias subject to user configuration. > > We need to be able to actively restrict NTP servers that are out bounds with > offsets. Servers that e.g. mishandle a leap second and are 1 second off from > that time on, or have other malfunctions, will be disabled that way. > > We need to publish the information for all hosts via SNMP. >
Heiko is in the process of implementing an SNMP MIB for NTP so you should just be able to leverage this when it's complete. Meinberg also has a monitoring application that you might want to consider. Danny _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
