thanks kirk for digging up those details.

My memory is faulty, but that is basically what henrik told me back in
2006/2007. I had noticed a difference between System.currentTimeMillis
and System.nanoTime on all JVM (sun, jrockit, ibm). Digging deeper,
henrik explained to me that windows uses the high performance timer,
which is considerably faster than linux timer.

I agree that more threads results in more pressure on the thread scheduler.

what got me curious is the user sees a difference between openJDK and
sunJDK. perhaps there is some other process running on that linux
system contributing to the extra CPU load.


On Wed, Dec 14, 2011 at 10:00 AM, Kirk <kirk.pepperd...@gmail.com> wrote:
>>
>>
>> Unfortunately it turns out that nanoTime drifts quite badly relative
>> to currentTimeMillis, so currentTimeMillis has to be used to anchor
>> that drift.
>> Otherwise the times just don't add up properly.
>>
>> The JMeter property "sampleresult.useNanoTime" can be set to "false"
>> to disable the use of nanoTime.
>
> Right, if nanoTime in Windows uses a TSC I would expect drift especially on 
> newer processors. Not all cores receive all clocks and since the value in the 
> TSC * CPu frequency is the current time, not having an accurate count of 
> clocks would cause drift. currentTimeMillis relying on a RTC would have 
> smaller amounts of drift which would only be noticed between machines (which 
> would be correct with NTP). So your correction of drift would be consistent 
> with this. On Solaris, the drift between the TOD clock and the TSC is correct 
> after a 1ms drift 125us at a time. I think MS has attempted something similar 
> (due to complaints from gamers) but I'm not aware of the details.
>
> Regards,
> Kirk
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
> For additional commands, e-mail: user-h...@jmeter.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
For additional commands, e-mail: user-h...@jmeter.apache.org

Reply via email to