From: Patrice on
> 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
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
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
* 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
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