Quote:
Originally Posted by
Green_Star
Hi there, sorry to bother you again.
When I had this command "ntpq -c rl" run on the server, this the the output I get.
It seems to me that you might profit in understanding from a bit of theory behind NTP and its workings. Here it goes:
Within a network it is vital to keep the timekeeping of the connected systems in sync. For instance the Kerberos protocol will invalidate any authentication attempt coming from a system which time is off by more than a (very narrow) margin from the ticket server. Alas, timekeeping in computers is done basically by some oscillating circuitry which is quite unreliable over periods longer than a few hours at most. This is where NTP comes in to synchronize the system time(s) throughout the network.
NTP is a client-server protocol and works in a hierarchical manner quite like the DNS protocol. At its root there are so-called
stratum-1 servers, which generate the correct time using some specially designed hardware (nowadays usually atomic clocks). Atomic clocks are off about a second every other billion of years, so for every practical purpose they are as exact as it gets.
You will never get into contact with a stratum-1 server anyway. These are not publicly available systems but usually secured and talking only to a very few select clients. These clients form the next layer of the hierarchy and are called
stratum-2 servers (now, who'd have guessed that?). They are on one hand clients to the stratum-1 servers, so their time is (almost, save for a margin you won't notice) as exact as them and on the other hand act as servers to the interested public.
That still doesn't mean they are publicly available. In fact a company usually has a contract with a company running a stratum-2 server and accesses with one (or two) client system(s) this service. These one or two systems act themselves as so-called stratum-3 servers giving out their time information to every server on the company network.
Now, how is timekeeping with NTP done: basically a client checks with his assigned server from time to time and if there is a difference in the gotten time information and the current system time the system time is adjusted. It
could be adjusted by simply setting it but this would create some problems: suppose the system time is 12:00:00 and a file is written. It would get the time stamp of 12:00:00. Now the NTP process sets the time back 5 seconds becaause it got the new information from its NTP server, so the system time would now be 11:59:55. Suppose a process would now try to find the last file one second later and notice that - from its POV - the file would be from the future. No good!
This is why time is usually adjusted "driftingly": the "seconds" on the affected system will be somewhat shortened or lengthened so that the "subjective" time on the system still passes continuously but eventually synchronises with the NTP servers information. This drifting is logged in the "drift file". Notice that per default the drift file resides in
/etc and can get pretty big if the timing circuitry of the underlying hardware is crap. I had a few (AIX) systems in my career having fits because of a full root FS after the drift file in
/etc filled it up. I'm not sure for HP-UX, but IIRC they don't like a full root FS any better.
You probably can understand your output now a little better.
I hope this helps.
bakunin