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 <[email protected]> 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 <[email protected]> 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: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
