You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Gary Gregory <ga...@gmail.com> on 2019/06/06 21:13:22 UTC
Re: org.apache.commons.lang3.time.StopWatch resolution
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 <er...@me.com.invalid>
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: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>
Re: org.apache.commons.lang3.time.StopWatch resolution
Posted by Erwin Hogeweg <er...@me.com.INVALID>.
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 <er...@me.com.invalid>
> 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 <re...@gmail.com> 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 <ga...@gmail.com> 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 <er...@me.com.invalid>
>>> 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: user-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: user-help@commons.apache.org
>>>>
>>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: org.apache.commons.lang3.time.StopWatch resolution
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
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 <er...@me.com.invalid>
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 <re...@gmail.com> 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 <ga...@gmail.com> 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 <er...@me.com.invalid>
>> 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: user-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: user-help@commons.apache.org
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: org.apache.commons.lang3.time.StopWatch resolution
Posted by Erwin Hogeweg <er...@me.com.INVALID>.
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 <re...@gmail.com> 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 <ga...@gmail.com> 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 <er...@me.com.invalid>
>> 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: user-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: user-help@commons.apache.org
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: org.apache.commons.lang3.time.StopWatch resolution
Posted by Remko Popma <re...@gmail.com>.
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 <ga...@gmail.com> 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 <er...@me.com.invalid>
> 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: user-unsubscribe@commons.apache.org
>> For additional commands, e-mail: user-help@commons.apache.org
>>
>>