Mailing-List: contact user-help@jmeter.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "JMeter Users List" <user@jmeter.apache.org>
Received-SPF: pass (nike.apache.org: domain of woolfel@gmail.com designates
 209.85.212.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <C15776B3-2B5C-4120-9AA6-4211A69DF213@gmail.com>
References: 
 <CAK22BipkfW=EOp27BaOuEBme9FBpyF9UA86kEdW-6bnm5pLXpg@mail.gmail.com>
	<CA+b7NVXTh0_3grjfyQ-33FBuqw8C7=JDE7fzsqxv8EdSqfH7bw@mail.gmail.com>
	<CAK22Bir25SMiX_4n1xmu7bR0Tw_kfxWBnz6mVRHyrKqgWbPyeQ@mail.gmail.com>
	<CA+b7NVX78X+F1NkPjvSzYqW-4p2wD8-eK1KUKpb+K6-Zr4jYOg@mail.gmail.com>
	<CAKv2g8cf7hkp1kJ0+JOQoa-USpQpLeGk0nAnH3WWA8M5xCk-NA@mail.gmail.com>
	<CA+b7NVVgzSQOrwy11_Um3=CJGfGkWBEpgjpUs+hDKwmFgg8bCg@mail.gmail.com>
	<CAKv2g8dhNkT+tUNP7vedyb=dDmxeNTFH4qc-RxD29NX9fFeFgg@mail.gmail.com>
	<CAOGo0VbT5YmiEqoQ-Q5EZ=DO4dWf-T0H7H9-xeB-+k4PaW9r2A@mail.gmail.com>
	<F38E3631-31EC-4985-AF83-4AF98E530F37@gmail.com>
	<CAKv2g8djYXk5PO-vfSv8vuJzxyf8w5qupMRia7PvggJeVWoYhw@mail.gmail.com>
	<C15776B3-2B5C-4120-9AA6-4211A69DF213@gmail.com>
Date: Wed, 14 Dec 2011 10:40:51 -0500
Message-ID: 
 <CAKv2g8eaOgRkZkmqV8m_7bbDzrQE_-gd2u+VCTXu4hq9aUxi3w@mail.gmail.com>
Subject: Re: Performance OpenJDK compared with SunJDK
From: Peter Lin <woolfel@gmail.com>
To: JMeter Users List <user@jmeter.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Great discussion by the way.

Before I talked to henrik, I had no clue how complex timers are in the
JVM. It was too much info to fit in my brain and got GC-ed. I can only
imagine what Azul is seeing with their hardware.

On Wed, Dec 14, 2011 at 10:33 AM, Kirk <kirk.pepperdine@gmail.com> wrote:
> Well, I'm not sure why he's seeing a difference in performance. I've not =
spoken to Henrik about timers so I can't comment on what he's telling you. =
I can only say that there is currently an open CR w.r.t monotonic timers an=
d there is some discussion on the subject in the CR. I've also spoken to Cl=
iff Click about Azul timers and to point to the confusion here.. he was cer=
tain that the JDK was using the TSC, something that I was told by Charlie H=
unt wasn't the case. So I went digging to find out which of these two was r=
ight. Turns out the answer is pretty complicated as it really depends on th=
e OS and what the hardware has. RedHat was the last to touch the OpenJDK ti=
mer code and they did so only in the Linux build and only to have the high =
res timer used if it was available.
>
> Not a very clear picture.. and all of these timers come with their own se=
t of faults.. which could be worked around if only we knew which one was be=
ing used =A0;-)
>
> And to add to the confusion is thread scheduler efficiency which comes in=
to play.... and I'm very suspicious of hypervisor interference with thread =
scheduling.Azul has found some very very weird (almost harmonic) interferen=
ce patterns that can adversely =A0affect the ability to utilize cores. With=
out access to proper counters it's almost impossible to say for sure whats =
going on.
>
> Regards,
> Kirk
>
> On Dec 14, 2011, at 4:09 PM, Peter Lin wrote:
>
>> 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 schedul=
er.
>>
>> 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.pepperdine@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 especiall=
y 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 cou=
nt of clocks would cause drift. currentTimeMillis relying on a RTC would ha=
ve smaller amounts of drift which would only be noticed between machines (w=
hich would be correct with NTP). So your correction of drift would be consi=
stent 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 someth=
ing similar (due to complaints from gamers) but I'm not aware of the detail=
s.
>>>
>>> Regards,
>>> Kirk
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
>>> For additional commands, e-mail: user-help@jmeter.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
>> For additional commands, e-mail: user-help@jmeter.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> For additional commands, e-mail: user-help@jmeter.apache.org
>

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