[ntp:questions] NTP client configuration

Benjamin CABUT benjamin.cabut at rsacosmos.com
Thu Sep 27 18:59:41 UTC 2012


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
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions
>
>
>


-- 
CABUT Benjamin
CEO - president
RSA Cosmos



More information about the questions mailing list