Question

I’ve created a watchdog timer (using a System.Windows.Forms.Timer), which triggers if a long period of time expires without receiving a small packet of data:

using System.Windows.Forms;
public class Watchdog
{
    private Timer Timer;

    public void Go()
    {
        Timer.Start();
    }

    public void Reset()
    {
        Timer.Stop();
        Timer.Start();
    }

    private void OnTimerExpired(object State)
    {
        Timer.Stop();
        DoSomething();
    }

    public Watchdog()
    {
        Timer = new Timer();
        Timer.Tick += new EventHandler(OnTimerExpired);
        Timer.Interval = (1000 * Timeout);            
    }
}

The main code calls Go(), and then calls Reset() each time a packet is received. If the timer expires, OnTimerExpired() is called.

Since that there may be hundreds of packet receptions per second, and since the main job of the application is to respond to such packets, I’m beginning to wonder if resetting the timer isn’t too CPU/OS intensive.

Any idea how calling Timer.Stop()/Timer.Start() this way may impact performance (in terms of latency)?

Answer 1

Use a simple timespan or integer variable as a flag. When the timer ticks, it checks against a Stopwatch object to see how much time has elapsed since the flag was last udpated. If it’s longer than your timeout value you trigger your watchdog code.

Now, instead of resetting your timer, other code can just use the stopwatch to update your timespan flag value when a new packet comes in.

You should also either set your timer’s tick interval to about 1/2 of what you want the actual timeout duration to be, or have code in the event to set your interval so your next tick event is just a few milliseconds after you would timeout if the connection was severed now. Otherwise you could end up waiting almost twice as long as the timeout duration in the situation where your last packet arrived very soon after a tick event.