Strange timer problem
-
I need to know when a user defined time has elapsed for communication reasons. The time is typically within the range of 1 to 20 ms. I am fully aware of windows not being a RTOS, but that is not the problem. My problem is that I get much better results with a PII 800MHz CPU running WinNT than with a P4 2.4GHz CPU running WinXP. I have tried both a waitable timer solution and a multimedia timer solution with exactly the same results. There is no difference between setting the mm-timer resolution to 1 or 0. While trying to nail this down I have created a small app that simply creates a timer and waits for it with WaitFor...() with no other threads involved. If I set the due time to 10ms I get variations between 9 and 10ms in the PII environment, but in the P4 environment I get variations between 0 and 15ms. I would understand if the timer event got signaled later than expected in the PII environment but this is not the case, it sometimes gets signaled long before the expected due time. Boosting process or thread priorities doesn't help. In the original app where I discovered the problem the time differences are measured with independant hardware. MSDN documentation about waitable timers says something like "the timer accuracy depends on the hardware capability". I just don't understand why "better" hardware performance is worse. This is how I do it in pseudo-code: CreateWaitableTimer QueryPerformanceCounter SetWaitableTimer WaitForSingleObject QueryPerformanceCounter What's wrong with this picture? How can "better" hardware and OS perform worse than older? Is it an OS or BIOS setting I am unaware of? Any comments are very welcome. Thanks in advance -- Rog
-
I need to know when a user defined time has elapsed for communication reasons. The time is typically within the range of 1 to 20 ms. I am fully aware of windows not being a RTOS, but that is not the problem. My problem is that I get much better results with a PII 800MHz CPU running WinNT than with a P4 2.4GHz CPU running WinXP. I have tried both a waitable timer solution and a multimedia timer solution with exactly the same results. There is no difference between setting the mm-timer resolution to 1 or 0. While trying to nail this down I have created a small app that simply creates a timer and waits for it with WaitFor...() with no other threads involved. If I set the due time to 10ms I get variations between 9 and 10ms in the PII environment, but in the P4 environment I get variations between 0 and 15ms. I would understand if the timer event got signaled later than expected in the PII environment but this is not the case, it sometimes gets signaled long before the expected due time. Boosting process or thread priorities doesn't help. In the original app where I discovered the problem the time differences are measured with independant hardware. MSDN documentation about waitable timers says something like "the timer accuracy depends on the hardware capability". I just don't understand why "better" hardware performance is worse. This is how I do it in pseudo-code: CreateWaitableTimer QueryPerformanceCounter SetWaitableTimer WaitForSingleObject QueryPerformanceCounter What's wrong with this picture? How can "better" hardware and OS perform worse than older? Is it an OS or BIOS setting I am unaware of? Any comments are very welcome. Thanks in advance -- Rog
Maye a different crystal oscillating frequency is being used between the two machines. CPU speed is irrelevant.
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
-
I need to know when a user defined time has elapsed for communication reasons. The time is typically within the range of 1 to 20 ms. I am fully aware of windows not being a RTOS, but that is not the problem. My problem is that I get much better results with a PII 800MHz CPU running WinNT than with a P4 2.4GHz CPU running WinXP. I have tried both a waitable timer solution and a multimedia timer solution with exactly the same results. There is no difference between setting the mm-timer resolution to 1 or 0. While trying to nail this down I have created a small app that simply creates a timer and waits for it with WaitFor...() with no other threads involved. If I set the due time to 10ms I get variations between 9 and 10ms in the PII environment, but in the P4 environment I get variations between 0 and 15ms. I would understand if the timer event got signaled later than expected in the PII environment but this is not the case, it sometimes gets signaled long before the expected due time. Boosting process or thread priorities doesn't help. In the original app where I discovered the problem the time differences are measured with independant hardware. MSDN documentation about waitable timers says something like "the timer accuracy depends on the hardware capability". I just don't understand why "better" hardware performance is worse. This is how I do it in pseudo-code: CreateWaitableTimer QueryPerformanceCounter SetWaitableTimer WaitForSingleObject QueryPerformanceCounter What's wrong with this picture? How can "better" hardware and OS perform worse than older? Is it an OS or BIOS setting I am unaware of? Any comments are very welcome. Thanks in advance -- Rog
This problem is not a processor problem rather a motherboard chipset problem. PerformanceCounter problems have been reported by other people, and are attributed to problems with certain chipsets. Specifically, some chipsets fail to carry the rollover from bit 23 into bit 24, or do so spuriously, depending on the interval between successive calls to QueryPerformanceCounter. Ant. I'm hard, yet soft.
I'm coloured, yet clear.
I'm fuity and sweet.
I'm jelly, what am I? - David Williams (Little Britain) -
This problem is not a processor problem rather a motherboard chipset problem. PerformanceCounter problems have been reported by other people, and are attributed to problems with certain chipsets. Specifically, some chipsets fail to carry the rollover from bit 23 into bit 24, or do so spuriously, depending on the interval between successive calls to QueryPerformanceCounter. Ant. I'm hard, yet soft.
I'm coloured, yet clear.
I'm fuity and sweet.
I'm jelly, what am I? - David Williams (Little Britain)That's true. But even if I could be exposed to such a chipset and it could be an error in the measurement method regarding my test application, it doesn't explain why the PII WinNT env. is more accurate when measuring with hardware. Thanks anyway -- Rog
-
That's true. But even if I could be exposed to such a chipset and it could be an error in the measurement method regarding my test application, it doesn't explain why the PII WinNT env. is more accurate when measuring with hardware. Thanks anyway -- Rog
I agree given that it is the same hardware (chipset) you are running the tests on. Ant. I'm hard, yet soft.
I'm coloured, yet clear.
I'm fuity and sweet.
I'm jelly, what am I? - David Williams (Little Britain)