in reply to Re: Re: Reasonably accurate timing
in thread Reasonably accurate timing

That's what hard is supposed to be for (not adding interval after, but before). Make sure you include Time::HiRes. From the manpage:
If the "hard" flag is set, the event will be queued for execution relative to the last time the callback was invoked. However, if "hard" is false the new timeout will be calculated relative to the current time (this is the default).

If you set repeat and hard, it shouldn't creep. I start up my samplers parked, set the at and interval, and then start them.

How fast are you getting callbacks? If you are taking too long in some of the callbacks, you could bump the callback time. Make sure that your callback action can never overlap the next callback by either speeding up the callback or slowing down the rate. Also, you might try setting debugging on either globally or on the watcher; there are diagnostics printed as to the actual times between callbacks, etc.

Replies are listed 'Best First'.
Re: Re: Re: Re: Reasonably accurate timing
by traveler (Parson) on Jul 24, 2001 at 02:11 UTC
    My callbacks take .6 seconds and happen every 60 seconds -- little chance of overlap. Actually I had put in debugging diags to find this out... I used lhoward's solution below for now and I'll look at Event again in a little while. I have other uses for Event, so I want to get to know it better. The reason I did not use sleep subtracting the function time in the first place is that I was unaware of Time::HiRes.

    Thanks for the help and for telling me about Event and Time::HiRes.