Bug 51855

JMeter by default uses System.nanoTime() for timing samples, as this gives greater accuracy than System.currentTimeMillis(). The latter often has a granularity of 10-20 milliseconds.

After it was introduced, it was discovered that nanoTime can drift quite substantially from wall time over the course of a test run.

For this reason, the SampleResult class now only uses nanoTime to enhance the accuracy of currentTimeMillis. It does this by calculating the offset between nanoTime and TimeMillis, effectively resetting the nanoTime with each sample.

This ensures that individual sample times are accurate, without allowing the start and end times to drift from wall time.

However, the nanoTime offset is affected by the TimeMillis granularity; consecutive samples may vary by 10-20 ms. This has the consequence that the current calculation of the parent sample end time may result in the parent elapsed time being shorter than the sum of its constituent elapsed times, or being noticeably greater. The difference can be 10-20 ms either way.

It's more important that elapsed times are accurate, rather than having exact start and end times (these are subject to the TimeMillis granularity anyway).

One fix is to adjust the parent sample end time by the difference in the nanoTime offsets, thus allowing for the drift.

An alternative fix would be to ensure that all the samples in the parent group used the same nanoTime offset; however the offset is currently final. Perhaps consider this for a later release.