ntpdate

[Hakki Aydin Ucar]

I wonder what it means the below explanation that quoted from Charles Keenan's book (CSE) :

>> The NTP software is able to reset your system clock backward in time.
OR
>> ntpdate has the ability to move our system clock backward in time.

Does it mean by clock backward ,ntpdate only can adjust the system clock if it is bigger than server clock ?

[Anshumali]

NO....
that just means that it will sync up the client's time with server regardless of whether your client is at later time than server or earlier. ntpdate will just make it equal to server's time, it doesnt care about +/-
Treat above as "caution line or Tip" as Databases and other apps dont like time going back wards when it happens....

[Sundar G]

ntpdate command used to sync the timings with respect to NTP server, useful when a server is physcially moved to another location which is in different time zone, - (of-course before comissioning the server in its new facility )

[Pete Randall]

I would take that to mean exactly what it says. NTP can move the clock backward, but it does it so gradually that there are no ill effects. As a general rule, paricularly in a database environment, it is not good to set the clock backward. With NTP, however, the adjustment is very gradual, a few microseconds are removed over a period of time and time dependant software is unaware of the change.


Pete

[Dennis Handly]

>Pete: NTP can move the clock backward

I would think it safer if it slows down the clock so the real time catches up to that machine.

>SundarG: useful when a server is physically moved to another location which is in different time zone

I'm not sure why you care about if a server is moved. When you start it, you make sure the clock is set to UTC. NTP is to keep the clocks synchronized after the system has been up awhile.

[Pete Randall]

Dennis,

I didn't say that very well, did I? I meant that NTP can present the effect of moving it backward, but it does so by slowing it down.

Thanks for clarifying.


Pete

[Matti_Kurkela · Accepted solution]

Turning a system clock backwards may cause bad things to happen if e.g. a database is running while the system clock is adjusted. (For example, the database or the application using it might crash.)

If you have an application that does not like it if time changes backwards, you should be aware of it and change your procedures as necessary.

The ntpdate command will change the system time instantly ( = using a STEP method) by default. The step may be forwards or backwards.

To adjust the system clock gradually, by slowing it down/speeding it up (= slewing it) until it matches the real time, you should use the -B option with ntpdate.

If you must make large adjustments (for example, larger than the +/- 1000s allowed by xntpd) to the system clock while applications are running, 'ntpdate -B' is the safe (but slow) way to do it.

The NTP daemon (xntpd) may also do a step-type change, if the time is more than 128 ms out of sync. It too has an option to avoid step-type changes: if you run e.g. a database or a financial transaction system and it's critical that the system time value never changes backwards, you should add the "-x" option to xntpd. In HP-UX, this can be done using the XNTPD_ARGS variable in /etc/rc.config.d/netdaemons.

MK

[Michael Steele_2]

Hi

I think its even more basic than expland above. I read this as "...either the NTP server can initiate a time sync up, or the client can with ntpdate...".

Ntpdate polls the ntp servers.

When left alone the ntp servers push the time out to its clients.

[Patrick Wallek]

>>When left alone the ntp servers push the time out to its clients

If the server is set to be a NTP Broadcast server, yes.

Otherwise the NTP clients periodically poll the server to get the time.

[rick jones]

FWIW, time on one system is usually said to be "later" or "earlier" than time on another system, not "bigger" or "smaller."

If pointed at an NTP server which is itself "synchronized" to a better stratum time source (closer to the "root" of the time tree if you will), the ntpdate command will reset the client OS's idea of current UTC to "match" that of the server. It is useful, particularly at system boot time, to get the clocks close enough that when running on the client, the ntpd (xntpd) can make adjustments to the rate at which time advances on the client to keep in in sync with the server(s).

If the time on the client is far enough off from the server when the ntpd is started the ntpd may make a "stepwise" adjustment to the client's idea of the correct UTC - this may cause the clock to jump forwards or backwards (iirc). If the time on the client is even farther off from the time on the server, ntpd will give up and ask that time be brought into closer agreement - via perhaps an ntpdate command.

Some applications do not handle stepwise adjustments in time very well. For example, I was recently running a benchmark that only took about 1200 seconds to complete, but there was a nine day ! stepwise adjustment to time (forward in this case) and so the benchmark reported running VERY slowly :) I can only imagine what it would have done had the time been adjusted backwards... :)

NTP does everything in UTC, as does Unix, it takes little to no interest in timezones. That is just a UI issue :)