Re: org.apache.commons.lang3.time.StopWatch resolution
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 > 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 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 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 >>> 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
Re: org.apache.commons.lang3.time.StopWatch resolution
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 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 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 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 >> 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
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 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 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 >> 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
