Hello David,
-> our time source is the local clock of one computer. wich I guess is
accurate.
I mean, we don't need to get the correct time in our application,
but we need that all computers shares the same time even if it wrong
compared to UTC.
-> you are right our problem is that ntpd takes time before accepting
time is broken, and during all this time our software do not work well
BUT I don't think the problem wome from the server (local clock).
Because the problem happen on one client only, when this client computer
is doing some action that I guess are making trouble to ntp.
Actualy my computer is playing audiofiles throught a special audio board.
I don't know why it affect ntp client, but it does....
I also have a problem when we start the computers in the morning, in
this case the server need some time to accept client request + client
need time to adjust there clock.
What I was wondering, is how Meinberg Time Server Monitor is doing to
know the "offset" (ntpq is also getting this information).
If i could have a way to get this in C source code, then I will handle
easily this issue.
Do you know how I can proceed to get "offset" value in a source code?
Regards.
Benjamin
Le 27/09/2012 19:57, David Woolley a écrit :
David Taylor wrote:
I haven't used "broadcast" or "auth", so I don't know if that affects
things. My understanding of NTP was that unless you configure it
otherwise, an offset exceeding 128 milliseconds would force NTP to
step the PC's clock rather than changing the rate, so I am surprised
you are seeing 500 ms offsets.
ntpd will wait a considerable amount of time before accepting that the
time it has really is broken. That I think is the issue here. There
is a tinker option which will reduce that. However the fundamental
problem is that NTP is intended to be used with time sources that
behave like UTC, with the only perturbations being those due to
variations in network delays, etc. The OP is asking the system to
work with a fundamentally broken time source. To get anything like
that to work, he is going to have to tune things a very long way from
their best practice settings, and accept that the ability to do so is
not part of the core requirements for ntpd.
The best solution is to fix the time source, but I suspect there is
some reason why that is not an option.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
--
CABUT Benjamin
CEO - president
RSA Cosmos
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
