When using System.nanoTime(), the SampleResult ctors calculate the current offset from currentTimeMillis(). This was previously done just once when the class was initialised, but this was found to cause problems because of drift - see Bug 51855. Consider using a background thread to calculate the offset, rather than calculating it for each sample - this should reduce the overhead for high sample rates. So long as the time between refreshes is kept reasonably low, drift should not be sufficient to cause an issue.
Note: it looks like Thread.sleep() returns to the thread shortly after a clock transition (as might be expected). Calculating the nanoTime offset immediately afterwards should ensure more consistent values. With the current implementation - which may call currentTimeMills at any point in the clock cycle - the granularity of currentTimeMillis (generally 10ms-15ms) means that the offset can vary by that amount.
URL: http://svn.apache.org/viewvc?rev=1215361&view=rev Log: Bug 52333 - Reduce overhead in calculating SampleResult#nanoTimeOffset Use a background thread to calculate the offset instead of doing it each sample Modified: jmeter/trunk/bin/jmeter.properties jmeter/trunk/src/core/org/apache/jmeter/samplers/SampleResult.java jmeter/trunk/test/src/org/apache/jmeter/samplers/TestSampleResult.java jmeter/trunk/xdocs/changes.xml jmeter/trunk/xdocs/usermanual/listeners.xml
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/2679