Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
need actual time based events
- Thread starter XWalrus2
- Start date
SemperFiDownUnda
Instructor
can you elaborate a bit more?
There are a few examples of using the media timer (give greater accuracy.
but if you read the help for a the timer you'll see that the timer is based on milliseconds (1/1000th of a second) so if you want something to happen ~ 10 times a second then you would have to figure out how long the routine takes to execute once and adjust the timer or you could say it will execute a max of 10 times a second and put the timer's interval property to 100 (100/1000 of a second or .1 second)
There are a few examples of using the media timer (give greater accuracy.
but if you read the help for a the timer you'll see that the timer is based on milliseconds (1/1000th of a second) so if you want something to happen ~ 10 times a second then you would have to figure out how long the routine takes to execute once and adjust the timer or you could say it will execute a max of 10 times a second and put the timer's interval property to 100 (100/1000 of a second or .1 second)
- Thread starter
- #3
SemperFiDownUnda
Instructor
Actually the timer is based on actual time but you have to understand timers.
if you set up a timer to go off 10 times a second then it pretty much will fire off 10 times a second. Now things that can effect the event actually triggering are some rule about the timer event.
1) for a given timer there will only ever be one event for that timer waiting in the msg stack. IE if the timer goes off Windows checks to see if there is a timer event for that timer already waiting to be processed. If there is the event it disgarded.
2) The amount of times the actual code gets triggered is based upon how much work the machine is doing. Now if I have a timer event that fires off 10 times a second but the actual event takes 80 milliseconds on one machine that is a lets say 2Ghz machine and another machine is 1Ghz then the code might take 160 milliseconds then yes the 2Ghz machine could end up executing the code 10 times a second while the 1Ghz may only get 5 maybe 6 executions in during that time.
This doesn't even factor in that other processes can pull time away from your app also. Rule of thumb the faster the machine with more ram and doing less in other processes the closer you'll get to the timer event code working at its optimal speed.
Also have to concider what is in the event stack. Have you ever had a VB program that is going mad in some long procedure and you click a few things on the form but it takes a while to actual do the code for those clicks? This is because the OS sends the events to the windows msg que right away but since your code is executing some massive code and VB is single threaded they just wait until its done. When a VB program gets to the top level of the call stack control passes back to the event handler and those msg (events) get handled in the order they where recieved.
There are lot to think about when dealing with timers.
if you set up a timer to go off 10 times a second then it pretty much will fire off 10 times a second. Now things that can effect the event actually triggering are some rule about the timer event.
1) for a given timer there will only ever be one event for that timer waiting in the msg stack. IE if the timer goes off Windows checks to see if there is a timer event for that timer already waiting to be processed. If there is the event it disgarded.
2) The amount of times the actual code gets triggered is based upon how much work the machine is doing. Now if I have a timer event that fires off 10 times a second but the actual event takes 80 milliseconds on one machine that is a lets say 2Ghz machine and another machine is 1Ghz then the code might take 160 milliseconds then yes the 2Ghz machine could end up executing the code 10 times a second while the 1Ghz may only get 5 maybe 6 executions in during that time.
This doesn't even factor in that other processes can pull time away from your app also. Rule of thumb the faster the machine with more ram and doing less in other processes the closer you'll get to the timer event code working at its optimal speed.
Also have to concider what is in the event stack. Have you ever had a VB program that is going mad in some long procedure and you click a few things on the form but it takes a while to actual do the code for those clicks? This is because the OS sends the events to the windows msg que right away but since your code is executing some massive code and VB is single threaded they just wait until its done. When a VB program gets to the top level of the call stack control passes back to the event handler and those msg (events) get handled in the order they where recieved.
There are lot to think about when dealing with timers.
MichaelRed
Programmer
On the other hand, if -AS YOU STATE- you "NEED" the 100 millisecond interval, then Win is the WRONG system. Win will always service other tasks during idle time, and you cannot set an absoloute priority of tasks, so it will NEVER be a truly "REAL TIME" processing system. You CAN come close, using a variety of techniques, the first of which would be the use of a third party add in card with an independent 'clock' and the capability to issue hardware interrupt(s).
MichaelRed
m.red@att.net
Searching for employment in all the wrong places
MichaelRed
m.red@att.net
Searching for employment in all the wrong places
- Thread starter
- #7
SemperFiDownUnda
Instructor
hehehe goes back to my learning to read through contracts and requirement. "real-time" is not a valid requirement. Everything has latency, lets not get into quantum mechanics. So its saying something has to be "real-time" is not testable. Saying "The system shall operate with a 10 millisecond or less responce time" is better and even that has holes riddled though it. With PC's you'll find systems are made "Good Enough" ie. 100 times a second is "Good Enough" and as other people have said that is more do to the OS we use on them.
- Status
Similar threads
- Locked
- Question
