[ACCEPTED]-Precise time measurement in Java-measurement

The problem with getting super precise time 5 measurements is that some processors can't/don't 4 provide such tiny increments.

As far as I 3 know, System.currentTimeMillis() and System.nanoTime() is the best measurement you 2 will be able to find.

Note that both return 1 a long value.

It's a bit pointless in Java measuring time 28 down to the nanosecond scale; an occasional 27 GC hit will easily wipe out any kind of 26 accuracy this may have given. In any case, the 25 documentation states that whilst it gives 24 nanosecond precision, it's not the same 23 thing as nanosecond accuracy; and there 22 are operating systems which don't report 21 nanoseconds in any case (which is why you'll 20 find answers quantized to 1000 when accessing 19 them; it's not luck, it's limitation).

Not 18 only that, but depending on how the feature 17 is actually implemented by the OS, you might 16 find quantized results coming through anyway 15 (e.g. answers that always end in 64 or 128 14 instead of intermediate values).

It's also 13 worth noting that the purpose of the method 12 is to find the two time differences between 11 some (nearby) start time and now; if you 10 take System.nanoTime() at the start of a 9 long-running application and then take System.nanoTime() a 8 long time later, it may have drifted quite 7 far from real time. So you should only really 6 use it for periods of less than 1s; if you 5 need a longer running time than that, milliseconds 4 should be enough. (And if it's not, then 3 make up the last few numbers; you'll probably 2 impress clients and the result will be just 1 as valid.)

Unfortunately, I don't think java RTS is 23 mature enough at this moment.

Java time 22 does try to provide best value (they actually 21 delegate the native code to call get the 20 kernal time). However, JVM specs make this 19 coarse time measurement disclaimer mainly 18 for things like GC activities, and support 17 of underlying system.

• Certain GC activities will block all threads even if you are running concurrent GC.
• default linux clock tick precision is only 10ms. Java cannot make it any better if linux kernal does not support.

I haven't figured 16 out how to address #1 unless your app does 15 not need to do GC. A decent and med size 14 application probably and occasionally spends 13 like tens of milliseconds on GC pauses. You 12 are probably out of luck if your precision 11 requirement is lower 10ms.

As for #2, You 10 can tune the linux kernal to give more precision. However, you 9 are also getting less out of your box because 8 now kernal context switch more often.

Perhaps, we 7 should look at it different angle. Is there 6 a reason that OPS needs precision of 10ms 5 of lower? Is it okay to tell Ops that precision 4 is at 10ms AND also look at the GC log at 3 that time, so they know the time is +-10ms 2 accurate without GC activity around that 1 time?

If you are looking to record some type of 7 phenomenon on the order of nanoseconds, what 6 you really need is a real-time operating system. The accuracy of 5 the timer will greatly depend on the operating 4 system's implementation of its high resolution timer and the 3 underlying hardware.

However, you can still 2 stay with Java since there are RTOS versions 1 available.

JNI: Create a simple function to access 18 the Intel RDTSC instruction or the PMCCNTR 17 register of co-processor p15 in ARM.

Pure 16 Java: You can possibly get better values 15 if you are willing to delay until a clock 14 tick. You can spin checking System.nanoTime() until 13 the value changes. If you know for instance 12 that the value of System.nanoTime() changes 11 every 10000 loop iterations on your platform 10 by amount DELTA then the actual event time 9 was finalNanoTime-DELTA*ITERATIONS/10000. You 8 will need to "warm-up" the code before taking 7 actual measurements.

Hack (for profiling, etc, only): If 6 garbage collection is throwing you off you 5 could always measure the time using a high-priority 4 thread running in a second jvm which doesn't 3 create objects. Have it spin incrementing 2 a long in shared memory which you use as 1 a clock.