clock-sync

Home

Clock Synchronization

The clock synchronization protocol establishes a global clock for the federation. Initially, nodes will get the time from the web server where they register membership and IP address. Time is approximately seconds since 1970 represented as a double.

API

Clock.Initialize()

set up the clock to be returned by getInstance().

Clock.getInstance()

return the single Clock object is created at startup time and can be accessed in this way.

Clock.getInstance().getTime()

get the time in seconds.
The time returned is approximately the number of seconds since 1970, so this is a large number. The rationale is that there is no clear start time for a performance or obvious time to set the time to zero. The time is available before clock synchronization begins, so the time may jump forward or backward due to synchronization. The jump should be less than one second. After the initial clock sync, the clock should not jump by more than a few milliseconds.

Clock.getInstance().getScheduler().schedule(Event e)

schedule an event. Normally, you would subclass Event (use edu.cmu.cs.floctrl.clock.Event, not the Event defined in Swing).

Clock.getInstance().getScheduler().crossThreadSchedule(Event e)

If you are not running on the GUI thread, call this to safely run schedule() on the GUI thread.

The initial timeStamp on an Event should be based on Clock.getInstance().getTime(), e.g. to run the event 5.5s in the future, use

event.timeStamp = Clock.getInstance().getTime() + 5.5;

Clock.getInstance().getScheduler().schedule(event)

Scheduled events are run on the GUI thread so they can make calls to Swing and access GUI components. Try to avoid creating other threads if you can use scheduled events.

Clock.getInstance().getScheduler().getNow()

returns the logical time in seconds from within the run() method of an event (this tells you your ideal scheduled run time, but so does timeStamp, an instance variable inherited from Event).

schedule(after(double delay))

reschedule a running event after some delay (in secconds); you call this from inside the Event's run method.

Overview, Requirements, Etc.

The network can function with just this rough initial clock setting. To make things more synchronized, any node can become the global time server (GTS). To become the GTS, just publish (broadcast) a message to "/" (the whole federation) with topic "CS" (clock sync) and announce your URL, e.g. "/cmu/joe".

We need to distinguish two times: RT is the system real time returned by a call to Java. GT is the "federation global time" which will be at some offset from RT. The clock synchronization code will provide a method to get the estimated GT and will also run a synchronization protocol to estimate the offset from RT to GT.

The clock synchronization protocol is performed at two levels: node to super-node, and super-node to super-node, but the protocol is the same. To synchronize a slave clock to a master clock, the slave reads the local system real time (call it A) and sends a request for the time to the master. The master replies with the GT (call it C), and then the slave reads the local system real time again (call it B). The estimated offset is

O = C - (A + B) / 2

Then, to estimate GT, just compute

GT = RT + O

The equation above for O is sensitive to network delay, so a simple fix is to do smoothing over multiple estimates, e.g.

T = C - (A + B) / 2
O = 0.9 * O + 0.1 * T

An even better method is to look at the previous 10 requests to the master. The round-trip time for the time request is A-B. Whichever request had the lowest round-trip time has the best estimate of O, so use that one.

In any case, requests should be made periodically. Clock error is usually within 0.01%, or 0.0001, or 1ms every 10s. A reasonable goal is to stay synchronized within 10 milliseconds, so running every 10s to 60s should be OK.

When the offset O changes, this will either cause local time to jump forward or backward. It would be a good idea to limit local time jumps to 20ms in case the scheduler is trying to produce some rhythmic music.

Design

• Details here

Implementation Plan

• Who does what when?

Home