You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by Andrej van der Zee <an...@gmail.com> on 2010/11/09 13:43:37 UTC
timestamps out of sync with system clock
Hi,
We experienced that JMeter's timestamps get out-of-sync with the
system clock. Is it true that JMeter does not read the system clock,
but uses performance counters or something like that to calculate the
difference between the start time and the current time? If so, can I
overwrite this behavior and force JMeter to use the system clock
instead? The platform is Windows XP.
Thank you,
Andrej
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: timestamps out of sync with system clock
Posted by sebb <se...@gmail.com>.
On 29 November 2010 00:11, Andrej van der Zee <an...@gmail.com> wrote:
> Hi,
>
> Thank you so much.
>
> I know it is a difficult question, but is there anything to say about
> the stability of these nightly builds?
The nightly builds come with no guarantees.
> Or is there an upcoming
> official release date?
Sorry, there is no release date planned at present.
However, you can easily build the code yourself. You just need Ant and
JDK 1.5 or later.
> Cheers,
> Andrej
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: timestamps out of sync with system clock
Posted by Andrej van der Zee <an...@gmail.com>.
Hi,
Thank you so much.
I know it is a difficult question, but is there anything to say about
the stability of these nightly builds? Or is there an upcoming
official release date?
Cheers,
Andrej
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: timestamps out of sync with system clock
Posted by sebb <se...@gmail.com>.
On 27 November 2010 22:14, Andrej van der Zee <an...@gmail.com> wrote:
> Hi,
>
> Is the fix an added option? What is the default?
The default is to use nanoTime, but resetting the baseline for each sample.
Define
sampleresult.useNanoTime=false
to use currentTimeMillis only.
> In the coming weeks we will try to test it at our client's site and post the results.
>
> Thank you!
> Andrej
>
>
>
>
> On 2010/11/28, at 3:51, sebb <se...@gmail.com> wrote:
>
>> On 27 November 2010 18:50, sebb <se...@gmail.com> wrote:
>>> On 20 November 2010 11:32, sebb <se...@gmail.com> wrote:
>>>> On 20 November 2010 11:28, Andrej van der Zee <an...@gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>>
>>>>>>
>>>>>> Nanotime was added to try and provide additional resolution - looks
>>>>>> like it causes more problems than it solves...
>>>>>
>>>>> Is this recently added? Are there older JMeter versions that use
>>>>> currentTimeMillis only?
>>>>
>>>> Only very old ones.
>>>>
>>>>>>
>>>>>> I think the options are:
>>>>>>
>>>>>> currentTimeMillis only
>>>>>> Use cTM for start (or end) timestamp, and use differential nanoTime for elapsed.
>>>>>>
>>>>>> The second option is as at present, but without storing the fixed base time.
>>>>>> There cannot then be any accumulation of drift.
>>>>>>
>>>>>
>>>>> Would solve our problems.
>>>>
>>>> I'll try and get a nightly build out soon.
>>>
>>> Builds after r1037933 have the fix.
>>
>> Oops - I meant builds from (and including) r1037933 have the fix.
>>
>>>>> Cheers,
>>>>> Andrej
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>>>>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>>>>
>>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: timestamps out of sync with system clock
Posted by Andrej van der Zee <an...@gmail.com>.
Hi,
Is the fix an added option? What is the default?
In the coming weeks we will try to test it at our client's site and post the results.
Thank you!
Andrej
On 2010/11/28, at 3:51, sebb <se...@gmail.com> wrote:
> On 27 November 2010 18:50, sebb <se...@gmail.com> wrote:
>> On 20 November 2010 11:32, sebb <se...@gmail.com> wrote:
>>> On 20 November 2010 11:28, Andrej van der Zee <an...@gmail.com> wrote:
>>>> Hi,
>>>>
>>>>
>>>>>
>>>>> Nanotime was added to try and provide additional resolution - looks
>>>>> like it causes more problems than it solves...
>>>>
>>>> Is this recently added? Are there older JMeter versions that use
>>>> currentTimeMillis only?
>>>
>>> Only very old ones.
>>>
>>>>>
>>>>> I think the options are:
>>>>>
>>>>> currentTimeMillis only
>>>>> Use cTM for start (or end) timestamp, and use differential nanoTime for elapsed.
>>>>>
>>>>> The second option is as at present, but without storing the fixed base time.
>>>>> There cannot then be any accumulation of drift.
>>>>>
>>>>
>>>> Would solve our problems.
>>>
>>> I'll try and get a nightly build out soon.
>>
>> Builds after r1037933 have the fix.
>
> Oops - I meant builds from (and including) r1037933 have the fix.
>
>>>> Cheers,
>>>> Andrej
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>>>
>>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: timestamps out of sync with system clock
Posted by sebb <se...@gmail.com>.
On 27 November 2010 18:50, sebb <se...@gmail.com> wrote:
> On 20 November 2010 11:32, sebb <se...@gmail.com> wrote:
>> On 20 November 2010 11:28, Andrej van der Zee <an...@gmail.com> wrote:
>>> Hi,
>>>
>>>
>>>>
>>>> Nanotime was added to try and provide additional resolution - looks
>>>> like it causes more problems than it solves...
>>>
>>> Is this recently added? Are there older JMeter versions that use
>>> currentTimeMillis only?
>>
>> Only very old ones.
>>
>>>>
>>>> I think the options are:
>>>>
>>>> currentTimeMillis only
>>>> Use cTM for start (or end) timestamp, and use differential nanoTime for elapsed.
>>>>
>>>> The second option is as at present, but without storing the fixed base time.
>>>> There cannot then be any accumulation of drift.
>>>>
>>>
>>> Would solve our problems.
>>
>> I'll try and get a nightly build out soon.
>
> Builds after r1037933 have the fix.
Oops - I meant builds from (and including) r1037933 have the fix.
>>> Cheers,
>>> Andrej
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: timestamps out of sync with system clock
Posted by sebb <se...@gmail.com>.
On 20 November 2010 11:32, sebb <se...@gmail.com> wrote:
> On 20 November 2010 11:28, Andrej van der Zee <an...@gmail.com> wrote:
>> Hi,
>>
>>
>>>
>>> Nanotime was added to try and provide additional resolution - looks
>>> like it causes more problems than it solves...
>>
>> Is this recently added? Are there older JMeter versions that use
>> currentTimeMillis only?
>
> Only very old ones.
>
>>>
>>> I think the options are:
>>>
>>> currentTimeMillis only
>>> Use cTM for start (or end) timestamp, and use differential nanoTime for elapsed.
>>>
>>> The second option is as at present, but without storing the fixed base time.
>>> There cannot then be any accumulation of drift.
>>>
>>
>> Would solve our problems.
>
> I'll try and get a nightly build out soon.
Builds after r1037933 have the fix.
>> Cheers,
>> Andrej
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: timestamps out of sync with system clock
Posted by sebb <se...@gmail.com>.
On 20 November 2010 11:28, Andrej van der Zee <an...@gmail.com> wrote:
> Hi,
>
>
>>
>> Nanotime was added to try and provide additional resolution - looks
>> like it causes more problems than it solves...
>
> Is this recently added? Are there older JMeter versions that use
> currentTimeMillis only?
Only very old ones.
>>
>> I think the options are:
>>
>> currentTimeMillis only
>> Use cTM for start (or end) timestamp, and use differential nanoTime for elapsed.
>>
>> The second option is as at present, but without storing the fixed base time.
>> There cannot then be any accumulation of drift.
>>
>
> Would solve our problems.
I'll try and get a nightly build out soon.
> Cheers,
> Andrej
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: timestamps out of sync with system clock
Posted by Andrej van der Zee <an...@gmail.com>.
Hi,
>
> Nanotime was added to try and provide additional resolution - looks
> like it causes more problems than it solves...
Is this recently added? Are there older JMeter versions that use
currentTimeMillis only?
>
> I think the options are:
>
> currentTimeMillis only
> Use cTM for start (or end) timestamp, and use differential nanoTime for elapsed.
>
> The second option is as at present, but without storing the fixed base time.
> There cannot then be any accumulation of drift.
>
Would solve our problems.
Cheers,
Andrej
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: timestamps out of sync with system clock
Posted by sebb <se...@gmail.com>.
On 19 November 2010 04:03, Andrej van der Zee <an...@gmail.com> wrote:
> Hi,
>
>>
>> I would prefer an option that gets the time ether from
>> currentTimeMillis() or from nanoTime(). On windows, the latter gets
>> its value from the QueryPerformanceCounter() API which causes the
>> drift from the system-clock.
>>
>
> On few particular machines we have seen a drift that is very extreme
> and it showed that nanoTime() did not give correct elapsed times too.
> Therefor in our case, we strongly prefer an option that switches of
> nanoTime() completely and use currentTimeMillis() instead, for
> timestamps and also for elapsed time calculation. Such an option would
> be very much appreciated. Also, we rely on the system-clock for
> comparison with other tools such as tcpdump, therefore we really need
> an implementation based on currentTimeMillis() only.
Nanotime was added to try and provide additional resolution - looks
like it causes more problems than it solves...
I think the options are:
currentTimeMillis only
Use cTM for start (or end) timestamp, and use differential nanoTime for elapsed.
The second option is as at present, but without storing the fixed base time.
There cannot then be any accumulation of drift.
> Best regards,
> Andrej
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: timestamps out of sync with system clock
Posted by Andrej van der Zee <an...@gmail.com>.
Hi,
>
> I would prefer an option that gets the time ether from
> currentTimeMillis() or from nanoTime(). On windows, the latter gets
> its value from the QueryPerformanceCounter() API which causes the
> drift from the system-clock.
>
On few particular machines we have seen a drift that is very extreme
and it showed that nanoTime() did not give correct elapsed times too.
Therefor in our case, we strongly prefer an option that switches of
nanoTime() completely and use currentTimeMillis() instead, for
timestamps and also for elapsed time calculation. Such an option would
be very much appreciated. Also, we rely on the system-clock for
comparison with other tools such as tcpdump, therefore we really need
an implementation based on currentTimeMillis() only.
Best regards,
Andrej
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: timestamps out of sync with system clock
Posted by Andrej van der Zee <an...@gmail.com>.
Hi,
>
> 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.)
I would prefer an option that gets the time ether from
currentTimeMillis() or from nanoTime(). On windows, the latter gets
its value from the QueryPerformanceCounter() API which causes the
drift from the system-clock.
Please keep me (us) informed!
Cheers,
Andrej
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: timestamps out of sync with system clock
Posted by sebb <se...@gmail.com>.
On 10 November 2010 07:26, Andrej van der Zee <an...@gmail.com> 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: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: timestamps out of sync with system clock
Posted by Andrej van der Zee <an...@gmail.com>.
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: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: timestamps out of sync with system clock
Posted by sebb <se...@gmail.com>.
On 9 November 2010 12:43, Andrej van der Zee <an...@gmail.com> wrote:
> Hi,
>
> We experienced that JMeter's timestamps get out-of-sync with the
> system clock. Is it true that JMeter does not read the system clock,
> but uses performance counters or something like that to calculate the
> difference between the start time and the current time? If so, can I
> overwrite this behavior and force JMeter to use the system clock
> instead? The platform is Windows XP.
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.
Are you running in a virtual environment? Some are known to have timer issues.
There's no option to change the JMeter behaviour currently, but of
course you can always edit the source, in this case
org.apache.jmeter.samplers.SampleResult
And you can raise a Bugzilla enhancement request to make the use of
nanoTime optional.
> Thank you,
> Andrej
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: timestamps out of sync with system clock
Posted by Deepak Shetty <sh...@gmail.com>.
hi
JMeter does use the system clock afaik. What makes you think it doesnt or
that it is getting out of sync?
regards
deepak
On Tue, Nov 9, 2010 at 4:43 AM, Andrej van der Zee <
andrejvanderzee@gmail.com> wrote:
> Hi,
>
> We experienced that JMeter's timestamps get out-of-sync with the
> system clock. Is it true that JMeter does not read the system clock,
> but uses performance counters or something like that to calculate the
> difference between the start time and the current time? If so, can I
> overwrite this behavior and force JMeter to use the system clock
> instead? The platform is Windows XP.
>
> Thank you,
> Andrej
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>