|
|
Yeah, except your article (Stop self advertising btw, it makes you look desperate) doesn't work. As many people have pointed out to you, windows is NOT a real-time OS, it is IMPOSSIBLE to have a timer on windows accurate to 1us, 10us or even 500us. Unless you use the MMTimer, windows will ALWAYS slice it to around 15ms. Stop being so ignorant please.
|
|
|
|
|
So according to you Poll should only accept a number between 1 and 15? And I think that you are also saying that 15 ms is greater than 15 μs which is not correct...
If you 15ms you have 15000μs so achieving something when there is such a large excess seems trivial to me, it's when you start taking into account small fractions of the 15ms slice used that you get into the realm where you may not get 15 whole ms and thus reliability can't be guaranteed beyond a 15ms window... but that is still more then you should need.
I appreciate your input and hope you gained something from reading this article!
|
|
|
|
|
I hope you realise your reply made no sense.
Firstly, how is 15ms not larger than 15us when 15ms is 15000us?
Secondly, I never once mentioned Poll.
Finally, let me re-iterate what I was saying.
No matter what you do, it is impossible to be guaranteed intervals of less than 15ms on Windows. You seem to think this isn't important, when it clearly is.
I've seen a lot of people posting on here and on StackOverflow giving valid reasons for needing guaranteed intervals of less than 1ms. I personally only need guaranteed 10ms, but I can't even get that.
|
|
|
|
|
What about my reply made no sense, That semantic (kernel scheduling) is performed in all operating systems which use threads.
Sometimes the kernel is written in a way so that it's context switches from user mode to supervisor mode can be sliced to make efficient use of the threads. This is where Time Slicing comes from....
During the time this switching is occurring the kernel may take more or less time than you like,t his is the semantic of a Real Time Operating System.
Unix also performs the same context switching so Windows or Unix or Linux does not matter.
What matters is the ability of the kernel to set a priority to the threads which can indicate that certain threads should not be blocked because they require a real time context.
Both Windows and Linux/Unix can do this but then you have the problem that the context switch itself takes time.
In short, I was simply stating that if you have 10ms then you have 1000μs, if you need guaranteed intervals you must either perform a few extra or a few less intervals at one point to maintain in sync with the scheduler.
Changing the scheduler frequency isn't going to reduce the amount of time your code takes to execute, it will only ensure that the switches are happening while your logic is executing.
|
|
|
|
|
Works like a charrm, thanks!
|
|
|
|
|
I'm using this timer to schedule task that we need a consistent wait duration for. I have been using the MM Timer to wait for about 300 ms on "OneShot" then if it meets a criteria then it fires again. I've been timing the MM Timer calls with the Stopwatch and it is giving very regular inconsistencies. Every time we run the software, every 4-10 waits will be high by about 30-40 ms and on each individual run the number of waits between error is about the same, i.e. it'll error every 4-5 waits one trial and every 9-10 waits another trial. Additionally I time the inter-wait times which we know fairly well and the SW times this with no hiccups.
Has anyone else seen this happen with the MM_Timer? Or does anyone have an idea about what might be going wrong? Is it possibly because my resolution is set too high?
Here's the relevant code:
private Multimedia.Timer mmTimer = new Multimedia.Timer();
private Stopwatch scanClock = new Stopwatch();
mmTimer.Resolution = 1;
mmTimer.Period = 330;
scanClock.Start();
runDwell();
private void runDwell()
{
dwellPreTick = scanClock.ElapsedTicks;
mmTimer.Start();
}
private void mmTimer_Tick(object sender, EventArgs e)
{
dwellPostTick = scanClock.ElapsedTicks();
transPreTick = scanClock.ElapsedTicks();
if(stuffIsDone){
transPostTick = scanClock.ElapsedTicks;
scanClock.Stop();
storeTimingInfo();
}
else{
transPostTick = scanClock.ElapsedTicks;
storeTimingInfo();
runScanDwell();
}
}
Let me know. Thanks.
|
|
|
|
|
Hi,
The thread on which the timer runs remains alive after the timer is disposed. Is there any way to kill that thread, or is this behaviour by-design?
Thanks
Lee
|
|
|
|
|
Thank you Leslie Sanford!!
|
|
|
|
|
Love the control. It's great and allows me to get very close to 100ths of a second accuracy in triggering my reads. I'm finding that over time (even just 3 or 4 minutes) the timer will drift slightly and end up straying off the time I set (at least according to the system clock)
Is there any way to correct for that?
Thanks.
P.S. I posted this as a question on the VB.Net board as well to get other peoples input.
|
|
|
|
|
You will get timer drift in windows xp, the only way to address this is to do a manual check of the time when the event fires and if necessary then fire the event twice to make up for the timer drift. Its not ideal but it's the only way to address this.
Microsoft fixed the timer drift in windows 7, but it appears that they too just fire the event twice when they see that the timer has drifted. I suspect that the timer drift is directly related to the hardware you're using.
|
|
|
|
|
I have written an application that uses several (at one time, up to 4) MultimediaTimers running simultaneously. Some perform GUI update tasks while others talk to hardware. When all of them are running, resource-usage is high, but does not seem to be overwhelmingly so.
I have run into a few situations where I am repeatedly able to show that a MultimediaTimer will not re-start properly (e.g. no Tick events will occur after a Stop()/Start() cycle - verified with breakpoint debugging). My evidence that it is the MultimediaTimer causing this issue is that when I replace it with a System.Timers.Timer, the issue disappears (albeit with less than desirable timing characteristics).
I do like the accuracy advantages that the MultimediaTimer brings, but I cannot use it if it does not function well in a multiple-timer environment.
Has anyone else seen this? Is there a fix/workaround?
|
|
|
|
|
I 've found the same problem when i used this class.
it seems that after several start and stop ,the timer will work with start very well, but its Tick will not work property, partially in fact, and will never stop.
Winform's Timer doesn't have this kind of problem, although it is not accuracy at all with teen-ms.
|
|
|
|
|
hello,
I have a WPF application using the above timer, and it works perfect, but from time to time I get the following error:
CallbackOnCollectedDelegate was detected
Message: A callback was made on a garbage collected delegate of type 'CWUserInterface!Multimedia.Timer+TimeProc::Invoke'. This may cause application crashes, corruption and data loss. When passing delegates to unmanaged code, they must be kept alive by the managed application until it is guaranteed that they will never be called.
I need to specify that each timer instance goes into it's own thread, and I think that is where the error is coming from, now I also have read in some posts that I have to keep a pointer during the lifetime of the application to the control handler or something like that and frankly I don't quite get hot to do this, any help would be much appreciated
Thank you in advance
L.E.
Ok so I have placed try catch blocks all over the Timer code too try to catch the exception and I did at one point, seems it crashes in the OnTick event with an OutOfMemory exeption so something weird is going on
modified on Wednesday, April 13, 2011 3:50 AM
|
|
|
|
|
Quite long time I busy with development of integration none standard hardware with windows software, the software can talk simultaneously with different hardware and above that talk through tcp communication line with other software and other computers. Due to this I am looking for timers which can give better possibility to handle and synchronize such kind processes.
Last time I read about multimedia timers and found on internet this article.
First question which have been raised is how far the multimedia timer is better that let say System.Timers.Timer.
I have built simple test program with two timers. There are instantiated two timer (the class from this article and System.Timers.Timer). Two buttons on the form: Start and stop.
Both buttons start and stop both timers at the same time.
Each timer has own tick event, within the event they write when the event happaned (Console.Writels("Timer 1/2" & Now.TimeOfDay.TotalMilliseconds.tostring))
Both timers always had the same interval. I played with different intervals (5,10,20,50,100,200,500 ms).
The behavior was always the same: at the same time there were events from both timers up to 1 ms precision, no exceptions was found.
Only difference was in multimedia timer:
It gives more events inside the same timestamp. Suppose interval is 5 ms. if the program had not time chunk from CPU then after receiving the chunk the program shows simultaneously 3-4 fired events.
But from mine point of view it is pure waste of computer resources.
So, then is the question: What is advantage of using multimedia timer in comparing with System.Timers.Timer?
The test shows: there are no advantages.
Regards, Jamal
|
|
|
|
|
It sounds like your test is flawed due to its simplicity. Are there any resource-consuming processes or threads running in the background during this test? If not, I would not expect a significant difference in performance between the two timers as the message queue used by the System.Timers.Timer has relatively low traffic and can respond to timer messages in an accurate fashion. Try the same test, but with multiple background threads consuming resources (e.g. performing GUI changes), and see if the results remain the same. If they do, then you may have a point. I certainly have noticed a difference in my graphical application between the two timers.
That being said, it sounds like you are looking for a timer for the synchronization of TCP communication, and I would guess, without experience, that both of these timers are insufficient for that application.
All the best.
|
|
|
|
|
Thank you very much for this code - it's solved a nuggety little issue I was facing in 10 minutes flat instead of hours of doing my own coding. So thanks again.
|
|
|
|
|
Can I start up several instances of the timer? whit key work "new Timer"
br, Patrik
|
|
|
|
|
First of all, thanks for wrapping mmtimer. However, I did some bench marking and here are the results:
Period = 50, Res = 1, Min = 41.308, Max = 61.152, Avg = 49.994
Period = 20, Res = 1, Min = 16.921, Max = 21.685, Avg = 19.996
Period = 10, Res = 1, Min = 4.899, Max = 14.656, Avg = 9.996
Period = 5, Res = 1, Min = 0.033, Max = 17.212, Avg = 4.993
Period = 1, Res = 1, Min = 0.031, Max = 3.503, Avg = 0.993
Period = 1, Res = 1, Min = 0.031, Max = 2.24, Avg = 0.993
Period = 1, Res = 1, Min = 0.032, Max = 2.569, Avg = 0.993
Period = 1, Res = 1, Min = 0.019, Max = 3.452, Avg = 0.992
Period = 1, Res = 1, Min = 0.017, Max = 2.622, Avg = 0.996
I integrated the HiPerfTimer to get the exact tick count since elapsed event. I am not sure where is the problem, but reading msdn about managed vs unmanaged code I can see why the performance degradation.
http://msdn.microsoft.com/en-us/library/ms973872.aspx
Any hints why? I used the mmTimer on native C++ and I used to get exact timing. Wrapping mmTimer in managed code breaks its accuracy. Any help will be greatly appreciated. I apologies if I am double posting of this issue.
thanks
Laith
modified on Thursday, June 10, 2010 1:50 PM
|
|
|
|
|
Hi Leslie,
Just wanted to say thanks very much for providing this class. I've been making an Asteroids-style game and the standard C# timers are far too inconsistent for doing moving graphics. This really helped a lot.
Kind Regards,
Julian
|
|
|
|
|
Hello,
Is this class thead safe ?
Let say the two thread share the same timer, and they both call the stop function, the kill will be called twice on the same timer id, which will cause an assertion. is this right ?
Another thing, lets say that the user used the timer, and supplied slow function that acts as the event hanlde of onStopped. wouldn't it interfere with other instances of the timer ?
thanks,
berlus
|
|
|
|
|
Hi Leslie,
First let me thank you for providing us with this great class. I'm working on an audio/midi sequencer and have been struggling to find a way to get high precision timing firing events.
This class has been written in 2006. Is it still what you would recommend today as the best timer available or have you found something else? Do you know if that is the solution that professional multimedia software developpers would use in their products?
Also, do you know of a way in C# to access the timing capabilities of modern professional audio sound cards (adat, word clock,..)?
Thanks again.
|
|
|
|
|
Hi,
The multimedia timer class is really usefull to me. We use C# on WIN XP32 to control our machines. The main reason is for its 'good' resolution (around 1 ms).
I would like a Wait() function we can call in any thread at any time to wait for the specified time. So there can be multiple waits active at the same time. Since the number of multimedia timers is limited to 16 (I read somewhere) and to reduce the CPU load, (since each multimedia timer creates a thread) I was thinking of using only 1 multimedia timer for this job.
As soon as one calls the Wait() function, it registers the time at which it has to expire and an event to be called when the time has expired. Next the Wait() function will wait until that event gets set. The multimedia timer gets setup for this time and as soon as the timer has expired, it will signal the event for the appropriate wait call. If a 2nd Wait() gets called before the first one has expired and that second timer has to expire before the first one, it should cancel the current multimedia timer and setup the new (shorter) time. As soon as that time has expired it should check if there are other timers expired yet (signal them as well) and finally setup the multimedia timer with the remaining time for the next timer to expire.
Has anyone ever made something like this, or are there other (easier) ways to achive this ?
|
|
|
|
|
Your best bet is to use Query Performance Timer and run it in a separate thread with sleep and set to high priority thread. You can instantiate multiple timers. The mmTimer purpose is method invocation and may not be what you are looking for. There are many articles on Query Performance Timer and I actually used it to get the mmTimer performance (see above posting by me).
|
|
|
|
|
Is 16 instances the upper limit?
|
|
|
|
|