Prev: How can I read selected text in another application, by vb program?
Next: datagridview problem
From: James Hahn on 1 Nov 2009 20:04
If your timer can't respond within, say 5s of the nominated interval, then
surely that indicates that the machine is not responsive, and that is
exactly why the server needs that acknowledgement. If you manage to force
the keepalive even when the machine is bogged down like this, surely you
will risk corrupting the connection because the server is being fooled into
thinking that the connection is active when it isn't.

"Charles" <blank(a)nowhere.com> wrote in message
news:eG3x2DvWKHA.4780(a)TK2MSFTNGP05.phx.gbl...
> 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: Charles on 2 Nov 2009 04:01
Hi James

Actually, you have a point there. I hadn't thought of it like that. I should
perhaps put more effort into re-establishing the connection when the machine
unfreezes.

On the other side though, the connection is important enough to keep going
at all costs, so if I could make my task higher priority then it would be ok
if other processes suffered slightly.

Charles


"James Hahn" <jhahn(a)yahoo.com> wrote in message
news:uf2SDi1WKHA.3720(a)TK2MSFTNGP02.phx.gbl...
> If your timer can't respond within, say 5s of the nominated interval, then
> surely that indicates that the machine is not responsive, and that is
> exactly why the server needs that acknowledgement. If you manage to force
> the keepalive even when the machine is bogged down like this, surely you
> will risk corrupting the connection because the server is being fooled
> into thinking that the connection is active when it isn't.
>
> "Charles" <blank(a)nowhere.com> wrote in message
> news:eG3x2DvWKHA.4780(a)TK2MSFTNGP05.phx.gbl...
>> 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: Charles on 2 Nov 2009 04:07
It's not really practical to dedicate a machine to this task, and in any
case, if I could assign an appropriate level of priority to the task then
any other tasks would get plenty of time to operate.

The thing that currently seems to upset it is file transfers over RDP. I
occasionally need to copy a file to the machine over RDP, which can take
anything from 1 minute to 30 minutes. There are times in this window when
the machine appears to hang, but I imagine it is just concentrating really
hard on the file transfer. Anyway, that's when my timer goes astray. Giving
a regular 10 second slot to my task would not hinder the file transfer in
any way, and even if it did, I could live with it. It's just a case of
priorities, as it were.

Charles


"Jeroen Mostert" <jmostert(a)xs4all.nl> wrote in message
news:4aedf426$0$83239$e4fe514c(a)news.xs4all.nl...
> 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: Patrice on 2 Nov 2009 08:42

> 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.

Ok thanks I was wondering (as you saw I'm not that familiar with TCP but
thought it was connection oriented and both end had to agree to close the
connection). Charles, sorry for having hijacked this part of your thread ;-)

--
Patrice

From: Mike on 7 Nov 2009 15:45
I don't know if is to late, to give you one idea,

I did have the same problem, i did have to develop one small app, to keep a
VPN tunnel up and running, until change one of the VPN pix,

What i did do to kip the connection up and running was a ICMP app, using
Background worker this basically ping a host from the other lan and this way
my pix that was broke dint let the tunnel get down.
And the BackGroundWorker don't let my CPU get stress up.

Cheers,

Mike


"Charles" <blank(a)nowhere.com> wrote in message
news:eG3x2DvWKHA.4780(a)TK2MSFTNGP05.phx.gbl...
> 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
>
>

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