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. > 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]
