On 29/11/06, Ian Lynagh wrote:

On Wed, Nov 22, 2006 at 03:37:05PM +0000, 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