Hi Lauren,<br>
<br>
thanks for the explanation!<br>
<br>
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? :)<br>
<br>
(FYIO, I found a bug in #busyWait for durations < 1 milliSecond, see fix-busyWait-precision.1.cs for more details. :-))<br>
<br>
Best,<br>
Christoph<br>
<br>
<font color="#808080">---<br>
</font><font color="#808080"><i>Sent from </i></font><font color="#808080"><i><a href="https://github.com/hpi-swa-lab/squeak-inbox-talk"><u><font color="#808080">Squeak Inbox Talk</font></u></a></i></font><br>
<br>
On 2022-03-28T18:11:27+00:00, drurowin@gmail.com wrote:<br>
<br>
> Hi Christoph,<br>
> <br>
> On 3/25/22 17:57, Thiede, Christoph wrote:<br>
> > 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?<br>
> With #busyWait the timing isn't perfect, so the actual delay is 1<br>
> millisecond plus or minus some nanoseconds.  Those nanosecond<br>
> differences are the round-off error, and they can add up to be a<br>
> millisecond or more up and down*.<br>
> <br>
> The #roundTo: makes passing duration be<br>
>     997.5 <= elapsed < 1002.5<br>
> instead of<br>
>     998.0 <= elapsed <= 1002.0<br>
> <br>
> I was getting a significant number of 997.9999 elapsed times out of<br>
> testing so I put in the #roundTo:.<br>
> <br>
> *  While I was testing, a good 50% of the elapsed times were between 998<br>
> and 999 milliseconds, over the course of around 1000 iterations.  The<br>
> minimum was the strangely low 990 milliseconds.<br>
> <br>
>