Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Need : Meinberg NTP client configuration to immediately correct to server time
21 views
Skip to first unread message
Andy Munoz
May 17, 2013, 6:56:22 PM5/17/13
to
I am using the Meinberg ntpd 4.2.4 deamon to syncronize a client pc to another server pc on my network. The client time cannot be trusted.
The problem I am having is that if the client time drifts out too far as a result of a network loss, it does not appear to resync and correct its clock to conform to the server's true time.
I havetried using "server xxx.xxx.xxx.xxx. iburst minpoll 4 maxpoll 5
to be more agressive with getting the client to poll but it symply resyncs without forcing a time jump and only over a long period of time do I see the client correct itself to the Server's time.
I am aware of W32Time Max Phase Correction but can't seem to find similar control with meinberg. I wish to continue to use meinberg since the client may act as a server or peer for a subnet.
Does anyone know how to configure this application to have the client always burst and update its clock to lock onto the NTP server in the similar manner as the IBURST behavior when the client first starts up ?
The problem I am having is that if the client time drifts out too far as a result of a network loss, it does not appear to resync and correct its clock to conform to the server's true time.
I havetried using "server xxx.xxx.xxx.xxx. iburst minpoll 4 maxpoll 5
to be more agressive with getting the client to poll but it symply resyncs without forcing a time jump and only over a long period of time do I see the client correct itself to the Server's time.
I am aware of W32Time Max Phase Correction but can't seem to find similar control with meinberg. I wish to continue to use meinberg since the client may act as a server or peer for a subnet.
Does anyone know how to configure this application to have the client always burst and update its clock to lock onto the NTP server in the similar manner as the IBURST behavior when the client first starts up ?
David Woolley
May 18, 2013, 4:37:08 AM5/18/13
to
[Excessively long lines and missing paragraph gaps repaired.]
> to another server pc on my network. The client time cannot be trusted.
Also note that a low maxpoll will tend to result in the clock drifting
faster when there is a network outage, as ntpd will not be able to get
as accurate measurement of the crystal frequency error.
> to be more agressive with getting the client to poll but it symply
+ resyncs without forcing a time jump and only over a long period of time
+ do I see the client correct itself to the Server's time.
By default, tinker step is set to 128ms. Most people actually want to
increase it, rather than reduce it.
>
Andy Munoz wrote:
> I am using the Meinberg ntpd 4.2.4 deamon to syncronize a client pc
University of Delaware.
> I am using the Meinberg ntpd 4.2.4 deamon to syncronize a client pc
> to another server pc on my network. The client time cannot be trusted.
> I havetried using "server xxx.xxx.xxx.xxx. iburst minpoll 4 maxpoll 5
Do not do this unless you own the server. It is considered abusive.
Also note that a low maxpoll will tend to result in the clock drifting
faster when there is a network outage, as ntpd will not be able to get
as accurate measurement of the crystal frequency error.
> to be more agressive with getting the client to poll but it symply
+ do I see the client correct itself to the Server's time.
By default, tinker step is set to 128ms. Most people actually want to
increase it, rather than reduce it.
>
0 new messages