I want to have a running timer in my app which displays the seconds elapsed upto 2 decimal places e.g. 2.31 seconds. I'm using System.Threading.Timer for this and I'm setting the Timer object to call refreshTimeBox() function every 10 milliseconds (because I want the seconds upto 2 decimal places). But, the timer lags behind. And as the time passed increases, it lags more and more behind. I'm guessing its because refreshTimeBox() is taking too long to complete. But, I also tried calling refreshTimeBox() every 100 milliseconds instead. The timer still lags. The only difference is that the lag becomes noticeable after a longer time in this case than in the case where I use 10 milliseconds as interval. I have the following code to initialize the timer:
timer = new Timer(refreshTimeBox, null, 0, 10);
The following is the code for refreshTimeBox:
public void refreshTimeBox(object param)
{
time += 0.01f;
Dispatcher.BeginInvoke(WriteTimeBox);
}
The following is the code for WriteTimeBox:
public void WriteTimeBox()
{
TimeBar.Text = time.ToString("0.00");
}
time is the variable which stores the time elapsed and TimeBar is the text box which is being updated.
I want as accurate a timer as possible. Please help me with this. Thanks.
If you want to display the amount of time that has elapsed since a particular event in the past, then the best way to do that is to store the time at "time zero", e.g. startTime, and then, in your timer event, computer the time that has elapsed by subtracting startTime from the current time, and displaying the difference.
You can't rely on timer events being delivered at exact intervals. This isn't a realtime system. Added to which, you should be aware that BeginInvoke is likely requesting that the method call occur on a different thread to the current one, and that different thread may not be able to dispatch that method call at the current time.
You could also use a stopwatch
System.Diagnostics.Stopwatch sw=new System.Diagnostics.Stopwatch();
sw.Start();
And in the update function
TimeBar.Text = sw.ElapsedMilliseconds;
Then you don't have to worry about UTC issues
Timers always have the possibility of lagging. What you need to do is store when you started, then compare it to the current time.
private DateTime startTime;
public void startTimer() {
startTime = DateTime.Now;
}
public void refreshTimeBox(object param)
{
Dispatcher.BeginInvoke(WriteTimeBox);
}
public void WriteTimeBox()
{
TimeSpan ts = DateTime.Now - startTime;
// See http://msdn.microsoft.com/en-us/library/1ecy8h51.aspx for TimeSpan formatting.
TimeBar.Text = ts.time.ToString("s.ff");
}
Related
I have a piece of code that records the current time (DateTime.UtcNow) as a "deadline", sets up an System.Threading.Timer, and when the timer elapses checks if the deadline has been reached. It does this check by comparing the current time (DateTime.UtcNow) to the recorded deadline.
Here is a simplified code example that illustrates the principle:
class DeadlineChecker
{
private DateTime deadline;
public DeadlineChecker()
{
int waitingTimeInMilliseconds = 1200;
TimeSpan waitingTime = TimeSpan.FromMilliseconds(waitingTimeInMilliseconds);
this.deadline = DateTime.UtcNow + waitingTime;
System.Threading.Timer timer = new System.Threading.Timer(TimerElapsed);
timer.Change(waitingTimeInMilliseconds, Timeout.Infinite);
}
private void TimerElapsed(object state)
{
if (this.HasDeadlineBeenReached())
{
[...] // Do something
}
[...] // Cleanup (dispose timer etc.)
}
private bool HasDeadlineBeenReached
{
get
{
// This is only called from TimerElapsed(), so
// this should always return true, right?
return (this.deadline <= DateTime.UtcNow);
}
}
}
I have now had a case where HasDeadlineBeenReached unexpectedly returns false. It appears that my assumption that HasDeadlineBeenReached always returns true in the example code above is wrong.
Can someone explain why? Before I refactor I would like to understand the issue.
Even taking the documented fact into account that DateTime.UtcNow has a 15ms resolution, I would not have expected that two snapshots of DateTime.UtcNow taken at times X and Y would report a time span that is smaller than what has actually elapsed (Y - X). Even if both snapshots are 15ms off, the time span between them should still be equal to the time that has elapsed due to the timer?
EDIT: What the real code tries to do is to set up a deadline, check that deadline when certain events occur, and "do something" when the deadline has been reached. The "timer elapsed" event is merely one of the many events that trigger the deadline check and is there to guarantee that "do something" happens in the absence of other events. It doesn't matter whether "do something" happens on time or a few milliseconds or even a second later than the deadline - there just needs to be a guarantee that it happens.
EDIT 2: I made a few minor changes to the code example after accepting the answer - bad style, I know, but maybe this makes the question a bit more intelligible to future generations.
You wrote:
// This should always return true, right?
No, it will only return true when deadline is in the past. I appreciate that you created a deadline that was 1200ms into the future and then told a timer to fire after 1200ms and are expecting the deadline to be in the past the instant the timer fires, but in reality the timing of timers and the accuracy of the clock is such that you might well reasonably observe your code not firing at the exact milliseconds you expect, and the clock not returning the exact milliseconds you expect, and as a result your deadline is still in the future when the code runs
I suggest you adjust your timing strategy; set your timer for a half the interval you want to be "accurate" to interval, check your deadline to be in the past using the same logic, and tolerate the imprecision (don't promise the user that they can schedule the notification of their meeting with 1 millisecond precision)
I have a scenario where I want to track if my Console application is alive or dead (due to exceptions etc..).
While the console application is performing its processing I want to have a mechanism where it has a timer which keeps on calling a reporting method after every N minutes, this method being called updates a time stamp in the DB.
So :
1 - Console application starts
2 - Reports time stamp
3 - Keeps on doing its task (while in parallel it reports again after N seconds)
I know I can spawn a thread and make it sleep and wake up again after the "N" minutes but how reliable is that since threads might not fire until resources are free and the "N" minutes might not be valid anymore since the thread will fire on its own time.
How can I make sure the reporting is done in parallel while the processing is going on?
Rather than create your own thread use a built in Timer:
private DateTime startTime;
private System.Threading.Timer theTimer;
Start the timer:
this.startTime = DateTime.Now;
TimerCallback callback = TimerTick;
this.theTimer = new System.Threading.Timer(callback, null, 0, 1000);
The callback method:
void TimerTick(object stateInfo)
{
TimeSpan currentTime = DateTime.Now - startTime;
// Do your stuff here.
}
This creates a timer with no delay that fires every second.
MSDN page
The first integer is the dueTime amount of time to delay before the callback method is invoked. Specifying zero starts the timer immediately.
The second integer is the period - i.e. the time interval between invocations of the callback mathod.
You need to either make sure that your processing in TimerTick takes less than the period you have specified or ensure that it it re-entrant - i.e it can cope with being called before the previous invocation has completed. How you do that - or indeed whether you can do that - depends on your application.
Scenario:
In a Winform application(C#), I have a Datagridview in which I have to display 4 countdown timers in the format "mm:ss".
Time Interval must be 1000ms.
I was counting the timer down in the elapsed event of system.timers.timer.
On all 4 timers I'm starting to countdown from 2 mins (02:00).
Issue:
It takes more time(125 seconds) than 2 mins, to reach 00:00.
Similarly for 4 mins it takes 7-10 more(247 -250) seconds to reach 00:00
Timers on systems are somewhat of an inaccurate beast. Better systems generally provide better timers but even the best system has slippage.
You also need to remember that your process isn't going to be in "full control" 100% of the time, it will at times be pushed into the background and have to share the processor with other applications so whilst it's does its best to keep track of the time.
What you probably want is a High Precision Timer (aka stopwatch) in C#. Have a look at This thread and This article on selecting timer mechanisms for some more information.
If you need time resolution of that type (i.e. actual clock or countdown clock), you should use the real-time clock.
You still use a timer with sub-second resolution to fire frequently enough for display purpose, but you don't add up those times, you use the real-time clock to get the real elapsed time (DateTime.Now - startTime).
First off you should run this little test and see the drift in near real-time. I lose a 1 second after 72 timer elapsed events (this is with very little actual work).
using (var timer = new Timer(1000))
{
var start = DateTime.Now;
var i = 0;
timer.Elapsed += (sender, args) => Console.WriteLine("{0} -> {1}", ++i, (DateTime.Now - start).TotalMilliseconds);
timer.Start();
Thread.Sleep(130*1000);
}
I'm not sure how precise your app needs to be but you can get "good enough" by using the delta between the start time & now and subtracting that from your initial value and killing the timer at zero. You will lose seconds with this approach and there's a reasonable chance that lost second could happen # 0:00 causing a -0:01 tick, which you will need to handle.
var countdownSeconds = 120;
var startedAt = DateTime.Now;
var timer = new Timer(1000);
timer.Elapsed += (sender, args) => Display(countdownSeconds - (int)((DateTime.Now - startedAt).TotalSeconds));
timer.Start();
//- be sure to dispose the timer
I have a dll consumed by a service. Its basic job is to run every X minutes and perform some system checks.
In my dll I have a top level class that declares a System.threading.timer and a Timercallback.
The constructor for the class initialises the timerCallback with my thread function.
In my "Onstart" handler I initialise the timer with the timercallback and set the next time to fire and interval time. In my case its every 10 minutes.
Usually in these 10 minute checks there is nothing to do but the service is forced to do something at least once every day at a set time.
My problem: I am finding that during testing, the time the daily check is carried out every day is slowly drifitng away from the desired start time of 8.30. e.g. over about 20 odd days my time has drifted from 08.30 to 08.31.35. It drifts about 4 - 6 seconds every day.
My question: does anyone know why the time is drifting like this and how can I make it stick to its allotted time?
thanks
The time "drifts" because the timer is simply not that precise. If you need to run your code as closely as possible to a certain interval, you can do something like this:
public void MyTimerCallback(object something) {
var now = DateTime.UtcNow;
var shouldProbablyHaveRun = new DateTime(
now.Year, now.Month, now.Day,
now.Hour, now.Minute - (now.Minute % 10), 0);
var nextRun = shouldProbablyHaveRun.AddMinutes(10.0);
// Do stuff here!
var diff = nextRun - DateTime.UtcNow;
timer.Change(diff, new TimeSpan(-1));
}
...assuming you are using a System.Threading.Timer instance. Modify the example if you are using any other type of timer (there are several!).
Why not check every minute if the action needs to be performed?
ie:
if (DateTime.Now.Minute % 10) == 0
it takes a finite amount of time to do the operations you are doing in your timer method handler, so it makes sense that it's not going to happen every 10 minutes to the second, especially if you are scheduling the next wakeup after doing your checks and such. if you are already checking anyway for answering is it time to do this, you should make your timer fire more frequently to satisfy the resolution you need and trust your check of when it should execute something to make sure that it does. you probably need some sort of persistence to make sure it doesn't execute twice (if that is important) in case there is a shut down/restart and the state of knowing whether it has already run is not still in memory.
Here is my take:
while ((DateTime.Now - lastRunTime).TotalSeconds < 600)
CurrentThread.Sleep(1000);
or just register a windows timer and execute in response to the event/callback
public static void Main()
{
System.Timers.Timer aTimer = new System.Timers.Timer();
aTimer.Elapsed+=new ElapsedEventHandler(OnTimedEvent);
// Set the Interval to 600 seconds.
aTimer.Interval=600000;
aTimer.Enabled=true;
Console.WriteLine("Press \'q\' to quit the sample.");
while(Console.Read()!='q');
}
// Specify what you want to happen when the Elapsed event is raised.
private static void OnTimedEvent(object source, ElapsedEventArgs e)
{
Console.WriteLine("10 minutes passed!");
}
Timers aren't exact, just approximate. Don't use the logic of "just add 10 minutes". Each time your timer fires, you need to check for time skew and adjust.
eg. If you say "wake me up in 10min", and it wakes you up in 10min 1sec, then the next timer needs to be 9min 59sec, not 10min.
Also, you want to assign your next timer at the end of your logic.
eg. say you want to start taskA every 10min and it takes 2 seconds to run. Your timer starts and 10 minutes later it wakes up to run taskA. It kicks off, finishes, now you add 10 minutes. But it took 2 seconds to run your task. So 10 minutes from the time your code ran will be skewed by 2 seconds.
What you need to do is predict the next time you need to run and find the difference between now and then and set the timer to that difference.
I have a windows service handles events triggered by a System.Timers.Timer.
I want to set the interval of that timer to 3 months.
The Interval property of the System.Timers.Timer is an Int32 in millseconds, and Int32.MaxValue is smaller than 3 months in milliseconds.
What should I do?
You would re-think your design. Store the next time you want to execute your event (e.g. registry, file, database, ...) and then wake up periodically to check whether that time has passed. Even if you could set a System.Timers.Timer for 3 months, the system would likely reboot before the timer went off and you'd lose your event.
Another option would be to use a scheduled job executed by the Windows Scheduler. It would run a small program that sends your service a message saying that the event has occurred. This would be less resource intensive - though more complex - than waking up periodically to check whether the 3 months had elapsed.
I would use Quartz.net - the opensource enterprise job scheduler - http://quartznet.sourceforge.net/
You may use CRON like syntax- http://quartznet.sourceforge.net/tutorial/lesson_6.html
& you may store relevant job state to a DB easily (just incase the machine dies, which it will) - http://quartznet.sourceforge.net/tutorial/lesson_9.html, and lots more usefulness.
I've used Quartz.net on several production systems and to my knowledge the processes are still running today :)
Why not use System.Timer - http://quartznet.sourceforge.net/faq.html#whynottimer
Good luck!
You can't run your PC for continuously for 3 month. If application is closed timer will also close. On restarting application results the timer to restart from beginning.
If you want to fire event at interval of 3 months you must keep information about the total time elapsed by the timer at the time of exiting application.
Updated
So you have to divide your interval in some parts and set a counter on every elapse and increment it.Check it in every elapse until it reaches to 3 months.
e.g.
int interval = 10 * 24 * 60 * 60 * 1000; // Time interval for 10 days
int counter = 0;
private void timer1_Elapsed(object sender, System.Timers.ElapsedEventArgs e)
{
counter++;
if (counter == 9)
{
//do your task for 3 months
//since counter increments 9 times at interval of 10 days
//so 9*10=90 days i.e. nearly equal to 3 months
counter = 0;
}
}
Had the same problem, except that it was a generic system that could do the same thing with completely adjustable intervals, from milliseconds to months. Well, was supposed to. Turned out it indeed messed up on intervals larger than 24.8 days because of this.
In my case, "rethinking the approach" was of out of the question, since it was just one small problem sub-case of a much larger Windows service system.
The solution was rather simple, but do note I had a side system that supplied me with the next execution as DateTime; the timer's job was just to match that to actually execute the task, so it calculated the interval simply by subtracting DateTime.Now from that.
In this case, all I needed to do was keep an overflow boolean alongside my timer object, and setting that when checking that interval against Int32.MaxValue:
private Timer _timer;
private Boolean _overflow;
private void QueueNextTime(DateTime thisTime)
{
TimeSpan interval = this.GetNextRunTime(thisTime) - DateTime.Now;
Int64 intervalInt = (Int64)((interval.TotalMilliseconds <= 0) ? 1 : interval.TotalMilliseconds);
// If interval greater than Int32.MaxValue, set the boolean to skip the next run. The interval will be topped at Int32.MaxValue.
// The TimerElapsed function will call this function again anyway, so no need to store any information on how much is left.
// It'll just repeat until the overflow status is 'false'.
this._overflow = intervalInt > Int32.MaxValue;
this._timer.Interval = Math.Min(intervalInt, Int32.MaxValue);
this._timer.Start();
}
// The function linked to _timer.Elapsed
private void TimerElapsed(object sender, ElapsedEventArgs e)
{
this._timer.Stop();
if (this._overflow)
{
QueueNextTime(e.SignalTime);
return;
}
// Execute tasks
// ...
// ...
// schedule next execution
QueueNextTime(e.SignalTime);
}
This is simplified, of course; the real system has try/catch and a system to abort on external stop commands. But that's the gist of it.
I would create an exe application and run as a part of scheduled Windows Task.