2

I have 13 computers in the office that I want to make sure the time is in sync. I thought of configuring a virtual server to be the NTP server of the local network. That NTP server will sync with the pool of servers. On the clients, would it be okay to just reference the one NTP server and mark it as prefer and comment the rest out or should I list the pool as well?

My thought is, if the Internet craps out, no amount of redundancy on the local network would help with time anyway. Maybe I should add a line on the NTP server to fall back on its own internal clock to pass to clients?

client ntp.conf

server LOCAL_NTP_IP prefer
#server 1.US.POOL...
#server 2.US.POOL...
tomhauss13
  • 21
  • 1
  • 2
  • 1
    with such a small number of clients, I would be tempted to point them at the pool. A reasonable counter-argument would be if you want to keep that traffic off your WAN/internet link, preferring to have one system sync, then fan it out internally. NTP is not too bandwidth-heavy, though. (and it's resonable at keeping time while disconnected) – Jeff Schaller Oct 07 '15 at 01:47
  • 1
    I have had bad experiences with virtual servers running NTP, they drift a lot and in some instances won't ever synchronize with an NTP source. – wurtel Oct 07 '15 at 07:27
  • 2
    Why not have them sync to your router? – dfc Oct 07 '15 at 11:10

2 Answers2

1

In addition to the other answer, if you need to keep the time reasonably close to the reality and you suspect that your local network could be disconnected from the internet for prolonged intervals, you might calibrate the clock on your NTP server. Install adjtimex, run the server for some days without NTP, find the time drift (ntpdate -q pool.ntp.org) and see http://www.ep.ph.bham.ac.uk/general/support/adjtimex.html for a calculator to help you find out what to put to /etc/adjtime (probably depending on your distribution).

You might also look at /sys/devices/system/clocksource/clocksource*/available_clocksource for available clock sources and try to pick a more precise one (to put into /sys/devices/system/clocksource/clocksource0/current_clocksource). I found out that hpet drift is only about 10% of tsc on my server.

Radovan Garabík
  • 1,853
  • 1
    Calibrating a virtual server's clock like this is an awful idea. This method requires bare metal. – dfc Oct 07 '15 at 11:07
0

For a small number of machines, the load is very low. So I'd probably let them all query pool servers.

Unless your network is down for quite a bit more than a day, I doubt you will have a huge benefit from a local server. But the setup cost is very low as well, so it's probably worth it. I would pick one machine to be the local server. If it's down, everyone will just tick at the last set rate and should stay together reasonably well. If the designated server is up, then all will use it when the pool is down.

No need to use 'prefer' in this case.

For the designated server:

server 0.pool.ntp.org
[...]
server 127.127.1.1  # local clock
fudge 127.127.1.1 10  # don't trust the clock much

For all the clients:

server 0.pool.ntp.org
[...]
server local.designated.server
  • Network up - all clients sync against pool
  • Network down/server up - other clients sync against your server
  • Network down/server down - other clients tick at last configured rate

If you think 13 is no longer a "small number" and you want to reduce your load on the pool (and you don't want to get a cheap GPS clock), then you could sync one or two machines to the pool and sync the rest to them.

Designated server 1

server 0.pool.ntp.org
[...]
server 127.127.1.1 # local clock
fudge 127.127.1.1 10 # don't trust the clock much

Designated server 2

server 0.pool.ntp.org
[...]
server local1.designated.server
server 127.127.1.1 # local clock
fudge 127.127.1.1 12 # don't trust the clock much

All other clients

server local1.designated.server
server local2.designated.server
BowlOfRed
  • 3,772
  • 1
    This is a terrible answer. For starters two is the worst number of server associations. A man with one watch knows what time it is and a man with two watches is never sure. Most importantly stop recommending the undisciplined local clock unless you understand its purpose. The developers explicitly state in bold "we recommend against using this driver" on the documentation page for ULC: https://www.eecis.udel.edu/~mills/ntp/html/drivers/driver1.html – dfc Oct 07 '15 at 11:18