Bug 52333

Summary: Reduce overhead in calculating SampleResult#nanoTimeOffset
Product: JMeter Reporter: Sebb <sebb>
Component: MainAssignee: JMeter issues mailing list <issues>
Severity: enhancement    
Priority: P2    
Version: 2.5.1   
Target Milestone: ---   
Hardware: PC   
OS: All   

Description Sebb 2011-12-14 17:57:13 UTC
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.
Comment 1 Sebb 2011-12-14 19:55:00 UTC
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.
Comment 2 Sebb 2011-12-17 00:17:01 UTC
URL: http://svn.apache.org/viewvc?rev=1215361&view=rev
Bug 52333 - Reduce overhead in calculating SampleResult#nanoTimeOffset
Use a background thread to calculate the offset instead of doing it each sample