org.apache.commons.lang3.time.StopWatch resolution

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

org.apache.commons.lang3.time.StopWatch resolution

Erwin Hogeweg-3
Hi,

I am tad confused about the StopWatch resolution. I have a very basic JUnit test that starts a stopwatch, wait for 10ms and then stops it, and checks the value. In about 40% of the cases it is less than the 10ms wait time.

Is that expected? What is my blind spot?


Regards,

Erwin
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: org.apache.commons.lang3.time.StopWatch resolution

garydgregory
The OS' clock resolution is in play here, which depending on your OS will
give you varying results. Also, on Java 9, you get better clock resolution
for certain APIs. Kinda messy...

Gary

On Thu, Jun 6, 2019 at 4:28 PM Erwin Hogeweg <[hidden email]>
wrote:

> Hi,
>
> I am tad confused about the StopWatch resolution. I have a very basic
> JUnit test that starts a stopwatch, wait for 10ms and then stops it, and
> checks the value. In about 40% of the cases it is less than the 10ms wait
> time.
>
> Is that expected? What is my blind spot?
>
>
> Regards,
>
> Erwin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: org.apache.commons.lang3.time.StopWatch resolution

Remko Popma-2
Timers and elapsed time in Java is an interesting topic. Can be a moving target though...

Some recent articles:
https://hazelcast.com/blog/locksupport-parknanos-under-the-hood-and-the-curious-case-of-parking/

https://hazelcast.com/blog/locksupport-parknanos-under-the-hood-and-the-curious-case-of-parking-part-ii-windows/

Remko.

(Shameless plug) Every java main() method deserves http://picocli.info

> On Jun 7, 2019, at 6:13, Gary Gregory <[hidden email]> wrote:
>
> The OS' clock resolution is in play here, which depending on your OS will
> give you varying results. Also, on Java 9, you get better clock resolution
> for certain APIs. Kinda messy...
>
> Gary
>
> On Thu, Jun 6, 2019 at 4:28 PM Erwin Hogeweg <[hidden email]>
> wrote:
>
>> Hi,
>>
>> I am tad confused about the StopWatch resolution. I have a very basic
>> JUnit test that starts a stopwatch, wait for 10ms and then stops it, and
>> checks the value. In about 40% of the cases it is less than the 10ms wait
>> time.
>>
>> Is that expected? What is my blind spot?
>>
>>
>> Regards,
>>
>> Erwin
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: org.apache.commons.lang3.time.StopWatch resolution

Erwin Hogeweg-3
Thanks for the replies and the links gents. Still confused. I can understand that you can’t expect nanosecond resolution but the diff I noticed is 1-6 ms... on a 10 ms interval. Those are eternities in modern day CPUs.

I am planning to use the stopwatch with a second resolution so this test is kinda irrelevant but I am still surprised by the result. I might take a look at the implementation later to get a better understanding.

Thanks again for the help.


Erwin

El jun. 6, 2019, a la(s) 22:41, Remko Popma <[hidden email]> escribió:

> Timers and elapsed time in Java is an interesting topic. Can be a moving target though...
>
> Some recent articles:
> https://hazelcast.com/blog/locksupport-parknanos-under-the-hood-and-the-curious-case-of-parking/
>
> https://hazelcast.com/blog/locksupport-parknanos-under-the-hood-and-the-curious-case-of-parking-part-ii-windows/
>
> Remko.
>
> (Shameless plug) Every java main() method deserves http://picocli.info
>
>> On Jun 7, 2019, at 6:13, Gary Gregory <[hidden email]> wrote:
>>
>> The OS' clock resolution is in play here, which depending on your OS will
>> give you varying results. Also, on Java 9, you get better clock resolution
>> for certain APIs. Kinda messy...
>>
>> Gary
>>
>> On Thu, Jun 6, 2019 at 4:28 PM Erwin Hogeweg <[hidden email]>
>> wrote:
>>
>>> Hi,
>>>
>>> I am tad confused about the StopWatch resolution. I have a very basic
>>> JUnit test that starts a stopwatch, wait for 10ms and then stops it, and
>>> checks the value. In about 40% of the cases it is less than the 10ms wait
>>> time.
>>>
>>> Is that expected? What is my blind spot?
>>>
>>>
>>> Regards,
>>>
>>> Erwin
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: org.apache.commons.lang3.time.StopWatch resolution

Bernd Eckenfels
A 10ms sleep is problematic as a test case since some OS only allow Worse Timer Resolution (for some like Windows it even depends on which timer is currently active, the default timer uses 15,6ms which is only changed in latest Windows 10 I think). So the variation you see is more likely caused by the delay you use and less likely caused by System.nanoTime (as used by Stopwatch). For your test (not sure how valuable that is) I would go with 100ms sleep and allow 85-115ms stopwatch results.


--
http://bernd.eckenfels.net

________________________________
Von: Erwin Hogeweg <[hidden email]>
Gesendet: Freitag, Juni 7, 2019 2:21 PM
An: Commons Users List
Betreff: Re: org.apache.commons.lang3.time.StopWatch resolution

Thanks for the replies and the links gents. Still confused. I can understand that you can’t expect nanosecond resolution but the diff I noticed is 1-6 ms... on a 10 ms interval. Those are eternities in modern day CPUs.

I am planning to use the stopwatch with a second resolution so this test is kinda irrelevant but I am still surprised by the result. I might take a look at the implementation later to get a better understanding.

Thanks again for the help.


Erwin

El jun. 6, 2019, a la(s) 22:41, Remko Popma <[hidden email]> escribió:

> Timers and elapsed time in Java is an interesting topic. Can be a moving target though...
>
> Some recent articles:
> https://hazelcast.com/blog/locksupport-parknanos-under-the-hood-and-the-curious-case-of-parking/
>
> https://hazelcast.com/blog/locksupport-parknanos-under-the-hood-and-the-curious-case-of-parking-part-ii-windows/
>
> Remko.
>
> (Shameless plug) Every java main() method deserves http://picocli.info
>
>> On Jun 7, 2019, at 6:13, Gary Gregory <[hidden email]> wrote:
>>
>> The OS' clock resolution is in play here, which depending on your OS will
>> give you varying results. Also, on Java 9, you get better clock resolution
>> for certain APIs. Kinda messy...
>>
>> Gary
>>
>> On Thu, Jun 6, 2019 at 4:28 PM Erwin Hogeweg <[hidden email]>
>> wrote:
>>
>>> Hi,
>>>
>>> I am tad confused about the StopWatch resolution. I have a very basic
>>> JUnit test that starts a stopwatch, wait for 10ms and then stops it, and
>>> checks the value. In about 40% of the cases it is less than the 10ms wait
>>> time.
>>>
>>> Is that expected? What is my blind spot?
>>>
>>>
>>> Regards,
>>>
>>> Erwin
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: org.apache.commons.lang3.time.StopWatch resolution

Erwin Hogeweg-3
Thanks Bernd,

See below.

> A 10ms sleep is problematic as a test case since some OS only allow Worse Timer Resolution (for some like Windows it even depends on which timer is currently active, the default timer uses 15,6ms which is only changed in latest Windows 10 I think). So the variation you see is more likely caused by the delay you use and less likely caused by System.nanoTime (as used by Stopwatch).
Interesting. Not sure about that though because I log the System.currentTimeMillis around the sleep and the diff is always 10 or more never less.

> For your test (not sure how valuable that is) I would go with 100ms sleep and allow 85-115ms stopwatch results.
I’ll give that a try.

Thanks again,

Erwin.

>
>
> --
> http://bernd.eckenfels.net
>
> ________________________________
> Von: Erwin Hogeweg <[hidden email]>
> Gesendet: Freitag, Juni 7, 2019 2:21 PM
> An: Commons Users List
> Betreff: Re: org.apache.commons.lang3.time.StopWatch resolution
>
> Thanks for the replies and the links gents. Still confused. I can understand that you can’t expect nanosecond resolution but the diff I noticed is 1-6 ms... on a 10 ms interval. Those are eternities in modern day CPUs.
>
> I am planning to use the stopwatch with a second resolution so this test is kinda irrelevant but I am still surprised by the result. I might take a look at the implementation later to get a better understanding.
>
> Thanks again for the help.
>
>
> Erwin
>
> El jun. 6, 2019, a la(s) 22:41, Remko Popma <[hidden email]> escribió:
>
>> Timers and elapsed time in Java is an interesting topic. Can be a moving target though...
>>
>> Some recent articles:
>> https://hazelcast.com/blog/locksupport-parknanos-under-the-hood-and-the-curious-case-of-parking/
>>
>> https://hazelcast.com/blog/locksupport-parknanos-under-the-hood-and-the-curious-case-of-parking-part-ii-windows/
>>
>> Remko.
>>
>> (Shameless plug) Every java main() method deserves http://picocli.info
>>
>>> On Jun 7, 2019, at 6:13, Gary Gregory <[hidden email]> wrote:
>>>
>>> The OS' clock resolution is in play here, which depending on your OS will
>>> give you varying results. Also, on Java 9, you get better clock resolution
>>> for certain APIs. Kinda messy...
>>>
>>> Gary
>>>
>>> On Thu, Jun 6, 2019 at 4:28 PM Erwin Hogeweg <[hidden email]>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I am tad confused about the StopWatch resolution. I have a very basic
>>>> JUnit test that starts a stopwatch, wait for 10ms and then stops it, and
>>>> checks the value. In about 40% of the cases it is less than the 10ms wait
>>>> time.
>>>>
>>>> Is that expected? What is my blind spot?
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Erwin
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]