A real mystery involving timers 1

[Devin]

Fair warning: this is a complicated one...

I am working on making my Win98-compatible application run on XP. The application includes a scrolling graph, which must refresh at a high rate. Since timers don't "count down" while their code is executing, this was a always a problem, as the execution time was variable and longer than the refresh period required. As suggested (I think in the MS knowledge base), the problem was solved by using a number of timers, all running at the same time, each one adding a point to the graph. That was the only way to achieve sufficient refresh rate. Running the app on any Win98 system, even after moving from VB5 to VB6, seemed to work the same, regardless of system speed or compiler version. Running the exact same executable on an XP machine produced a much faster refresh rate. So, I made a separate version for XP that only uses 2 or 3, instead of 6, timers in parallel. I also adjusted some of the timer intervals until I got the right refresh rate. That worked great on the [XP Pro] development machine, whether I ran it through VB or compiled it and ran the executable directly. Then, I tried to run it on a test laptop (a significantly slower machine with less RAM running XP Home). To my surprise, the refresh rate was even faster than on the development machine! Based on my experience with the Win98 version, I did not expect the system to make a difference, since both the development and test machines were XP. If anything, I would have predicted a slower refresh rate on the slower system but saw the opposite. Somehow the difference is based on the system, though, but obviously it's not simply system speed. Of course I can tune the timers to match a given system, but I need a more robust and widely applicable solution.

Can anyone offer some insight?

 

[AndyGroom]

Perhaps the laptop is running at a lower screen resolution or lower colour depth, maybe it doesn't have as many things running in the background, or maybe it's simply got a better graphics chip with more on-board memory?

Try using the performance monitor on both machines (Ctrl-Alt-Del) to see if the processor usage is comparable - is the laptop less busy?

- Andy.

 

[strongm]

It probably depends on what the timer interval is set to. The various Windows operating systems have different resolutions. Eg W98 has a resolution of approx 55ms, whilst NT4's is about 10ms. And timer events don't queue.

So, using these two as an example, if your timer resolution was set to 20ms it would actually only fire at best every 55ms on the W98 box, but every 20ms on the NT4 box. In other words the NT4 box would appear to be running almost 3 times faster.

 

[TheTuna]

This is quite interesting. I was leaning towards what strongm said, but I beleive you said the laptop is running XP home as well... so, what's going on?

There could be differences in the FSB (front side bus) more video memory or more efficient useage of said memory, shared memory vs. independent video memory, and like Andy said, better video period or resolutions are different. Even the color depth could be making a difference here.

Lets get the full specs on the machines in question, I live for this stuff. Tuna - It's fat free until you add the Mayo!

 

[strongm]

System timer resolutions are independant of 'trivial' issues such as FSB speed, shared memory etc.

 

[Devin]

It's working now. If you're interested, see below the response from MS Support and my final solution.


Elan

Thank you for the insight on the timer control. It seems that the difference between 98 and XP was that XP has a higher precision timer resolution, and the guy who wrote this awful code set the original (win98 ver) intervals to absurdly low values like 5msec, so when I ran on XP, it did a much better job at achieving that interval.

The difference between 2 different XP machines seems to now be fixed. What I did was use more timers with longer durations, instead of only 2 short duration timers. 2 timers with 20ms intervals is not stable, but 6 timers with 60ms intervals is stable across different XP boxes. Also, with more timers, the execution time has less impact on aggregate refresh rate. My target refresh PERIOD is 10ms, and it can be derived that the actual refresh period is approximately equal to [(10*numberOfTimers+executionTime) / numberOfTimers] or [10 + executionTime / numberOfTimers]. This, of course, assumes that the queue delay is relatively small, but you can see that the Timer event execution time has less effect on the actual refresh period as the number of timers in increased.

Thanks again

Devin


----- Original Message -----
From: Elan Zhou
To: devin@gaumard.com
Sent: Friday, January 31, 2003 2:40 AM
Subject: SRZ030130000883:VB6:Question about using timer to refresh a scroll graph.


Dear Davin,



Thank you for contacting Microsoft. I am Elan Zhou from Microsoft Visual Basic developer support and it is my pleasure to be assisting you of this service request.



Based on my understanding to your description, you have a VB application that includes a scrolling graph. You use timers to refresh the graph at a high rate. Your current development tool is VB 6.0. The application originally runs on Win98 machines and the refresh rate is relatively consistent across Win98 machines. Now you are migrating this application to WinXP machines. However, you find that the refresh rate is not consistent across two WinXP machines, one is WinXP Professional and one is WinXP Home. If my understanding is not accurate, please feel free to correct me.



When you use a Timer control in the VB application, it internally calls the SetTimer() API to create a timer with the specified time-out value. You can check the following document for a description of the SetTimer() API.

http://msdn.microsoft.com/library/?...erence/timerfunctions/settimer.asp?frame=true

After that, the WM_TIMER message will be posted to the installing thread's message queue when a timer expires. As is described in the following document, the WM_TIMER message is a low-priority message and is only posted when no other higher-priority messages are in the thread's message queue.

http://msdn.microsoft.com/library/d...ference/TimerMessages/WM_TIMER.asp?frame=true

Generally speaking, Windows is not designed as a full real time operating system because there are many processes and threads running concurrently in the system. Especially in Windows NT/2000/XP, because there are also many service processes running in the background. If the thread that executing the VB application is very busy, or if the threads in other processes of the system are very busy, it may affect the responsiveness of the Timer control.



The analysis above is just a general explanation based on my understanding to your VB application. However, if possible, could you send me a simplified VB sample that can demonstrate more clearly what the symptom you encountered? Thus, I can run your sample on my machine to understand your problem more clearly and check what your code looks like. Maybe I can give you some more suggestions specific to your application.



I look forward to hearing from you. Thanks.



Best Regards,

Elan Zhou

Microsoft Developer support

mailto:elanzh@microsoft.com