Thanks all for the contribution to the issue, Next week I will launch again the same test, and I will add GCLogs to Jmeter, and I will compare GC results for both cases to see if really the JVM is working different.
Thks, Toni El 14/12/2011, a las 16:40, Peter Lin <wool...@gmail.com> escribió: > 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.pepperd...@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 and >> there is some discussion on the subject in the CR. I've also spoken to Cliff >> Click about Azul timers and to point to the confusion here.. he was certain >> that the JDK was using the TSC, something that I was told by Charlie Hunt >> wasn't the case. So I went digging to find out which of these two was right. >> Turns out the answer is pretty complicated as it really depends on the OS >> and what the hardware has. RedHat was the last to touch the OpenJDK timer >> 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 set >> of faults.. which could be worked around if only we knew which one was being >> used ;-) >> >> And to add to the confusion is thread scheduler efficiency which comes into >> play.... and I'm very suspicious of hypervisor interference with thread >> scheduling.Azul has found some very very weird (almost harmonic) >> interference patterns that can adversely affect the ability to utilize >> cores. Without 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 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 >>> >> >> >> --------------------------------------------------------------------- >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
