From: Charles on 1 Nov 2009 07:43 This is a follow up to an earlier post, about a Threading.Timer that occasionally fired at odd times. In that case I discovered that low memory meant that the machine 'froze' intermittently and a timer callback could fire after 30 seconds instead of every 10 seconds as intended. I now find that if the machine becomes preoccupied with another task, I get the same effect. This is a very bad state of affairs, as I can no longer rely on my 10 second tick occurring every 10 seconds. I need to have a reliable 10 second timer, such that an event happens every 10 seconds. It's no good if I get two events after 20 seconds, I need one every 10 seconds. How is this possible to guarantee in .NET? The app is running on Windows Server 2003 x64. TIA Charles
From: Family Tree Mike on 1 Nov 2009 08:10 Charles wrote: > This is a follow up to an earlier post, about a Threading.Timer that > occasionally fired at odd times. In that case I discovered that low > memory meant that the machine 'froze' intermittently and a timer > callback could fire after 30 seconds instead of every 10 seconds as > intended. > > I now find that if the machine becomes preoccupied with another task, I > get the same effect. This is a very bad state of affairs, as I can no > longer rely on my 10 second tick occurring every 10 seconds. > > I need to have a reliable 10 second timer, such that an event happens > every 10 seconds. It's no good if I get two events after 20 seconds, I > need one every 10 seconds. > > How is this possible to guarantee in .NET? The app is running on Windows > Server 2003 x64. > > TIA > > Charles > > If the task is that critical that it _must_ occur every 10 seconds, then I would dedicate a machine to that task. If that task is it's job, then it does nothing else. It is impossible for me to know your situation, but is there a way to "throttle" the other process that is grabbing the CPU attention? That may be an option to look into. -- Mike
From: Patrice on 1 Nov 2009 10:25 Some more details could help but this is possible only for a real time OS (http://en.wikipedia.org/wiki/Real-time_operating_system)... Also a common misuse is to to use a timer to measure the time, if applicable you could get this timer fire with a possible margin and then get the system time date to get the actual time you are called. We can't say much more wihtout knwoing what is the critical task that needs to be done... -- Patrice
From: Jeroen Mostert on 1 Nov 2009 11:05 Charles wrote: > This is a follow up to an earlier post, about a Threading.Timer that > occasionally fired at odd times. In that case I discovered that low > memory meant that the machine 'froze' intermittently and a timer > callback could fire after 30 seconds instead of every 10 seconds as > intended. > > I now find that if the machine becomes preoccupied with another task, I > get the same effect. This is a very bad state of affairs, as I can no > longer rely on my 10 second tick occurring every 10 seconds. > > I need to have a reliable 10 second timer, such that an event happens > every 10 seconds. It's no good if I get two events after 20 seconds, I > need one every 10 seconds. > > How is this possible to guarantee in .NET? The app is running on Windows > Server 2003 x64. > You can't really do this with managed code only, because all managed timing mechanisms that aren't WM_TIMER rely on a hand-rolled thread pool which is very much subject to preemption. Technically speaking, as others have pointed out, you can't do it in unmanaged code either, as it requires a real-time OS to do tasks in hard real-time. That said, unmanaged code *can* get much better accuracy in fixed timing, because you can use the OS mechanisms. But there is still no cure for a system that's completely locked up with I/O -- you can't just steal time from the interrupt handlers. Doing something every 10 seconds doesn't require high resolution, so an option is to use a thread running at high or even realtime priority that sleeps for 500 ms and checks how much time has passed every time it wakes up. This is still subject to preemption, so how well it works depends. Another option is to P/Invoke to CreateWaitableTimer() or CreateTimerQueueTimer() using one of the the WT_EXECUTEIN* flags. I have no idea how well this holds up when the system is busy, but it ought to do better than .NET's own thread pool. Getting the interop right can be tricky, though. Many people still use the multimedia timer functions (timeSetEvent() and the like) despite these being nominally obsoleted, as they still offer higher accuracy -- but with a 10 second period you're not likely to need them. -- J.
From: Charles on 1 Nov 2009 11:59 Hi Mike Thanks for the quick reply. It's not critical that it is exactly 10 seconds. 12 seconds would do, or even 15 seconds occasionally. But what I can't have is it being 30 seconds between timer events, and that is the worst cases I have seen. I have to send a message over TCP/IP about every 10 seconds in order to keep a connection open, otherwise the other end shuts up shop and goes away. Charles "Family Tree Mike" <FamilyTreeMike(a)ThisOldHouse.com> wrote in message news:#QdxhSvWKHA.1792(a)TK2MSFTNGP04.phx.gbl... > Charles wrote: >> This is a follow up to an earlier post, about a Threading.Timer that >> occasionally fired at odd times. In that case I discovered that low >> memory meant that the machine 'froze' intermittently and a timer callback >> could fire after 30 seconds instead of every 10 seconds as intended. >> >> I now find that if the machine becomes preoccupied with another task, I >> get the same effect. This is a very bad state of affairs, as I can no >> longer rely on my 10 second tick occurring every 10 seconds. >> >> I need to have a reliable 10 second timer, such that an event happens >> every 10 seconds. It's no good if I get two events after 20 seconds, I >> need one every 10 seconds. >> >> How is this possible to guarantee in .NET? The app is running on Windows >> Server 2003 x64. >> >> TIA >> >> Charles >> >> > > If the task is that critical that it _must_ occur every 10 seconds, then I > would dedicate a machine to that task. If that task is it's job, then it > does nothing else. > > It is impossible for me to know your situation, but is there a way to > "throttle" the other process that is grabbing the CPU attention? That may > be an option to look into. > > -- > Mike
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: How can I read selected text in another application, by vb program? Next: datagridview problem |