On Sun, Mar 13, 2016 at 9:27 AM, Ben Coman <b...@openinworld.com> wrote:
> > > 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 > P.S. I'm curious how you came to notice this. I have a long term interest in Pharo as a soft-real time industrial control system, motion control system and robotics. One option is using a protocol like EtherCAT which at the hardware level does microsecond time synchronisation of all nodes on the network, and every measurement is microsecond timestamped in the node before it is sent to the control system. So your motion control algorithms can work with an extremely accurate timestamp of *exactly* when a measurement was taken, rather than when the measurement arrived at the control program which is dependent on the delay and jitter vagaries of communications hardware and CPU scheduling of the network stack and control programs.
