in reply to Waiting for Alarm

alarm is useful to interupt other processing at a given time or regular intervals, but if you have nothing else to do but wait for the intervening period, then you are using the wrong tool. Forget alarm and use sleep.

Do something every 10 seconds:

my $deadline = time() + 10; while( 1 ) { sleep 1 while time() < $deadline; $deadline = time() +10; ## Do the something }

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Replies are listed 'Best First'.
Re^2: Waiting for Alarm
by n8ur (Acolyte) on Feb 16, 2008 at 18:08 UTC
    Using sleep (or usleep from Time::HiRes) is how I've done it in the past, but the problem is accumulating time inaccuracy do to delays in processing.

    For a bit more context, I'm taking measurements from electronic test equipment using the GPIB bus. I want to take those readings, say, every 10 seconds. The time it takes to tell the instrument to send a reading, for the instrument to process that request, and then return the result, is somewhat variable. So it's very hard to calibrate the sleep time to keep accuracy.

    What I want to do is trigger the measurement cycle every X seconds regardless of how long (less than X, obviously) the measurement process takes.

    In one previous iteration, I used HiRes gettime calls before and after the read/write cycle to determine how long the processing took, and used that to adjust the sleep time, but that seemed an awfully awkward way to go. I was hoping that a recurring alarm (which the HiRes setItimer function allows) would be a more elegant way to go.

    Thanks! Hope this helps clarify.

      What I want to do is trigger the measurement cycle every X seconds regardless of how long (less than X, obviously) the measurement process takes.

      That's why I used a while loop sleeping for 1 second each time to accumulate the 10 seconds, rather than a 10 second sleep:

      my $deadline = time() + 10; while( 1 ) { sleep 1 while time() < $deadline; $deadline = time() +10; ## Do the something }
      This way, no matter how long "Do something" takes, so long as it's less that 10 seconds, the next reading will be initiated on time. To within one second.

      Eg. If it takes 3 seconds to process, the while loop will iterate 7 times. If it takes 7 seconds, the loop will iterate 3 times only.

      If you need to get more accurate, then use Time::HiRes and sleep for 1/10 of a second in the while loop. It will be 10 times more accurate and still consume almost imeasurable cpu.

      Need more accurate still? Then sleep for 1/100th of a second. It will still consume very little cpu and be another order of magnitude more accurate.

      Beyond that, you start getting into the realms of how long it takes to read the clock, affecting your accuracy, but if you need accuracy beyond 1/1000th of a second, you should probably be using C or assembler.


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

        Need more accurate still? Then sleep for 1/100th of a second. It will still consume very little cpu and be another order of magnitude more accurate.

        One approach to achieve high accuracy while reducing the amount of calls to sleep and time is to sleep for long times initially and decrease them as you get closer to the time to "fire".

        For example, if you want to call a routine every 10 seconds at a resolution of 1/100th of a second, then you could first sleep for 8 seconds, then for 0.2 seconds until within 0.2 sec, then for 0.01 seconds. (These are arbitrary values, of course.)

        This could be premature optimization, though. :-)

      Look into the setitimer function in the POSIX module. It will give you a stream of signals at repeated intervals. This might be a real slick solution combined with the pause suggestion made by traveler.