On Sun, Mar 13, 2016 at 1:47 AM, Aliaksei Syrel <alex.sy...@gmail.com> wrote:
> Hi > > At some point I got a feeling that actual Delay time is longer than > expected. It is especially visible on small delays less than 100ms > (otherwise difference is < 1%). > > [image: Inline image 1] > Documentation says that *Delay waits approximately* for specified amount > of time. However, according to experimental data an actual difference is > always positive with the value around 1.5-2 seconds. It is actually strange > where such a constant difference, independent from delay length, comes from. > [image: Inline image 2] > To conclude, if you want to wait more precisely you need to create delays > with duration 1.5 seconds less than expected. Also it would be interesting > to test on different hardwares to make sure that difference stays constant > (around 1.5-2s) > > I used the following script to gather data and save in .csv file > http://ws.stfx.eu/DSCLG2ON0VBI > > Tested on: > Pharo: #50636 > Spur-VM: #463 > OS: Mac OS Yosemite > CPU: Intel Core i7 2.39 GHz > Nice analysis. I've previously wondered about such an effect from resumptionTime being calculated by the high priority thread in #handleTimerEvent: and thus delayed by switching threads, rather than being calculated as-soon-as-possible by the low priority process when #schedule: is called. I can't remember my line of reasoning, but doing it the low priority process seemed to open the potential for nasty race conditions, so I left it as I found it. Perhaps we should take a time snapshot in the #schedule: and pass that through to #handleTimerEvent: similar to scheduledDelay. Would you like to try that? btw, I have some cleanup of DelayScheduler almost complete that I had meant to get into Pharo 5 earlier, but now I think best to wait for early Pharo 6. cheers -ben
