5

Is it correct to compare two values resulting from a call to System.nanoTime() on two different machines? I would say no because System.nanoTime() returns a nanosecond-precise time relative to some arbitrary point time by using the Time Stamp Counter (TSC) which is processor dependent.

If I am right, is there a way (in Java) to capture an instant on two different machines and to compare (safely) these values with at least a microsecond precision or even nanotime precision?

System.currentTimeMillis() is not a solution because it is not returning a linearly increasing number of time stamps. The user or services such as NTP can change the system clock at any time and the time will leap back and forward.

Laurent
  • 14,122
  • 13
  • 57
  • 89
  • NTP was designed to allow multiple computers to agree on what time it is. – Thorbjørn Ravn Andersen Nov 03 '11 at 19:47
  • It seems like it depends a good bit on what *kind* of comparing is being done... –  Nov 03 '11 at 19:48
  • I have a feeling you're going to want to use an 'external' or 'third-party' time call, that _everything_ uses. I'm not suggesting an actual outside party, but some separate 'time-server' process that everything grabs it's time from. – Clockwork-Muse Nov 03 '11 at 19:49
  • pst, I suppose that I have a machine M1 that generates an event at time T1 but also on an another machine M2, M2 generates an event at time T2. Then, the values T1 and T2 are received by a machine and I would to know if T1 is greater, lower or equals to T2. – Laurent Nov 03 '11 at 20:01

4 Answers4

4

You might want to look into the various clock synchronization algorithms available. Apparently the Precision Time Protocol can get you within sub-microsecond accuracy on a LAN.

If you don't need a specific time value but rather would like to know the ordering of various events, you could for instance use Lamport timestamps.

Vlad
  • 18,195
  • 4
  • 41
  • 71
1

You cannot use nanoTime between two different machines. For the Java API docs:

This method can only be used to measure elapsed time and is not related to any other notion of system or wall-clock time. The value returned represents nanoseconds since some fixed but arbitrary time (perhaps in the future, so values may be negative).

There's no guarantee that nanoTime is relative to any timebase.

Steve Kuo
  • 61,876
  • 75
  • 195
  • 257
0

This is a processor & OS dependent Q. Looking at POSIX clocks, for example, there are high precision time of day aware timestamps (e.g. CLOCK_REALTIME returns a nano epoch time value) and high precision arbitrary time timestamps (e.g. CLOCK_MONOTONIC) (NB: the difference between these 2 is nicely explained in this answer).

The latter is often something like time since the box was booted and therefore there's no way to accurately compare them across servers unless you have high precision clock sync (e.g. PTP as referenced in the other answer) in the first place (as then you'd be able to share an offset between them).

Whether NTP is good enough for you depends on what you're trying to measure. For example if you're trying to measure an interval of a few hundred micros (e.g. boxes connected to the same switch) then your results will be rough, at the other extreme NTP can be perfectly good if your servers are in different geographical locations entirely (e.g. London to NY) which means the clock sync effect (as long as it's not way way off) is swamped by the latency between the locations.

FWIW the JNI required to access such clocks from java is pretty trivial.

Community
  • 1
  • 1
Matt
  • 8,367
  • 4
  • 31
  • 61
0

You can synchronize the time to current time millis. However even if you use NTP this can drift by 1 ms to 10 ms between machines. The only way to be micro-second synchronization between machines is to use specialist hardware.

nanoTime is guaranteed to be determined the same way or have the same resolution on two different OSes.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130