Re: Strange timer problem
From: Roger Stoltz (rog.stoltz_at_home.se)
Date: 06/09/04
- Next message: sanjeev bhatia: "Visual studio hangs while debugging"
- Previous message: Ips: "Re: PCH (MFC DLL)"
- In reply to: Joseph M. Newcomer: "Re: Strange timer problem"
- Next in thread: Joseph M. Newcomer: "Re: Strange timer problem"
- Reply: Joseph M. Newcomer: "Re: Strange timer problem"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 9 Jun 2004 05:06:02 -0700
As always, I value your opinion very much and I have read
every one of your essays, even "Time is the simplest
thing". That's one of the reasons I wrote that I am fully
aware of windows not being an RTOS. I know this from
experience as well.
However, I feel that you have misinterpreted me.
I may very well be confused, but not in the aspect
regarding the topics you claim. ;-)
If I would have meant the CPU I would have written "CPU"
instead of "hardware" and by "hardware" I meant almost
everything but the CPU, timer circuits in particular.
I'm not looking for precise functionality with 100%
reliability. It would be like teaching my dog to speak
even though his anatomi makes it impossible, he is not
designed for speaking.
If I set the timer to be signaled after 1 ms, it would be
quite alright if it gets signaled after 3, or even 5, ms.
If I understood you correctly this can be accomplished
with MM-timers. Since windows is not an RTOS I would
expect the timer to get signaled with a "random" delay
depending on the OS scheduler and its time slices of 10
ms. But the thing is if I request the timer to be signaled
after 1 ms repeatedly, it gets signaled after approximatly
10ms every time, give or take 0.5 ms. I'm under the
impression that the timer is very precise in this aspect,
more so than I expected.
I have no idea what triggers waitable timers and/or MM-
timers, but something differs. It could be that the MM-
timers are triggered with the timer chip and waitable
timers are not, but I don't know.
How the different timers are triggered is probably the
answer I am looking for.
-- Rog >-----Original Message----- >For all practical purposes, unless you are using multimedia timers, 1ms is about the same >as 20ms. Doing anything where the delta-T has to be less than a couple hundred ms is risky >(except for the MM timers, which seem to be quite accurate) > >9-to-10ms sounds like it is within the acceptable limits of error. Basically, you can't >trust any time value to less than the basic timer tick (except for the MM timers). It >would not surprise me to see variations of many tens of milliseconds on a system with a >real load. The P4 could be a multiprocessor; I have not investigated to see if Windows >uses the 15ms timing on a hyperthreaded uniprocessor, but if you don't have a P4 with >multiple processors, then it would appear that a hyperthreaded processor looks like a >true multiprocessor, at least insofar as the OS is concerned. But I see nothing here that >I find even slightly disconcerting. "Hardware capability" has nothing whatsoever to do >with processor speed; it has to do with what the operating system does with the timer >information from the timer chip, which runs independent of the processor speed, always. > >Note that if you use MM timers, you get better resolution, although my tests at 1ms >indicate that mostly I get 1ms and sometimes I get 2ms (but not too often). So if you >think you will ever get 100% reliability at the error-no- more-than-1ms level, you are >dreaming. The only difference between a 90MHz machine and a 4GHz machine is that you >execute your code a whole lot faster on the faster machine, meaning you can do more per >notification. But expecting those notifications to be precise is unjustified. In fact, in >the last several decades, I have never worked on any general-purpose operating system >(including the fancifully-titled "real-time Mach" [it wasn't]) in which the OS had other >than a very loose grasp of the concept of time.OTOH, I have been told that Windows CE and >Embedded Linux are actually quite reliable in terms of realtime, but I have used neither. > >So Windows is behaving exactly as it is designed to behave. What's wrong with the picture >is that you are expecting to do something it was never designed to do, or behave in a way >that it was never intended to support. Or expecting that processor speed is relevant to >the design of the OS use of its basic timer, which it is not, never has been, and is >unlikely it ever will be. > >You have confused "better" with "clock speed" (they aren't always the same; a P3 >outperforms a P4 at the same clock speed, and of course support chip sets with different >L2 cache sizes, strategies, and performances (full- speed/half-speed L2 cache, for example) >can have a bigger impact on performance than raw clock speed), and you have also confused >processor clock speed with operating system timer maintenance. In fact, the OS runs at >either 10ms or 15ms on ANY speed processor. 4GHz, 300MHz, even a poor old 90MHz machine >running NT 3.5, all had a 10ms or 15ms clock (I don't recall when multiprocessor systems >became available, but I have one that is at least a decade old, it is a 100MHz quad >processor HP file server, and it runs with the same 15ms clock that my 2GHz dual-processor >system runs, because that is how Windows is designed and specified to run). > >The BIOS is completely irrelevant nearly all the time. It is used to boot the system, to >power down the motherboard, and to display the bluescreen, and otherwise, as far as most >of us know, it has no function in Windows. In fact, the BIOS-as-BIOS is dead; there is a >new ROM-based software standard (whose acronym I forget) which has nothing at all to do >with the traditional BIOS; it supports real operating systems, such as Unix, Linux, and >Windows, and nothing else. > joe > >On Tue, 8 Jun 2004 05:42:38 -0700, "Roger Stoltz" <rog.stoltz@home.se> wrote: > >>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 > >Joseph M. Newcomer [MVP] >email: newcomer@flounder.com >Web: http://www.flounder.com >MVP Tips: http://www.flounder.com/mvp_tips.htm >. >
- Next message: sanjeev bhatia: "Visual studio hangs while debugging"
- Previous message: Ips: "Re: PCH (MFC DLL)"
- In reply to: Joseph M. Newcomer: "Re: Strange timer problem"
- Next in thread: Joseph M. Newcomer: "Re: Strange timer problem"
- Reply: Joseph M. Newcomer: "Re: Strange timer problem"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
