[ntp:questions] NTP client configuration
benjamin.cabut at rsacosmos.com
Thu Sep 27 18:59:41 UTC 2012
-> our time source is the local clock of one computer. wich I guess is
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?
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
> questions at lists.ntp.org
CEO - president
More information about the questions