GHC concurrency runtime "breaks" every 497 (and a bit) days
In investigating ways of getting less jitter in the GHC concurrency runtime I've found the following issue: The GHC concurrency model does all of its time calculations in "ticks" - a tick being fixed at 1/50th of a second. It performs all of these calculations in terms the number of these ticks since the Unix epoch (Jan 1970). Which is stored as an Int - unfortunately this 2^31 bits overflows every 497 (and a bit) days. When it does overflow any threads on the timer queue will either a) run immediately or b) not be run for another 497 days - depending on which way the sign changes. Also any timer calculation that spans the wrapround will not be dealt with correctly. Although this doesn't happen often (the last one was around Sat Sep 30 18:32:51 UTC 2006 and the next one will not be until Sat Feb 9 21:00:44 UTC 2008) I don't think we can leave this sort of issue in the run-time system. Take a look at the definition of getTicksofDay (in base/include/HsBase.h (non-windows) / base/cbits/Win32Utils.c) and getDelay (in base/GHC/Conc.lhs) to understand the details of the issue. I don't mind having a go at the base system to remove this problem - but before I do I would like to canvas some opinions. I'll do that in a separate thread. Neil
Neil Davies wrote:
In investigating ways of getting less jitter in the GHC concurrency runtime I've found the following issue:
The GHC concurrency model does all of its time calculations in "ticks" - a tick being fixed at 1/50th of a second. It performs all of these calculations in terms the number of these ticks since the Unix epoch (Jan 1970). Which is stored as an Int - unfortunately this 2^31 bits overflows every 497 (and a bit) days.
When it does overflow any threads on the timer queue will either a) run immediately or b) not be run for another 497 days - depending on which way the sign changes. Also any timer calculation that spans the wrapround will not be dealt with correctly.
Although this doesn't happen often (the last one was around Sat Sep 30 18:32:51 UTC 2006 and the next one will not be until Sat Feb 9 21:00:44 UTC 2008) I don't think we can leave this sort of issue in the run-time system.
Take a look at the definition of getTicksofDay (in base/include/HsBase.h (non-windows) / base/cbits/Win32Utils.c) and getDelay (in base/GHC/Conc.lhs) to understand the details of the issue.
I don't mind having a go at the base system to remove this problem - but before I do I would like to canvas some opinions. I'll do that in a separate thread.
I answer but on this thread because IMO the overflow is a /much/ more serious problem than the jitter due to unnecessarily coarse rounding. Fortunately both can be solved together, by using 64 bit timestamps and the highest available resolution. In my experience avoiding overflow by using enough bits is a lot more reliable than any trick to 'handle' overflow. With 64 bit timestamps, even if the base resolution is as small as one nanosecond (which is lot more than you get on stock hardware even if you use raw hardware timers), you still get overflow only every 585 years which I would deem acceptable for all practical purposes. BTW, the timer resolution should be available as a (platform dependent) constant. Maybe it would even be useful to define a simple external interface (to the RTS, i.e. in C) so that advanced users may plug in e.g. extra hardware timers for ultimate resolution. Cheers Ben
I've prototyped a fix for this issue which will now only wrap every 585,000 years or so. It also removes the 1/50th of a second timer resolution for the runtime. This means that the additional 20ms (or thereabouts) of delay in the wakeup has gone. This means that GHC is now on a par with any other program, i.e. down to the resolution of the jiifies within the O/S. I've done the non-Windows branch of the GHC.Conc - but I'll need some help with the windows branch. Anyone out there able to help with the intricacies of Windows? Neil
Neil Davies wrote:
I've prototyped a fix for this issue which will now only wrap every 585,000 years or so. It also removes the 1/50th of a second timer resolution for the runtime. This means that the additional 20ms (or thereabouts) of delay in the wakeup has gone.
This means that GHC is now on a par with any other program, i.e. down to the resolution of the jiifies within the O/S.
I've done the non-Windows branch of the GHC.Conc - but I'll need some help with the windows branch.
Anyone out there able to help with the intricacies of Windows?
Thanks Neil, just submit your patch and we'll look into making similar changes on Windows. Cheers, Simon
participants (3)
-
Benjamin Franksen -
Neil Davies -
Simon Marlow