Quick (I hope) ntpd question

[singlespeed]

I've spent the morning reading posts about NTP and am more confused than before I started.. :(

I basically just need my server to keep time correctly. I don't want it to be a timeserver for the rest of my network. ntpd is set to start on boot and is running. I've changed the ntp.conf file from it's default to what you see below. Is this all that's needed to get my server to keep it's clock steady?

Running RHES 3.2

got the ntpd daemon running. in the /etc/ntp.conf i have

# --- GENERAL CONFIGURATION ---

#server 127.127.1.0 # local clock
server pool.ntp.org
fudge 127.127.1.0 stratum 10

Or should I just not run the ntpd and instead use a cron job to run ntpdate every hour or so?

[bwkaz]

Running ntpdate from cron would keep the time correct, but you won't be able to keep track of the clock drift that way. The only good way to do that is to run a program that keeps track of it, like ntpd. :)

For the config file itself, I don't think that your "fudge" line is needed -- that address is the type that ntpd uses to indicate a hardware clock (i.e. an atomic clock, or something else that you built support into ntpd for). If you don't have a real atomic clock handy, you probably shouldn't use that as a time source. ;)

I generally use {0,1,2}.us.pool.ntp.org, myself (since that gives me three time servers -- hopefully at least one of them is running -- and it also gives me servers that are in the U.S.), but what you have should work too.

There are lots of other restrictions you can put into that file, but it's easiest to just use a firewall to block incoming udp/123 traffic on every interface except lo. (Just don't block outgoing traffic, or the replies to that traffic. The fairly-standard iptables "-m state --state ESTABLISHED" match should allow the responses, as long as they come in within a few tens of seconds of the outgoing request, and the outgoing request is allowed.)

[singlespeed]

Thanks Bwkaz!

So just editing the "server" values in the ntp.conf is enough to get it to sync. Question, how often does ntpd check and sync? how can this be controlled?

[bwkaz]

Question, how often does ntpd check and sync? It doesn't, not really. It's nowhere near that simple. (Note that Windows's time service is that simple -- it just checks about once a day, and sets the clock to whatever it should be, immediately. That's dumb -- see below for a much, MUCH better way to do it.)

What ntpd does do, is send packets back and forth frequently (one every few tens of seconds or minute, or so). If you're familiar with a phase-locked loop in electronics, that's basically what it's doing. It has a high-frequency local counter (the system clock) that it wants to keep in step with a lower-frequency but more-accurate counter (the remote clock(s) that it's syncing with). So at each signal from the lower-frequency counter, it adjusts the counting rate of the higher-frequency counter, so the local counter ends up at the same count as the remote one after a few round trips.

The round trips happen about once every minute (or few minutes) or so, but whenever it gets a frequency correction, it feeds the correction itself into the kernel, which modifies the clock rate that it has, so the time doesn't suddenly step from one second to another forward or backward -- rather, the seconds in between get slightly stretched or squished so that after a few seconds, the times will line up. This is nicer for programs that depend on the system time, like cron. (If the time jumps two minutes ahead, then cron will miss 2 minutes' worth of jobs that it should have run. Depending on the cron program, this means that either it'll skip them, or it'll run them all at once; neither is good.)

But the amount that each second gets stretched or squished is fairly small, so if the time difference is more than a certain threshold, ntpd gives an error and won't change the local time (I believe this is the only thing that ntpdate is supposed to be used for). This is partly as a sanity check on the remote time value, because in the normal course of events ntpd will by syncing frequently, and the clock will never get more than a few milliseconds off. So if it's suddenly off by several tens of minutes (or whatever the threshold is), it's a sign that either the remote server is screwed up, or the local clock has jumped; it's now the admin's responsibility to fix whichever one of these is at fault.

Anyway, this method also gives ntpd a drift value -- a value that keeps track of how much faster or slower the local hardware clock is actually running, compared to the reference clock(s). This gets stored away, though I'm not sure what it's used for. In theory it could be used to correct the clock when ntpd starts back up (if it knew how long it had been shut down), but it can fix that with a few syncs as well. (Although according to some docs I've read, it takes a lot longer to get the local counter in phase without the drift file. I'm not exactly sure why that is.)

how can this be controlled? You don't control it. It's basically hard-coded into ntpd; they've used the algorithm that they feel provides the fastest clock synchronization at startup (on the order of a few seconds, when the drift file is present) and the best long-term stability.

[singlespeed]

Bwkaz,

Thanks!!! that's the best explanation I've found so far. I really appreciate you taking the time to write all that!!

So in essence my server should keep time now provided that the source servers don't get screwed up.

[happybunny]

I'm curious to know if i list 100 time sources, will my local machine/ntpd average them out to the right time?

Or does it just use one of the 100, and move to a 2nd one if it is not available when it goes to check?

So does having more make for a more "accurate" (or average accurate) time, or is more than 3 just silly?

[bwkaz]

More than three may be silly, but it does do some averaging, yes. It analyzes the responses that it gets from each server, and throws out the ones that are more than some threshold away from the rest (and I think uses some heuristics too), then averages the samples that remain. :)