Hi Lauren,

thanks for the explanation!

I tried it on my machine, but unfortunately the test it a bit brittle now, there's a good chance that it fails when I cause a high load on the VM, for instance by moving my cursor around very fast. I'm not sure what is a good trade-off between precision and reliability here ... It would be nice if the test also passed on my raspi reliably. What do you think? Would 1100 milliSeconds be okay-ish for you, too? :)

(FYIO, I found a bug in #busyWait for durations < 1 milliSecond, see fix-busyWait-precision.1.cs for more details. :-))

Best,
Christoph

---
Sent from Squeak Inbox Talk

On 2022-03-28T18:11:27+00:00, drurowin at gmail.com wrote:

> Hi Christoph,
> 
> On 3/25/22 17:57, Thiede, Christoph wrote:
> > thanks for the patch! :-) Just as a comprehension question, what are the rounding errors you are talking about and why did you insert a #roundTo: in the test?
> With #busyWait the timing isn't perfect, so the actual delay is 1
> millisecond plus or minus some nanoseconds.  Those nanosecond
> differences are the round-off error, and they can add up to be a
> millisecond or more up and down*.
> 
> The #roundTo: makes passing duration be
>     997.5 <= elapsed < 1002.5
> instead of
>     998.0 <= elapsed <= 1002.0
> 
> I was getting a significant number of 997.9999 elapsed times out of
> testing so I put in the #roundTo:.
> 
> *  While I was testing, a good 50% of the elapsed times were between 998
> and 999 milliseconds, over the course of around 1000 iterations.  The
> minimum was the strangely low 990 milliseconds.
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220328/b0e1ebf1/attachment.html>