Centuries ago, Nostradamus foresaw when Paul Brannan <pbrannan / atdesk.com> would write: > On Fri, Jun 07, 2002 at 10:57:14PM +0900, Dossy wrote: >> Out of curiousity: what are you doing that requires such precise >> periodic execution? Embedded software for a pacemaker? :-) > > Five milliseconds of drift is a lot of drift, even for a non-real-time > application, as it only takes 200 iterations to lose a second. It's not > so important to me that I have precise periodic execution, but more so > that over the course of an hour I get exactly 3600 events (with 5 ms of > drift, I would get roughly 3572 events). I suppose it's not critical, > but it makes analyzing my log files a lot easier. If you strictly _need_ that kind of accuracy, then you'll need to design your process in keeping with that. What you'd need would be to have part of that "scheduler" that tracks how much things are drifting, and waiting/acting-early in order to adjust for the drift. If the only granularity that you've got is something that will do something looking like sleep(1), with resolution of 1 second, you can'd do anything better than to be within a second. If, in contrast, you could live with events every 10 seconds, you can do quite a lot better. Something with pseudocode sort of like: # This isn't really ruby, but it's not anything else either... start = time.stamp() # Measured in milliseconds interval = 10 next = start + interval loop do now = time.stamp() wait_period = Integer(next - now) # How long do we need to wait? next = next + interval sleep(wait_period) do_whatever() end The point of the calculations is that you're always calculating how long each interval needs to be. If there is some regular drift, whereby the average "sleep" needs to be 9.5 seconds, then it's likely that there will be a rough alternation between 9 and 10 second intervals. This actually ought to work _marginally_ acceptably even with 1 second intervals; what will likely happen is for there to be a set of sleep() calls with for 0, 1, and _maybe, sometimes_ 2 seconds. Unfortunately, with the very low resolution, that'll jitter all around. The larger the number of time intervals that you have to work with, the less jittery it should be. - If you can sleep for intervals measured in milliseconds, then you can get a pretty steady result when trying to get 1 second intervals, as there shouldn't be need to get off by more than a millisecond or two. - If you can sleep for intervals measured in seconds, and want 10 second intervals, you ought to be able to stay within 1s. That's much less satisfactory than with ms intervals. - Trying to be within 1s with 1s sleep() intervals is going to be highly jittery. -- (concatenate 'string "aa454" "@freenet.carleton.ca") http://www3.sympatico.ca/cbbrowne/linuxxian.html Why are men like blenders? You need one, but you're not quite sure why.