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 <erwin.hoge...@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 <remko.po...@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 <garydgreg...@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 <erwin.hoge...@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-unsubscr...@commons.apache.org
>>>> For additional commands, e-mail: user-h...@commons.apache.org
>>>> 
>>>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Reply via email to