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 at (no spam) ThisOldHouse.com> wrote in message
news:#QdxhSvWKHA.1792 at (no spam) 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

* 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 at (no spam) ThisOldHouse.com> wrote in message
news:#QdxhSvWKHA.1792 at (no spam) 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

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 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 at (no spam) nowhere.com> wrote in message
news:eG3x2DvWKHA.4780 at (no spam) 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

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.

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.

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

Windows is non-deterministic.

As other replies indicate, you simply cannot assure yourself that this
happens -- unless you design you system such that the user (or your own
code) cannot cause trouble. The most reliable way to do this is to
dedicate a processor, another computer, to the time-critical task. It you
don't allow the user, or your own code, to use that environment for
anything other than your time critical process, you should be OK. You'd
then add a non-time critical communications method to that process that
communicates results to your "loaded" machine, where you can then allow
the user -- or your own code -- do things that otherwise mung up the
system.

Dick

--
Richard Grier, Consultant, Hard & Software 12962 West Louisiana Avenue
Lakewood, CO 80228 303-986-2179 (voice) Homepage: www.hardandsoftware.net
Author of Visual Basic Programmer's Guide to Serial Communications, 4th
Edition ISBN 1-890422-28-2 (391 pages) published July 2004, Revised July
2006.

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

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 at (no spam) nowhere.com> wrote in message
news:eG3x2DvWKHA.4780 at (no spam) 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