On 10 November 2010 07:26, Andrej van der Zee <[email protected]> wrote: > Hi Sebb, > > Thanks for your reply. > >> >> JMeter saves both System.currentTimeMillis() and System.nanoTime() at >> the start of a run. >> >> It then uses System.nanoTime() differences to arrive at the current >> time with a resolution of 1ms. >> >> System.nanoTime() Javadoc says "The value returned represents >> nanoseconds since some fixed but arbitrary time". >> >> If this is not true, or if the nanosecond clock is not very accurate, >> then of course the JMeter timestamps can drift. >> > > Will give it a try if given the time.
I tried a simple program comparing systemTime and nanoTime, and found that it does seem to drift (WinXP/Java1.6). This is not the impression one gets from the Javadoc... Maybe the base times need to be regenerated more frequently - perhaps even every sample, leaving the nanotime just for elapsed time. Maybe even support just systemTime. (Might be best to make the changed implementation(s) optional.) >> Are you running in a virtual environment? Some are known to have timer >> issues. > > No, its a dedicated system. > > Windump (windows version of tcpdump) also has problems on the same > machine. For one real-time hour it only shows packets for about 10 > minutes. The reason was that windump uses performance counters on > Windows XP for assessing the difference in time from the start of the > capture and the current time. So the real clock is only read at the > beginning of the capture and from there on the differences are added, > like for JMeter. This caused the drift but luckily a registry setting > solved this issue. > > On the same system we have this problem for JMeter, yet unsolved. If > my boss gives me time to change the source-code, I will report the > results to you. > > Thank you, > Andrej > > --------------------------------------------------------------------- > 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]
