- that there is (eventually) a Windows implementation.
I'm writing the code to be as portable as I can make it, but I have
neither Windows machines nor clue how to program for their kernel-time-api.
- that it responds to "ntpq -pn" and "ntpq -crv" commands so that it can be
easily remotely monitored.
The jury is still out on the control protocol.
To be honest I don't much like it from a security point of view,
and the parameters of my clock control algorithm may not map well
into its datafields.
Time will show...
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
==================================================================
Yes, I can appreciate the Windows problems. We have more than a thousand
clients running the reference NTP as ported by Meinberg very happily, but if
there were a better-performing implementation that would be "nice" to have.
Personally, I feel that the ability to monitor the workings of an NTP
implementation remotely is an important feature of the (present) software.
I can run on one system a single monitoring program which then checks NTP
running on Windows, Linux and FreeBSD systems using exactly the same over
the wire ntpq commands. Perhaps you can return dummy values where your
algorithm differs? The ability to know lock status, offset and jitter
(ntpq -crv) is useful for longer term checking, and the "*" in ntpq -p
helpful for a response to a quick-look "is it working?" interrogation.
Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: [email protected]
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
