From: Patrice on 1 Nov 2009 15:05 > 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. It begins to be OT respective with the OP initial demand by may I ask what you think about the connection being closed after 10 s ? Is this something usual ? TIA -- Patrice
From: Jeroen Mostert on 1 Nov 2009 15:26 Patrice wrote: >> 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. > > It begins to be OT respective with the OP initial demand by may I ask > what you think about the connection being closed after 10 s ? Is this > something usual ? > I have worked with setups where the server side closed the connection after just 20 seconds of inactivity, because it was more important for the connection to be "known good" even at short intervals than it was to be mindful of the bandwidth wasted this way. I'm not saying this is a good way of doing things (using short transmission timeouts is probably a better idea), but I don't think it's unusual either. -- J.
From: Jeroen Mostert on 1 Nov 2009 15:48 Charles wrote: > 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? No, you can't. Well, to be precise, you can, but there's no thread affinity for the timer, so you'll just be boosting the priority of some random thread that's handling the timer callback. I don't recall if it's possible for the thread that sets the timer to get the callback if the interval is sufficiently short, but in any case that won't apply here since your interval is in the range of seconds. > 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? > Yes, in principle. There's one caveat with waitable timers, though: they use APCs to signal completion. This is slightly tricky because the CLR also uses APCs to communicate with threads (Thread.Interrupt() and Thread.Abort(), among others, queue an APC on the thread). I recall having some problems using APCs in managed threads, but nothing specific; it's probably the general trouble of having to be careful in callbacks from unmanaged code, especially something as low-level as APCs. I do recall you can use try { Thread.Sleep(Timeout.Infinite); } catch (InterruptedException) { return; // asked to stop } And then call Thread.Interrupt() when your thread should stop. Thread.Sleep() uses SleepEx() under the covers and will properly respond to the CLR signaling APCs. I'd try timer queues first. By default these just use worker threads, so no mucking around with APCs. They don't allow for boosting priority but they don't use the .NET thread pool either, so they might be less susceptible to preemption under load. I have no idea if this is actually the case, but you'll have to thoroughly test whatever solution you pick anyway, so you might as well start with the easier ones. Speaking of which, you really are better off dedicating a machine that's guaranteed to have low loads to this task, like Mike suggested. :-) If you can isolate the processes that are ruining it for the rest, you could try looking into job objects to limit the memory and CPU they're assigned. Keeping your program simple and not overly reliant on interesting low-level techniques is certainly worth some effort. -- J.
From: Jesse Houwing on 1 Nov 2009 17:12 * Charles wrote, On 1-11-2009 17: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. Isn't it possible to make that connection more reliable (by leaving it open longer), or wouldn't it just be possible to switch to UDP instead and forget the notion of a connection altogether? Jesse > > 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 > -- Jesse Houwing jesse.houwing at sogeti.nl
From: Charles on 1 Nov 2009 18:05 Hi Jesse Because it's third-party, I'm at their mercy. This is just the protocol I have to accommodate. Charles "Jesse Houwing" <jesse.houwing(a)newsgroup.nospam> wrote in message news:#l#KjB0WKHA.3428(a)TK2MSFTNGP06.phx.gbl... > * Charles wrote, On 1-11-2009 17: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. > > Isn't it possible to make that connection more reliable (by leaving it > open longer), or wouldn't it just be possible to switch to UDP instead and > forget the notion of a connection altogether? > > Jesse > >> >> 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 >> > > > -- > Jesse Houwing > jesse.houwing at sogeti.nl
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 |