Title pretty much explains it. Let's say there's 100 servers, various versions of Windows and Linux, and one Windows server is the "master clock." I did look at this question:

How do I synchronize clocks between Linux and Windows?

This hints that ntp can do what I want if I run "ntpd -q" on a client (?). If I install ntp I also need to guarantee that it will only sync the times when I force it to. Even better if I have a log that tells me every time a sync was performed.

I'm doing benchmark runs and I need to be able to say something like this: "Clocks were synced on all the benchmark systems at 09:42:01am on the master. A benchmark run was then initiated and allowed to run for six hours. None of the system clocks were altered during this time interval."

I understand there is subsequent clock drift, but for now that's the way we're doing things and I'm doing it with a manual process. I'd rather at least automate the one-time sync.

  • A couple things to add: the 'master' system has Cygwin installed. The Windows machines have .bat files to sync their times with the 'net time' command. The Linux machines don't have an equivalent script right now. I discovered I could log into a Linux system, ssh into the master (running cygwin), run 'date' and use that output to set the local time with 'date -s.' – twblamer Jun 26 '11 at 10:07

Are you looking for the specific command to start/stop NTP on Linux and Windows? Those are different on different Linux distros. It will be something like "/etc/init.d/ntpd stop" on some, different on others, and I'm not sure on Windows.

There are two ways to do this, and one caveat.

Method 1: Run NTP normally but stop it for the benchmark.

Method 2: Don't run NTP but run NTP in "one-shot" mode right before the benchmark runs. (On linux that would be "ntpdate SERVERNAME" on Unix/Linux or [i think] "ntp -q" on windows)

Method 1 has some advantages in that the clock will be correct all those times that the you aren't running benchmarks. The clock will also be more accurately set for the benchmark. That is, NTP maintains the clock very accurately even between NTP packets. The NTP packets on the network are simply fine tuning. Between packets NTP uses past experience to nudge the system clock faster or slower. The disadvantage is that when you start NTP again, it will refuse to start if the clock is too far off. This is not a bug, it does this on purpose to prevent syncing to a server that has gone bad. To prevent this, do an "ntpdate" or "ntp -q" right before you restart NTP.

Method 2 has the advantage that it is more simple to implement. However, the clock will not be very accurate. "one shot" mode doesn't set the clock as accurately as running NTP. It is mostly for fixing a far-off clock before you start NTP (see above). However, if your benchmark only has to be accurate to about 1/10th second you'll be fine.

The caveat is that the benchmarks might not be benchmarking what you think they are benchmarking if you turn off NTP. The computer's clock will drift without NTP running constantly. That's ok if you are benchmarking how much drift the computer has but not much else.

(And I should note... the drift will be different not just brand-to-brand, but between particular machines.)


  • I probably want Method 2. I found this: techrepublic.com/blog/datacenter/… which might suggest I can use the master server as an NTP server. Right now, the Windows machines use a batch file that runs 'net time' to sync up. Obviously this is not best practice, but if all the systems are at least capable of doing a one-shot sync with NTP, then it's that much easier later on to argue for letting the machines sync continuously. – twblamer Jun 26 '11 at 10:12

If you were just using Linux I'd use mcollective for parallel execution of the ntpdate command. My ntpd doesn't have a -q option.

I'm not familiar with similar tools for Windows.

Just to be clear, you're more likely to get consistent time when running ntpd continuously since it also keeps clock drift at bay. Different computers have slightly different clock speeds, and just synchronising clocks at the start does not guarantee they'll keep in sync for the next six hours. ntpd is designed specifically to correct this.


ntpd is designed to keep a constant synchronization, hence the "d". ntpdate will get you a one-time sync.

For Windows, I guess you would do something like this.. (I haven't tested if this works right)

w32tm /config /manualpeerlist:"valid.ntp.server,0x9"
w32tm /resync /rediscover
w32tm /config /manualpeerlist:"bogus.invalid.server,0x9"

Why not just let the devices stay in sync at all times, though?


Manual syncing may be your only option for Windows without additional software. See this article:


For alternatives, this page looks promising:


Keep in mind that doing a periodic / manual sync is NOT better in any way than continuous. Logging time changes due to clock drift for extended durations without synchronization will not give you a supreme level of accuracy. Clocks don't necessarily drift at a consistent rate; it can change based on temperature and other fluctuations you cannot measure.

What level of accuracy are you looking for? +/- 1 second, +/- 0.0001 seconds, ...?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.