Synchronization (of clocks) between two remote computers

Question

I\'m looking into writing a simple synchronization ability into my app and one of the concerns that has popped up is synchronization of time between two remote computers, ea

Answer 1

You can try PTP, The Precision Time Protocol (PTP) is a protocol used to synchronize clocks throughout a computer network. On a local area network it achieves clock accuracy in the sub-microsecond range, making it suitable for measurement and control systems. http://en.wikipedia.org/wiki/Precision_Time_Protocol

Answer 2

Instead of writing code to synchronise the clocks, wouldn't it be possible to just run an ntp client on both machines?

Alternatively, if the above is not possible and your app is running with sufficient privileges to set the time, I would be tempted to implement a minimal NTP client right in the application and try to sync it against a public server. Just don't hardcode someone's private server in...

Answer 3

This is a problem I currently have to solve in respect of unsophisticated end-users who can do many things to upset the sensible suggestions made by the previous contributors. An unsophisticated end-user can do at least these things, and more:

1) Not have enough computing knowledge to be able to set up ntp time synchronisation

2) Set their computer time clock to a house clock or mobile phone clock that is incorrect

3) In Windows XP accidentally disable ntp time sync and not know how to enable it again, or have their computer date set wrongly, in which case Windows ntp doesn't work

4) The computer bios battery has gone flat so the pc always starts up in 1970!

5) The user takes their laptop abroad and temporarily sets the laptop clock to local time but does not change the time zone, so now the pc will return incorrect utc time!!!

So your program itself will have to manage the time, and of course you want to do that with minimum overhead.

Let's assume two end-users running the your programs need the programs to do something at the same absolute time in the future.

I propose this scheme, which takes some ideas from the way cron jobs work, I would be happy if anyone can suggest improvements to the idea.

1) When your application starts, it synchronises its own internal utc time to ntp via a soap call to a third party server or to your own time server (which you can yourself keep on time with ntp).

2) After that it adds on elapsed time from the system clock to maintain the time. If requirements are stringent you may need to repeat the ntp synchronisation at intervals.

3) The application then looks at a list of future jobs that it needs to do on time. It needs to know the earliest job.

4) It then creates a thread which it puts to sleep for the length of time ahead of the earliest job, less a safety margin, which depending on your requirements could be 10 minutes in advance, an hour or two in advance etc.

5) When the thread wakes up, it rechecks the absolute time with a further soap call, and then relies on the system time clock to add on elapsed time until it reaches the time when the first job should be carried out.

6) As soon as the job is triggered (run it in another thread) the time-monitoring thread calculates the next task time ahead and puts itself to sleep again for the duration.

Enhancements to the idea:

1) A user may close down your application before the due job, so you may need a background process or service, which uses the same synchronisation scheme above, to independently monitor your job lists, stored in a database or file, and start up the application in time. (In Windows, spawn the application process)

2) Your application may be adding newer, earlier jobs on the fly, or deleting jobs, so your sleeping thread will probably need to be wakeable to recalculate for the new earlier job, or for the job following the deleted job. In Win32 you would do this by your thread waiting with timeout on an Event, which you set to force it to recalculate the sleep time. In Linux no doubt there is a similar mechanism.

3) For the Soap call to get the time keep a note of when the Soap is sent and when the response is received. If the turnaround time is too long, you cannot rely on the time and may need to repeat the call, or you can compromise. For example, if the Soap says the computer clock is 5 minutes fast, but the Soap call itself took a minute to reply, then you can only say for certain that the computer clock is at least 4 minutes fast.

Answer 4

Relying on NTP for your application as others have recommended is the easy fudge. The correct approach is to use Lamport's distributed clock synchronization algorithm. It is explained in his classic 1978 paper Time, clocks, and the ordering of events in a distributed system.

Answer 5

any networked machine should use NTP. all modern systems include an easy way to setup this. the only issue should be choosing a specific server, if you need a little extra precision; but it's already in the millisecond range, so i don't care and usually just point to pool.ntp.org

Answer 6

Don't use NTP. NTP is for getting date/time only.

It works to synchronize events between apps that don't communicate. An alarm app and your body, for instance.

For apps that have direct communication, sharing a resource, use lamport clocks or vector clocks as Diomidis said. Lamport clocks work great to achieve a partial order between events, Vector clocks are great when you need to identify concurrent events.