Max time adjustment
Gabrie
Our Active Directory admin wants to start syncing time with our ESX hosts.
But he has one requirement, he wants me to limit the clock adjustment to max
1 hour. So if our ESX host has an incorrect time compared to the ntp server,
the ESX host should not correct it if it is off more then one hour.
Which ntp setting can I use for this?
(Redhat EL)
Gabrie
Terje Mathisen
NTP has a default max adjustment of about 1000 seconds (WAYTOOBIG is the
#define value), but you can override this with a config file parameter.
Terje
--
- <Terje.M...@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
David Woolley
Don't use -g. ntpd will then abort if one tries to change the time by
more than 1000 seconds. I.E., by default, ntpd will not allow a large
correction.
In the unlikely event that you really do want to tolerate up to 1 hour
(I imagine you would at least want reduce this by twice the maximum
assumed manual setting error), you would use "tinker panic 3600", I
believe. Please read the health warnings about tinker.
Richard B. Gilbert
> Gabrie wrote:
>> Our Active Directory admin wants to start syncing time with our ESX
>> hosts.
>> But he has one requirement, he wants me to limit the clock adjustment
>> to max
>> 1 hour. So if our ESX host has an incorrect time compared to the ntp
>> server,
>> the ESX host should not correct it if it is off more then one hour.
>>
>> Which ntp setting can I use for this?
>
> Don't use -g. ntpd will then abort if one tries to change the time by
> more than 1000 seconds. I.E., by default, ntpd will not allow a large
> correction.
>
ISTR that "-g" unconditionally sets the clock to whatever time is
supplied by the source(s)! It should bring your clock to within a few
milliseconds of whatever source(s) was/were used. This is a ONCE only
setting. Thereafter, less drastic methods are used and the size of any
correction is subject to "sanity checking".
David Woolley
>
> ISTR that "-g" unconditionally sets the clock to whatever time is
> supplied by the source(s)! It should bring your clock to within a few
> milliseconds of whatever source(s) was/were used. This is a ONCE only
> setting. Thereafter, less drastic methods are used and the size of any
> correction is subject to "sanity checking".
>
>
Not what the documentation (4.2.4p4) says. It only says that it removes
the 1000 second limit.
> -g
> Normally, ntpd exits with a message to the system log if the
> offset exceeds the panic threshold, which is 1000 s by default.
> This option allows the time to be set to any value without
> restriction; however, this can happen only once. If the
> threshold is exceeded after that, ntpd will exit with a message
> to the system log. This option can be used with the -q and -x
> options. See the tinker command for other options.
Unruh
>Richard B. Gilbert wrote:
>>
>> ISTR that "-g" unconditionally sets the clock to whatever time is
>> supplied by the source(s)! It should bring your clock to within a few
>> milliseconds of whatever source(s) was/were used. This is a ONCE only
>> setting. Thereafter, less drastic methods are used and the size of any
>> correction is subject to "sanity checking".
>>
>>
>Not what the documentation (4.2.4p4) says. It only says that it removes
>the 1000 second limit.
Yes. it says exactly that. See the "this can happen only once" line. And
the other docs which say that if ntp is off by more than 128ms it will step
rather than slew.
David Woolley
> David Woolley <da...@ex.djwhome.demon.co.uk.invalid> writes:
>
>> Richard B. Gilbert wrote:
>
>>> ISTR that "-g" unconditionally sets the clock to whatever time is
>>> supplied by the source(s)! It should bring your clock to within a few
>>> milliseconds of whatever source(s) was/were used. This is a ONCE only
>>> setting. Thereafter, less drastic methods are used and the size of any
>>> correction is subject to "sanity checking".
>>>
>>>
>> Not what the documentation (4.2.4p4) says. It only says that it removes
>> the 1000 second limit.
>
> Yes. it says exactly that. See the "this can happen only once" line. And
> the other docs which say that if ntp is off by more than 128ms it will step
> rather than slew.
You need to consider the context of the thread. It is not uncoditional,
because offsets of less than 128ms do not result in a step.
Richard B. Gilbert
I'm not sure what you are trying to say here! As I read the above text,
it does not seriously disagree with what I wrote.
Ryan Malayter
Actually, you should probably to make a setting on the Active
Directory servers, not on your ESX hosts. That way the AD servers will
ignore your source servers if they are acting crazy. I believe the
settings are MaxNegPhaseCorrection and MaxPosPhaseCorrection.
See:
http://technet.microsoft.com/en-us/library/cc773263.aspx
--
RPM
Ulrich Windl
I would shut down the system, set the clock in BIOS, then reboot,
watching the time for drift. If it drifts more than a minute per day,
first try to fix that. I think VMware has an article on taming bad
virtual clocks...
Regards,
Ulrich
>
> (Redhat EL)
> Gabrie