How to Generate an Accurate Timer Tick
in [VB.NET]
|
From: Cor Ligthert[MVP] on 21 May 2010 10:45 Seems to be, However, you wrote that you had written that you had heard.......................................... That is so often written about that threading timer without any reason, more that it seems to sound very elite. Like I've always have been, I don't like statements which goes around simple because someone had a dream and thought he had to write about it. However, if I would have known, it was you, my tone would have been very different. :-) Cor "Charles" <blank(a)nowhere.com> wrote in message news:uH1DesN#KHA.420(a)TK2MSFTNGP02.phx.gbl... > I don't remember you like this Cor. Is that really you? What have you done > with the real Cor? > > > "Cor Ligthert[MVP]" <Notmyfirstname(a)planet.nl> wrote in message > news:uIUoIpN#KHA.3176(a)TK2MSFTNGP05.phx.gbl... >> I forgot to ask you. >> >> How is your American car going at 200 miles an hour? >> >> Cor >> >> "Charles" <blank(a)nowhere.com> wrote in message >> news:uRLGmlN#KHA.1652(a)TK2MSFTNGP05.phx.gbl... >>> Have you actually read the article, Cor? I have. It bears out exactly >>> what I said: "System.Windows.Forms.Timer >>> If you're looking for a metronome, you've come to the wrong place." >>> >>> Charles >>> >>> >>> "Cor Ligthert[MVP]" <Notmyfirstname(a)planet.nl> wrote in message >>> news:OoAId2M#KHA.4768(a)TK2MSFTNGP04.phx.gbl... >>>> There is also written that American cars are better than German cars. >>>> >>>> Do you believe everything which is written without anything which >>>> explains why? >>>> >>>> Take a look at this page which compares timers. >>>> >>>> http://msdn.microsoft.com/en-us/magazine/cc164015.aspx >>>> >>>> You can handle them top down like in this page as long as something >>>> where they don't work fail. >>>> >>>> Cor >>>> >>>> >>>> >>>> "Charles" <blank(a)nowhere.com> wrote in message >>>> news:e7o3vHM#KHA.5916(a)TK2MSFTNGP04.phx.gbl... >>>>> Hi Cor, good to hear from you. >>>>> >>>>> I have read that the Forms timer is actually less reliable in terms of >>>>> its interval than the other timers, because it is single-threaded. >>>>> Coupled with the fact that I want to use this in a service eventually, >>>>> I don't think I can use the Forms timer. >>>>> >>>>> Cheers >>>>> >>>>> Charles >>>>> >>>>> >>>>> "Cor Ligthert[MVP]" <Notmyfirstname(a)planet.nl> wrote in message >>>>> news:#3x7yxK#KHA.4308(a)TK2MSFTNGP04.phx.gbl... >>>>>> Then why not use the standard Windows.Forms.Form.Timer, somehow >>>>>> persons want to use the system.timer.timer (the windows service one) >>>>>> or the threading timer (who is able to be used in async) >>>>>> >>>>>> I am glad that you are not writing of the current fourth one the >>>>>> dispatcher timer. >>>>>> >>>>>> People always write about all timers beside the >>>>>> windows.forms.form.timer that the others are better, but never tell >>>>>> why those are better. >>>>>> >>>>>> The windows.forms.form timer is at least the most reliable one in >>>>>> most situations >>>>>> >>>>>> Cor >>>>>> >>>>>> "Charles" <blank(a)nowhere.com> wrote in message >>>>>> news:#S6R67E#KHA.1652(a)TK2MSFTNGP05.phx.gbl... >>>>>>> Hi Dave >>>>>>> >>>>>>> Yes, I have. It was my understanding that the Timers timer was just >>>>>>> a wrapper for the Threading timer. Perhaps not. There doesn't seem >>>>>>> to be anything there that suggests it is any more reliable the the >>>>>>> threading version. If it doesn't use WM_TIMER messages, do you know >>>>>>> how it does work? >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Charles >>>>>>> >>>>>>> >>>>>>> "Davej" <galt_57(a)hotmail.com> wrote in message >>>>>>> news:a38d2fce-5230-42bd-833c-e9b6748bf691(a)h37g2000pra.googlegroups.com... >>>>>>>> On May 20, 8:51 am, "Charles" <bl...(a)nowhere.com> wrote: >>>>>>>>> [...] 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. >>>>>>>>> >>>>>>>> >>>>>>>> You've looked here? >>>>>>>> >>>>>>>> http://msdn.microsoft.com/en-us/library/system.timers.timer.aspx >>>>>>>>
From: Charles on 21 May 2010 10:57 Hi Cor, yes it's me. I've been off in SQL Server newsgroups for a bit and Windows Server. Doing lots of databasey stuff. Good to speak with you again. I'm pleased you remember me. Cheers Charles "Cor Ligthert[MVP]" <Notmyfirstname(a)planet.nl> wrote in message news:OAyYARP#KHA.5848(a)TK2MSFTNGP06.phx.gbl... > Seems to be, > > However, you wrote that you had written that you had > heard.......................................... > > That is so often written about that threading timer without any reason, > more that it seems to sound very elite. > > Like I've always have been, I don't like statements which goes around > simple because someone had a dream and thought he had to write about it. > > However, if I would have known, it was you, my tone would have been very > different. > > :-) > > Cor > > "Charles" <blank(a)nowhere.com> wrote in message > news:uH1DesN#KHA.420(a)TK2MSFTNGP02.phx.gbl... >> I don't remember you like this Cor. Is that really you? What have you >> done with the real Cor? >> >> >> "Cor Ligthert[MVP]" <Notmyfirstname(a)planet.nl> wrote in message >> news:uIUoIpN#KHA.3176(a)TK2MSFTNGP05.phx.gbl... >>> I forgot to ask you. >>> >>> How is your American car going at 200 miles an hour? >>> >>> Cor >>> >>> "Charles" <blank(a)nowhere.com> wrote in message >>> news:uRLGmlN#KHA.1652(a)TK2MSFTNGP05.phx.gbl... >>>> Have you actually read the article, Cor? I have. It bears out exactly >>>> what I said: "System.Windows.Forms.Timer >>>> If you're looking for a metronome, you've come to the wrong place." >>>> >>>> Charles >>>> >>>> >>>> "Cor Ligthert[MVP]" <Notmyfirstname(a)planet.nl> wrote in message >>>> news:OoAId2M#KHA.4768(a)TK2MSFTNGP04.phx.gbl... >>>>> There is also written that American cars are better than German cars. >>>>> >>>>> Do you believe everything which is written without anything which >>>>> explains why? >>>>> >>>>> Take a look at this page which compares timers. >>>>> >>>>> http://msdn.microsoft.com/en-us/magazine/cc164015.aspx >>>>> >>>>> You can handle them top down like in this page as long as something >>>>> where they don't work fail. >>>>> >>>>> Cor >>>>> >>>>> >>>>> >>>>> "Charles" <blank(a)nowhere.com> wrote in message >>>>> news:e7o3vHM#KHA.5916(a)TK2MSFTNGP04.phx.gbl... >>>>>> Hi Cor, good to hear from you. >>>>>> >>>>>> I have read that the Forms timer is actually less reliable in terms >>>>>> of its interval than the other timers, because it is single-threaded. >>>>>> Coupled with the fact that I want to use this in a service >>>>>> eventually, I don't think I can use the Forms timer. >>>>>> >>>>>> Cheers >>>>>> >>>>>> Charles >>>>>> >>>>>> >>>>>> "Cor Ligthert[MVP]" <Notmyfirstname(a)planet.nl> wrote in message >>>>>> news:#3x7yxK#KHA.4308(a)TK2MSFTNGP04.phx.gbl... >>>>>>> Then why not use the standard Windows.Forms.Form.Timer, somehow >>>>>>> persons want to use the system.timer.timer (the windows service one) >>>>>>> or the threading timer (who is able to be used in async) >>>>>>> >>>>>>> I am glad that you are not writing of the current fourth one the >>>>>>> dispatcher timer. >>>>>>> >>>>>>> People always write about all timers beside the >>>>>>> windows.forms.form.timer that the others are better, but never tell >>>>>>> why those are better. >>>>>>> >>>>>>> The windows.forms.form timer is at least the most reliable one in >>>>>>> most situations >>>>>>> >>>>>>> Cor >>>>>>> >>>>>>> "Charles" <blank(a)nowhere.com> wrote in message >>>>>>> news:#S6R67E#KHA.1652(a)TK2MSFTNGP05.phx.gbl... >>>>>>>> Hi Dave >>>>>>>> >>>>>>>> Yes, I have. It was my understanding that the Timers timer was just >>>>>>>> a wrapper for the Threading timer. Perhaps not. There doesn't seem >>>>>>>> to be anything there that suggests it is any more reliable the the >>>>>>>> threading version. If it doesn't use WM_TIMER messages, do you know >>>>>>>> how it does work? >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Charles >>>>>>>> >>>>>>>> >>>>>>>> "Davej" <galt_57(a)hotmail.com> wrote in message >>>>>>>> news:a38d2fce-5230-42bd-833c-e9b6748bf691(a)h37g2000pra.googlegroups.com... >>>>>>>>> On May 20, 8:51 am, "Charles" <bl...(a)nowhere.com> wrote: >>>>>>>>>> [...] 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. >>>>>>>>>> >>>>>>>>> >>>>>>>>> You've looked here? >>>>>>>>> >>>>>>>>> http://msdn.microsoft.com/en-us/library/system.timers.timer.aspx >>>>>>>>>
From: Charles on 21 May 2010 12:16 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(a)nowhere.com> wrote in message news:uYYPRWC#KHA.4316(a)TK2MSFTNGP04.phx.gbl... > 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 > >
From: Cor Ligthert[MVP] on 21 May 2010 12:27 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(a)nowhere.com> wrote in message news:etyVHEQ#KHA.1888(a)TK2MSFTNGP05.phx.gbl... > 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(a)nowhere.com> wrote in message > news:uYYPRWC#KHA.4316(a)TK2MSFTNGP04.phx.gbl... >> 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 >> >>
From: Willem van Rumpt on 21 May 2010 13:02
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 |