```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

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.
```