From: Charles on 1 Nov 2009 12:05 Hi Jeroen I understand better now from your explanation, thanks. I might give the P/Invoke method a try as I've used this before for other comms projects, so I'm reasonably familiar with getting it working. I presume if I switched from a Threading timer to a System.Timers.Timer I would be no better off? Cheers Charles "Jeroen Mostert" <jmostert(a)xs4all.nl> wrote in message news:4aedb1d9$0$83234$e4fe514c(a)news.xs4all.nl... > 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: Patrice on 1 Nov 2009 12:17 > I have just replied to Mike about what I am doing, but essentially I am > sending a heartbeat over TCP/IP and if it doesn't get sent in time then > the other end thinks I've died and it abandons the connection. I'm not a TCP expert but it really looks like the "TCP keepalive" feature. Have you tried http://msdn.microsoft.com/en-us/library/e160993d.aspx with the keepalive option ? Also it looks really low ? Is this is third party application server side ? -- Patrice
From: Jeroen Mostert on 1 Nov 2009 13:40 Charles wrote: > I presume if I switched from a Threading timer to a System.Timers.Timer I > would be no better off? > You presume correctly. System.Timers.Timer is in fact a wrapper around System.Threading.Timer with a slightly more conventional API. Except for System.Windows.Forms timer, which is based on SetTimer() and WM_TIMER, all managed timers rely on the managed thread pool, which is almost but not quite like the native OS thread pool. -- J.
From: Jeroen Mostert on 1 Nov 2009 13:55 Patrice wrote: >> I have just replied to Mike about what I am doing, but essentially I >> am sending a heartbeat over TCP/IP and if it doesn't get sent in time >> then the other end thinks I've died and it abandons the connection. > > I'm not a TCP expert but it really looks like the "TCP keepalive" > feature. I'm not a TCP expert either, but I do know TCP keepalives are usually more trouble than they're worth. You have to change the default keepalive time (by default it's two hours, which is useless), and even then all the mechanism does is send a number of probes with 1-second intervals to probe the other side for connectivity. The packets sent this way are just 0-byte data packets, which the other side will not necessarily respond correctly to ("responding" in this case is just receiving on the socket and not crashing on the zero-byte packet; the network layer will take care of the ACK). It's almost always a better idea to implement an explicit keepalive mechanism in whatever protocol you're using than to rely on the TCP keepalive. That's assuming your protocol actually needs keepalives, as many people forget that TCP's ability to keep a connection open without traffic is a feature, not a bug. -- J.
From: Charles on 1 Nov 2009 14:11 I've been wondering how I might increase the priority of the the thread that the timer runs on, but if it uses the thread pool then I don't imagine I can increase the priority? If that's the case, then perhaps that's another reason for going for a waitable timer, as the callback runs on the same thread on which the timer was created and I could boost the priority of that thread. Does that sound reasonable? Charles "Jeroen Mostert" <jmostert(a)xs4all.nl> wrote in message news:4aedd600$0$83234$e4fe514c(a)news.xs4all.nl... > Charles wrote: >> I presume if I switched from a Threading timer to a System.Timers.Timer I >> would be no better off? >> > You presume correctly. System.Timers.Timer is in fact a wrapper around > System.Threading.Timer with a slightly more conventional API. Except for > System.Windows.Forms timer, which is based on SetTimer() and WM_TIMER, all > managed timers rely on the managed thread pool, which is almost but not > quite like the native OS thread pool. > > -- > J.
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: How can I read selected text in another application, by vb program? Next: datagridview problem |