[Haskell-cafe] Re: help with threadDelay
Ian Lynagh wrote: [moving to glasgow-haskell-bugs] On Wed, Nov 15, 2006 at 11:40:12PM +, Neil Davies wrote: however when -threaded is used you get some interesting effects, including returning too early: Tgt/Actual = 0.000125/0.34s, diff = -0.91s Thanks for the report; I can reproduce it on Linux/amd64. OK, so the bug here is that threadDelay n might return after less than n microseconds. This looks like it's caused by truncation problems when converting times to ticks (where a tick is 1/50 of a second), e.g. while trying to sleep for 1.953125s one run started at 1164157960.773726s which is (Int) 1164157960 * 50 + 773726 * 50 / 100 = (Int) 58207898038.6863 = 58207898038 ticks and woke the thread up at 1164157962.708609s which is (Int) 1164157962 * 50 + 708609 * 50 / 100 = (Int) 58207898135.4305 = 58207898135 ticks The difference is 58207898135 - 58207898038 = 97 ticks. Meanwhile we're trying to sleep for (Int) 50 * 1.953125 = (Int) 97.65625 = 97 ticks However, 1164157962.708609s - 1164157960.773726s = 1.93488311767578s which is 0.0182418823242201s too short. The problem is that we have counted 0.6863 ticks before the start time, not counted 0.4305 ticks before the finish time and have been waiting 0.65625 ticks too short a time. Thus we have counted (0.6863-0.4305 + 0.65625) / 50 == 0.018241 too much time. I think the answer is that let target = now + usecs `quot` tick_usecs in GHC/Conc.lhs should be let target = 1 + now + (usecs + tick_usecs - 1) `quot` tick_usecs I'm also a bit dubious about the use of the constant "50" for the number of ticks per second, but the results with +RTS -V0.001 don't look any more wrong so perhaps I just need to get some sleep. The hardcoded 50 in GHC/Conc.lhs matches up with TICK_FREQ in libraries/base/includes/HsBase.h. It could probably be made larger without any ill effects. I agree that we should round up the target time to the nearest tick rather than rounding down, though. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: help with threadDelay
Ian/Simon(s) Thanks - looking forward to the fix. It will help with the real time enviroment that I've got. Follow on query: Is there a way of seeing the value of this interval from within the Haskell program? Helps in the calibration loop. Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: help with threadDelay
On Wed, Nov 22, 2006 at 03:37:05PM +, Neil Davies wrote: > Ian/Simon(s) Thanks - looking forward to the fix. I've now pushed it to the HEAD. > It will help with the real time enviroment that I've got. Lazy evaluation and GHC's garbage collector will probably cause headaches if you want true real time stuff. > Follow on query: Is there a way of seeing the value of this interval > from within the Haskell program? Helps in the calibration loop. I don't follow - what interval do you want to know? You can't find out how long threadDelay took, but the lower bound (in a correct implementation) is what you ask for and the upper bound is what you get by measuring it, as you did in your original message. Thanks Ian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: help with threadDelay
On 29/11/06, Ian Lynagh <[EMAIL PROTECTED]> wrote: On Wed, Nov 22, 2006 at 03:37:05PM +, Neil Davies wrote: > Ian/Simon(s) Thanks - looking forward to the fix. I've now pushed it to the HEAD. Thanks - I'll pull it down and give it a try. > It will help with the real time enviroment that I've got. Lazy evaluation and GHC's garbage collector will probably cause headaches if you want true real time stuff. So the wisdom goes, but I decided to try it and it works really nicely. Yes, the GC can introduce additional "jitter", but I can arrange for GC's to be performed at times more convinient and not on the time critical path. I'm reliably able to get sub-millisecond jitter in the wakeup times - which is fine for the application. Laziness is fine - It'll help later when I can arrange evaluation outside the time critical path. Yea, I'd love a non-locking, incremental GC that returned within a fixed (configurable) time - but until that time > Follow on query: Is there a way of seeing the value of this interval > from within the Haskell program? Helps in the calibration loop. I don't follow - what interval do you want to know? You can't find out how long threadDelay took, but the lower bound (in a correct implementation) is what you ask for and the upper bound is what you get by measuring it, as you did in your original message. I was trying to find out (in the running haskell) the value supplied by (for example) -V RTS flag. In order to get low jitter you have to deliberately wake up early and spin - hey what are all these extra cores for! - knowing the quantisation of the RTS is useful in calibration loop for how much to wake up early. Thanks Ian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: help with threadDelay
On Wed, Nov 29, 2006 at 10:57:52AM +, Neil Davies wrote: > > In order to get low jitter you have to deliberately wake up early and > spin - hey what are all these extra cores for! - knowing the > quantisation of the RTS is useful in calibration loop for how much to > wake up early. Ah, I see. Timing how long a threadDelay 1 takes and subtracting that from future threadDelays is probably the best answer. Thanks Ian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
