Windows Vista Forums

How to Generate an Accurate Timer Tick

  1. #21


    Cor Ligthert[MVP] Guest

    Re: How to Generate an Accurate Timer Tick

    Charles,

    All non main threads runs on the background, mostly with less priority than
    a foreground thread.
    A threading threading timer runs then even on its own thread like a
    threading.dispatcher timer, quiet new, is the one in use with WPF.

    Just my idea from what you wrote.

    However, I did you not see give any response on my advice to use a
    windows.timer.timer?

    I simply don't understand why you don't want to use that?

    Cor

    "Charles" <blank@newsgroup> wrote in message
    news:etyVHEQ#KHA.1888@newsgroup

    > I'm going to attempt to answer this myself, as I've had an idea.
    >
    > Rather than try to generate a reliable timer tick, that won't get deferred
    > when the system gets busy, how about generating a time-out instead. I can
    > think of two obvious ways of doing it:
    >
    > 1. Put the timed task on it's own thread and go to sleep for the timer
    > tick interval
    > 2. Also on a separate thread, wait on a handle that never gets set, and
    > set the timeout to the timer tick interval
    >
    > I don't know if both methods amount to the same thing, but I would be
    > interested in people's opinions.
    >
    > In the first scenario, I spin up a dedicated thread on which I intend to
    > perform my timed activity at a regular interval. I immediately put the
    > thread to sleep for my elapsed time, wake up, perform my task and go back
    > to sleep. This continues forever.
    >
    > In the second scenario, I create a ManualResetEvent and use WaitOne to
    > wait for it to be signalled. I set the timeout to my elapsed time again.
    > Each time the timeout expires I perform my task, and then go back to
    > waiting again.
    >
    > In each case, does the technique behave differently from the way a timer
    > works? In particular, do either or both of them avoid WM_TIMER events? Are
    > either of these going to give me a more stable and reliable interval,
    > bearing in mind that I don't mind the interval generated being +/-50%, but
    > I don't want it to ever be +200%, for example?
    >
    > I have tried both, and as techniques they work, but testing in the case
    > where the system is busy and the interval becomes extended is harder to
    > test empirically.
    >
    > Charles
    >
    >
    > "Charles" <blank@newsgroup> wrote in message
    > news:uYYPRWC#KHA.4316@newsgroup

    >> I asked a question related to this a little while ago, and thought that
    >> I'd got my answer, but it has come back to bite me again.
    >>
    >> I currently use a System.Threading.Timer to generate a tick every 10
    >> seconds. At each tick, I execute some code that will take a maximum of 5
    >> seconds to complete. Most of the time, each subsequent tick occurs at
    >> exactly 10 seconds after the previous one, but occasionally there can be
    >> as much as 20 or 30 seconds between ticks.
    >>
    >> It was explained, in the previous thread, that the Threading timer relies
    >> on WM_TIMER messages, which are low down on the priority list. If the
    >> system gets a bit busy then these message seem to come further apart, so
    >> my tick interval extends.
    >>
    >> What I need is a reliable way to generate a 10 second tick, that still
    >> works when the system gets a bit busy. I'm running this on Windows Server
    >> 2003 R2 x64, if that makes any difference.
    >>
    >> Does anyone have any ideas?
    >>
    >> TIA
    >>
    >> Charles
    >>
    >>

      My System SpecsSystem Spec

  2. #22


    Willem van Rumpt Guest

    Re: How to Generate an Accurate Timer Tick

    On 21-5-2010 18:16, Charles wrote:

    > I'm going to attempt to answer this myself, as I've had an idea.
    >
    > Rather than try to generate a reliable timer tick, that won't get
    > deferred when the system gets busy, how about generating a time-out
    > instead. I can think of two obvious ways of doing it:
    >
    > 1. Put the timed task on it's own thread and go to sleep for the timer
    > tick interval
    > 2. Also on a separate thread, wait on a handle that never gets set, and
    > set the timeout to the timer tick interval
    >
    > I don't know if both methods amount to the same thing, but I would be
    > interested in people's opinions.
    >
    > In the first scenario, I spin up a dedicated thread on which I intend to
    > perform my timed activity at a regular interval. I immediately put the
    > thread to sleep for my elapsed time, wake up, perform my task and go
    > back to sleep. This continues forever.
    >
    > In the second scenario, I create a ManualResetEvent and use WaitOne to
    > wait for it to be signalled. I set the timeout to my elapsed time again.
    > Each time the timeout expires I perform my task, and then go back to
    > waiting again.
    >
    > In each case, does the technique behave differently from the way a timer
    > works? In particular, do either or both of them avoid WM_TIMER events?
    > Are either of these going to give me a more stable and reliable
    > interval, bearing in mind that I don't mind the interval generated being
    > +/-50%, but I don't want it to ever be +200%, for example?
    >
    > I have tried both, and as techniques they work, but testing in the case
    > where the system is busy and the interval becomes extended is harder to
    > test empirically.
    >
    > Charles
    >
    I'd say you'd be reinventing the wheel.

    Unless you're doing *really* strange things, most (if not all) of the
    out-of-the-box timers offer the funtionality you want. From what i've
    gathered from the thread, you want a timer that's alerted *roughly*
    (give or take *5* seconds) every 10 seconds.

    Can you more clearly state what the actual problem is with those timers?

    --
    Willem van Rumpt

      My System SpecsSystem Spec

  3. #23


    Charles Guest

    Re: How to Generate an Accurate Timer Tick

    Hi Cor

    Having read the article you posted the link to, I didn't read anything that
    made me think the Timers.Timer was going to provide any real advantage over
    the Threading.Timer, which I am currently using. Do they function
    differently under the hood? I know it says that the System.Timers.Timer is a
    wrapper around Win32 waitable timer objects, but it doesn't say exactly how
    the Threading.Timer works.

    It's not that I don't want to use it, just that I didn't see what I would
    gain by switching.

    Charles


    "Cor Ligthert[MVP]" <Notmyfirstname@newsgroup> wrote in message
    news:#VDv2JQ#KHA.3176@newsgroup

    > Charles,
    >
    > All non main threads runs on the background, mostly with less priority
    > than a foreground thread.
    > A threading threading timer runs then even on its own thread like a
    > threading.dispatcher timer, quiet new, is the one in use with WPF.
    >
    > Just my idea from what you wrote.
    >
    > However, I did you not see give any response on my advice to use a
    > windows.timer.timer?
    >
    > I simply don't understand why you don't want to use that?
    >
    > Cor
    >
    > "Charles" <blank@newsgroup> wrote in message
    > news:etyVHEQ#KHA.1888@newsgroup

    >> I'm going to attempt to answer this myself, as I've had an idea.
    >>
    >> Rather than try to generate a reliable timer tick, that won't get
    >> deferred when the system gets busy, how about generating a time-out
    >> instead. I can think of two obvious ways of doing it:
    >>
    >> 1. Put the timed task on it's own thread and go to sleep for the timer
    >> tick interval
    >> 2. Also on a separate thread, wait on a handle that never gets set, and
    >> set the timeout to the timer tick interval
    >>
    >> I don't know if both methods amount to the same thing, but I would be
    >> interested in people's opinions.
    >>
    >> In the first scenario, I spin up a dedicated thread on which I intend to
    >> perform my timed activity at a regular interval. I immediately put the
    >> thread to sleep for my elapsed time, wake up, perform my task and go back
    >> to sleep. This continues forever.
    >>
    >> In the second scenario, I create a ManualResetEvent and use WaitOne to
    >> wait for it to be signalled. I set the timeout to my elapsed time again.
    >> Each time the timeout expires I perform my task, and then go back to
    >> waiting again.
    >>
    >> In each case, does the technique behave differently from the way a timer
    >> works? In particular, do either or both of them avoid WM_TIMER events?
    >> Are either of these going to give me a more stable and reliable interval,
    >> bearing in mind that I don't mind the interval generated being +/-50%,
    >> but I don't want it to ever be +200%, for example?
    >>
    >> I have tried both, and as techniques they work, but testing in the case
    >> where the system is busy and the interval becomes extended is harder to
    >> test empirically.
    >>
    >> Charles
    >>
    >>
    >> "Charles" <blank@newsgroup> wrote in message
    >> news:uYYPRWC#KHA.4316@newsgroup

    >>> I asked a question related to this a little while ago, and thought that
    >>> I'd got my answer, but it has come back to bite me again.
    >>>
    >>> I currently use a System.Threading.Timer to generate a tick every 10
    >>> seconds. At each tick, I execute some code that will take a maximum of 5
    >>> seconds to complete. Most of the time, each subsequent tick occurs at
    >>> exactly 10 seconds after the previous one, but occasionally there can be
    >>> as much as 20 or 30 seconds between ticks.
    >>>
    >>> It was explained, in the previous thread, that the Threading timer
    >>> relies on WM_TIMER messages, which are low down on the priority list. If
    >>> the system gets a bit busy then these message seem to come further
    >>> apart, so my tick interval extends.
    >>>
    >>> What I need is a reliable way to generate a 10 second tick, that still
    >>> works when the system gets a bit busy. I'm running this on Windows
    >>> Server 2003 R2 x64, if that makes any difference.
    >>>
    >>> Does anyone have any ideas?
    >>>
    >>> TIA
    >>>
    >>> Charles
    >>>
    >>>

      My System SpecsSystem Spec

  4. #24


    Charles Guest

    Re: How to Generate an Accurate Timer Tick

    Hi Willem

    The problem is simply that the Threading.Timer that I am using at present
    doesn't always raise an event when the designated 10 seconds has expired. It
    nearly always does, 99.9% of the time, probably. But occasionally, the event
    is delayed for some reason, and might not occur for 20 or even 30 seconds
    after the previous event. It is most likely to happen when the system is
    quite busy (Windows Server 2003 R2 x64), perhaps performing a lot of disk
    I/O, or something like that.

    Charles


    "Willem van Rumpt" <wdotvandotrumpt@newsgroup> wrote in message
    news:OfGbYdQ#KHA.5916@newsgroup

    > On 21-5-2010 18:16, Charles wrote:

    >> I'm going to attempt to answer this myself, as I've had an idea.
    >>
    >> Rather than try to generate a reliable timer tick, that won't get
    >> deferred when the system gets busy, how about generating a time-out
    >> instead. I can think of two obvious ways of doing it:
    >>
    >> 1. Put the timed task on it's own thread and go to sleep for the timer
    >> tick interval
    >> 2. Also on a separate thread, wait on a handle that never gets set, and
    >> set the timeout to the timer tick interval
    >>
    >> I don't know if both methods amount to the same thing, but I would be
    >> interested in people's opinions.
    >>
    >> In the first scenario, I spin up a dedicated thread on which I intend to
    >> perform my timed activity at a regular interval. I immediately put the
    >> thread to sleep for my elapsed time, wake up, perform my task and go
    >> back to sleep. This continues forever.
    >>
    >> In the second scenario, I create a ManualResetEvent and use WaitOne to
    >> wait for it to be signalled. I set the timeout to my elapsed time again.
    >> Each time the timeout expires I perform my task, and then go back to
    >> waiting again.
    >>
    >> In each case, does the technique behave differently from the way a timer
    >> works? In particular, do either or both of them avoid WM_TIMER events?
    >> Are either of these going to give me a more stable and reliable
    >> interval, bearing in mind that I don't mind the interval generated being
    >> +/-50%, but I don't want it to ever be +200%, for example?
    >>
    >> I have tried both, and as techniques they work, but testing in the case
    >> where the system is busy and the interval becomes extended is harder to
    >> test empirically.
    >>
    >> Charles
    >>
    >
    > I'd say you'd be reinventing the wheel.
    >
    > Unless you're doing *really* strange things, most (if not all) of the
    > out-of-the-box timers offer the funtionality you want. From what i've
    > gathered from the thread, you want a timer that's alerted *roughly* (give
    > or take *5* seconds) every 10 seconds.
    >
    > Can you more clearly state what the actual problem is with those timers?
    >
    > --
    > Willem van Rumpt

      My System SpecsSystem Spec

  5. #25


    Willem van Rumpt Guest

    Re: How to Generate an Accurate Timer Tick

    On 21-5-2010 19:20, Charles wrote:

    > Hi Willem
    >
    > The problem is simply that the Threading.Timer that I am using at
    > present doesn't always raise an event when the designated 10 seconds has
    > expired. It nearly always does, 99.9% of the time, probably. But
    > occasionally, the event is delayed for some reason, and might not occur
    > for 20 or even 30 seconds after the previous event. It is most likely to
    > happen when the system is quite busy (Windows Server 2003 R2 x64),
    > perhaps performing a lot of disk I/O, or something like that.
    >
    > Charles
    >
    Ok, now I see where your idea of the second scenario comes from.

    using a separate thread with a ManualResetEvent like this

    private ManualResetEvent _quitEvent = new ManualResetEvent(false);
    void ThreadProc()
    {
    while (!_quitEvent.WaitOne(timeout))
    {
    // ...Whatever it is your task should do...
    }
    }

    will do the trick.

    As soon as it's timeslice comes up, and the event is not signalled, the
    thread will move into the while loop. Assuming it runs on it's own
    thread, it will at least get scheduled and run (at some point).

    The more interesting part though is why this wouldn't work with the
    already provided timers. I haven't looked at the internals, but it seems
    logical that the threaded timer also uses some waitable object to do
    it's task. So the same problems may arise when using the scenario above.

    Is there anyway, indication, or way of logging of *what* is going on
    when the delay appears? Is the "delayed event" you talk about
    synchronized (i.e. are the handlers called through Control.Invoke())
    with the main thread?

    --
    Willem van Rumpt

      My System SpecsSystem Spec

  6. #26


    Charles Guest

    Re: How to Generate an Accurate Timer Tick

    Hi Willem

    Yes, that's exactly what I was thinking, and almost exactly what I tried.

    The process that runs when the interval has elapsed currently runs on the
    thread of the callback; I'm using the Threading.Timer.

    It's hard to be certain what is happening when the delay occurs. It used to
    happen when memory was short (caused by a memory leak in BackupExec, but
    that's been sorted now). The server where this happens I connect to using
    Remote Desktop. I can often cause the problem if I transfer a file from a
    mapped local drive over RDP to the server. That's about as much as I've been
    able to tell. I'm tempted to give the manual reset event thing a try though,
    now that you've picked up on the same idea.

    Charles


    "Willem van Rumpt" <wdotvandotrumpt@newsgroup> wrote in message
    news:eq9vZLR#KHA.3628@newsgroup

    > On 21-5-2010 19:20, Charles wrote:
    >

    >> Hi Willem
    >>
    >> The problem is simply that the Threading.Timer that I am using at
    >> present doesn't always raise an event when the designated 10 seconds has
    >> expired. It nearly always does, 99.9% of the time, probably. But
    >> occasionally, the event is delayed for some reason, and might not occur
    >> for 20 or even 30 seconds after the previous event. It is most likely to
    >> happen when the system is quite busy (Windows Server 2003 R2 x64),
    >> perhaps performing a lot of disk I/O, or something like that.
    >>
    >> Charles
    >>
    >
    > Ok, now I see where your idea of the second scenario comes from.
    >
    > using a separate thread with a ManualResetEvent like this
    >
    > private ManualResetEvent _quitEvent = new ManualResetEvent(false);
    > void ThreadProc()
    > {
    > while (!_quitEvent.WaitOne(timeout))
    > {
    > // ...Whatever it is your task should do...
    > }
    > }
    >
    > will do the trick.
    >
    > As soon as it's timeslice comes up, and the event is not signalled, the
    > thread will move into the while loop. Assuming it runs on it's own thread,
    > it will at least get scheduled and run (at some point).
    >
    > The more interesting part though is why this wouldn't work with the
    > already provided timers. I haven't looked at the internals, but it seems
    > logical that the threaded timer also uses some waitable object to do it's
    > task. So the same problems may arise when using the scenario above.
    >
    > Is there anyway, indication, or way of logging of *what* is going on when
    > the delay appears? Is the "delayed event" you talk about synchronized
    > (i.e. are the handlers called through Control.Invoke()) with the main
    > thread?
    >
    > --
    > Willem van Rumpt

      My System SpecsSystem Spec

  7. #27


    Charles Guest

    Re: How to Generate an Accurate Timer Tick

    Thinking about it further, the downside of this approach is that the
    interval between 'ticks' is not 10 seconds anymore. It is 10 seconds +
    length of time task takes. Perhaps that's not the end of the world, but I
    might have to factor that in somehow.

    Charles


    "Charles" <blank@newsgroup> wrote in message
    news:#ATK1BU#KHA.3880@newsgroup

    > Hi Willem
    >
    > Yes, that's exactly what I was thinking, and almost exactly what I tried.
    >
    > The process that runs when the interval has elapsed currently runs on the
    > thread of the callback; I'm using the Threading.Timer.
    >
    > It's hard to be certain what is happening when the delay occurs. It used
    > to happen when memory was short (caused by a memory leak in BackupExec,
    > but that's been sorted now). The server where this happens I connect to
    > using Remote Desktop. I can often cause the problem if I transfer a file
    > from a mapped local drive over RDP to the server. That's about as much as
    > I've been able to tell. I'm tempted to give the manual reset event thing a
    > try though, now that you've picked up on the same idea.
    >
    > Charles
    >
    >
    > "Willem van Rumpt" <wdotvandotrumpt@newsgroup> wrote in message
    > news:eq9vZLR#KHA.3628@newsgroup

    >> On 21-5-2010 19:20, Charles wrote:
    >>

    >>> Hi Willem
    >>>
    >>> The problem is simply that the Threading.Timer that I am using at
    >>> present doesn't always raise an event when the designated 10 seconds has
    >>> expired. It nearly always does, 99.9% of the time, probably. But
    >>> occasionally, the event is delayed for some reason, and might not occur
    >>> for 20 or even 30 seconds after the previous event. It is most likely to
    >>> happen when the system is quite busy (Windows Server 2003 R2 x64),
    >>> perhaps performing a lot of disk I/O, or something like that.
    >>>
    >>> Charles
    >>>
    >>
    >> Ok, now I see where your idea of the second scenario comes from.
    >>
    >> using a separate thread with a ManualResetEvent like this
    >>
    >> private ManualResetEvent _quitEvent = new ManualResetEvent(false);
    >> void ThreadProc()
    >> {
    >> while (!_quitEvent.WaitOne(timeout))
    >> {
    >> // ...Whatever it is your task should do...
    >> }
    >> }
    >>
    >> will do the trick.
    >>
    >> As soon as it's timeslice comes up, and the event is not signalled, the
    >> thread will move into the while loop. Assuming it runs on it's own
    >> thread, it will at least get scheduled and run (at some point).
    >>
    >> The more interesting part though is why this wouldn't work with the
    >> already provided timers. I haven't looked at the internals, but it seems
    >> logical that the threaded timer also uses some waitable object to do it's
    >> task. So the same problems may arise when using the scenario above.
    >>
    >> Is there anyway, indication, or way of logging of *what* is going on when
    >> the delay appears? Is the "delayed event" you talk about synchronized
    >> (i.e. are the handlers called through Control.Invoke()) with the main
    >> thread?
    >>
    >> --
    >> Willem van Rumpt
    >

      My System SpecsSystem Spec

  8. #28


    DickGrier Guest

    Re: How to Generate an Accurate Timer Tick

    It is hard for me to imagine a scenario where conventional timer messages
    will be delayed sufficiently long enough to cause trouble with your
    application. 5-10 seconds is a huge window. If you really are seeing such
    a problem, the only thing that I can imagine is something that is seriously
    wrong. This certainly isn't something that I've seen. Have you tried
    System.Threading.Timer instead -- this create a threaded timer? If this
    doesn't work, I think you need to look more closely at your system to see
    where the hog resides.

    --
    Richard Grier, Consultant, Hard & Software 12962 West Louisiana Avenue
    Lakewood, CO 80228 303-986-2179 (voice) Homepage: www.hardandsoftware.net
    Author of Visual Basic Programmer's Guide to Serial Communications, 4th
    Edition ISBN 1-890422-28-2 (391 pages) published July 2004, Revised July
    2006.


      My System SpecsSystem Spec

  9. #29


    Cor Ligthert[MVP] Guest

    Re: How to Generate an Accurate Timer Tick

    Charles,

    My aversion against the threading.timer is probably because of a bad
    experience with that one,
    However, there is another threading one.

    I don't know if you can use that in your environment. My experience with
    that one is fine.
    http://msdn.microsoft.com/en-us/libr...chertimer.aspx

    Cor

    "Charles" <blank@newsgroup> wrote in message
    news:u9ny##E#KHA.3628@newsgroup

    > Hi Dick
    >
    > As I replied to Mike, 10 +/- 5 seconds would do me. I have to send a
    > keep-alive message to another system approximately every 10 seconds. The
    > other end will time-out after 25 seconds or so, which doesn't seem too
    > tight a window, and yet sometimes the interval between ticks can be 30
    > seconds or mor. I wondered about monitoring elapsed seconds, but it just
    > seemed a bit kludgy. I can't imagine I'm the only person that does this
    > sort of thing in Windows. How do other applications do it, I wonder, where
    > they have to perform tasks at regular intervals, with a reasonable degree
    > of accuracy?
    >
    > Charles
    >
    >
    > "DickGrier" <dick_grierNOSPAM@newsgroup> wrote in message
    > news:u4PzjnD#KHA.1888@newsgroup

    >> As Mike said, Windows is not a real-time OS. Thus, you cannot guarantee
    >> response.
    >>
    >> That said, you may be able to approach the accuracy that you desire. One
    >> thing to realize is that resolution and accuracy are not the same thing.
    >> And, since you will be writing code that is multi-threaded (and you have
    >> only gross control of the various thread execution), and, in addition,
    >> are executing in a non-deterministic OS, you have to careful what you ask
    >> for -- and understand that you can never be absolutely certain that you
    >> will get the precision that you seek.
    >>
    >> If you use a timer, you depend on multiple things, including the wm_timer
    >> message. You might simply create a thread that monitors elapsed
    >> milliseconds (example: Now.TimeOfDay.TotalMilliseconds). This will be
    >> more accurate than the built-in timer. It will not, however, provide any
    >> real determinism, so at the end of the day, you have to test it under
    >> load and see if it meets your needs. If not... You may not be able to
    >> get there from here.
    >>
    >> Dick
    >> --
    >> Richard Grier, Consultant, Hard & Software 12962 West Louisiana Avenue
    >> Lakewood, CO 80228 303-986-2179 (voice) Homepage: www.hardandsoftware.net
    >> Author of Visual Basic Programmer's Guide to Serial Communications, 4th
    >> Edition ISBN 1-890422-28-2 (391 pages) published July 2004, Revised July
    >> 2006.
    >

      My System SpecsSystem Spec

  10. #30


    Tom Shelton Guest

    Re: How to Generate an Accurate Timer Tick

    Charles explained on 5/22/2010 :

    > Thinking about it further, the downside of this approach is that the interval
    > between 'ticks' is not 10 seconds anymore. It is 10 seconds + length of time
    > task takes. Perhaps that's not the end of the world, but I might have to
    > factor that in somehow.
    >
    > Charles
    >
    >
    ThreadPool.QueueUserWorkItem

    --
    Tom Shelton



      My System SpecsSystem Spec

Page 3 of 4 FirstFirst 1234 LastLast

How to Generate an Accurate Timer Tick
Similar Threads
Thread Forum
Solved For a more accurate speed test in the UK. Network & Sharing
Are Threading.Timers Supposed to be Accurate? .NET General
Network Map is *almost* accurate. Help? Vista networking & sharing
Timer Tick Avalon