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

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

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

Some more details could help but this is possible only for a real time OS
(http://en.wikipedia.org/wiki/Real-time_operating_system)... Also a common
misuse is to to use a timer to measure the time, if applicable you could
get this timer fire with a possible margin and then get the system time
date to get the actual time you are called.

We can't say much more wihtout knwoing what is the critical task that
needs to be done...

--
Patrice

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.

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

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

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.

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.

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.

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

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?

Yes, in principle. There's one caveat with waitable timers, though: they use