通过

Introduction to Control Theory and Its Application to Computing Systems -- Part 1

  • 项目

Part 1 of the slide presentation.

Sigmetrics Tutorial On Control Engineering -- Part 1 - Introduction.pptx

Comments

  • Anonymous
    December 28, 2008
    Until microsoft supports accurate time (via the HPET or some other device) the mere mention of control theory and windows in the same breath tests credibility. The lack of accurate time is such a severe deficiency that it really precludes using windows as a platform for a product in many cases even when a client asks for it. It forces one to use Linux. Please. Please! Provide sub-microsecond accurate time support on XP,Server 2008,server 2003

  • Anonymous
    December 29, 2008
    Joe, Ah, clocks and timers!!! Great question. A very interesting topic. Accurate clocks are so important for measurement and other applications like control engineering. Unfortunately, the timing facilities in Windows are not as well-documented as they should be. I assume you are not interested in issuing an rdtsc instruction and are familiar with the inconsistencies associated with that hardware timing facility. In Windows 2000, XP and Server 2003, the QueryPerformanceCounter() API issues an rdtsc instruction to provide precision timing information. *** I should note that the hardware vendors are rapidly addressing the inconsistencies associated with rdtsc in the past. On most current processor hardware, all the clocks on a socket are synchronized and they maintain a constant tick rate, even across power management events that change the clock rate of the processor. *** In response to the very visible issues with rdtsc, QueryPerformanceCounter() was changed in Vista and Windows Server 2008 to use the HPET instead, when it is available. Was that what you were asking about? BTW, if you are writing managed code, the Stopwatch() class is a thin wrapper around QueryPerformanceCounter(). This fix in Windows version 6 is hardly a panacea, however. The latency associated with calling the HPET is approximately 1 microsecond, which strikes many of us as an excessively long time. (For one thing, the long latency renders the number of bits of timer precision that are available pretty irrelevant.) We expect that the new version of Windows 7 will make some further improvements in the QPC() routine. As soon as we are permitted to discuss these improvements here in public, we will. What with the hardware improvements and the new support in the next version of Windows, we are pretty upbeat that there is a solution in hand for Windows developers. I am told there is even progress coming in the virtualization arena, which currently relies on software emulation of the hardware timing facilities, which leads to extremely imprecise clocks and timing. In Hyper-V, for instance, this plays havoc with any and all measurements that rely on precise intervals timers. This is very frustrating at the moment! In the meantime, keep in mind that the precision of the clock is not the entire story. And that precision clocks and timers is more of a hardware issue than a software one. (The Linux OS faces the same set of issues on Intel-compatible hardware.) -- Mark

  • Anonymous
    April 08, 2010
    The comment has been removed

  • Anonymous
    April 08, 2010
    Windows 7 determines at start-up whether the machine's TSC is invariant across power state changes. If it is, then subsequent calls to QueryPerformanceCounter() are handled using an rdtsc instruction. If the TSC tick rate is not constant, however, QueryPerformanceCounter()  will make requests to the HPET instead, just like in Windows 6. Basically, QueryPerformanceCounter()  does the right thing for you automatically in Windows 7. It uses rdtsc where it can be relied upon, and falls back to the HPET when it can't. Does that answer your question? Assuming a quick and reliable rdtsc instruction is available, do you you still want to be able to call the HPET from your program? -- Mark

  • Anonymous
    June 08, 2010
    Does it check whether it's consistent across cores?  I've got an i5 machine, and I'm getting solid results running a test with QPC when using CPU 0+1 (core 1) and when using CPU 2+3 (core 2), but inconsistent results with any other combination (including 0+2, 1+2, 0+3, and 0+1+2+3).  Running the same test on XP on the same machine with /USEPMTIMER works perfectly on 0+1+2+3.  But I can't find an equivalent to /USEPMTIMER for Win7.

  • Anonymous
    June 20, 2010
    We are experiencing the same problem as Miral. We relied on /USEPMTIMER to keep timing synchronised across CPUs in XP. This does not appear to work in Win7, and is stopping us from upgrading all our systems to win7. Look forward to hearing feedback, many thanks.

  • Anonymous
    June 22, 2010
    Miral and Ken: Intel Core i5 multi-core machines use TSCs that tick at a constant rate across power management events & should should remain in sync. Our experience is that you should not be seeing syncronization problems like this using TSC across cores. Please reply with your specific machine specifications so the Windows team can compare you to the machines we test against in our labs. And please describe how are you trying to test for synchronization problems? The USEPMTIMER boot.ini switch is no longer necessary in WS 2008, and that support was dropped. If you want to write me with more details, e-mail me directly at Microsoft. My alias is markfr. Thanks. -- Mark Friedman

  • Anonymous
    July 14, 2010
    Just to close the loop on this conversation about QPC() on Win7: Ken did ultimately follow up, and we were able to determine that QPC() was working correctly on his server hardware as advertised. It was, in fact, providing accurate timing information across cores. Drilling into the underlying problem, there was a timing anomaly impacting his application response times. We found it to be related to conventional resource contention, something we were able to start drilling into once we had established that the QPC() timings were, in fact, credible.

  • Anonymous
    July 14, 2010
    Just to close the loop on this conversation about QPC() on Win7: Ken did ultimately follow up, and we were able to determine that QPC() was working correctly on his server hardware as advertised. It was, in fact, providing accurate timing information across cores. Drilling into the underlying problem, there was a timing anomaly impacting his application response times. We found it to be related to conventional resource contention, something we were able to start drilling into once we had established that the QPC() timings were, in fact, credible.

  • Anonymous
    July 14, 2010
    Just to close the loop on this conversation about QPC() on Win7: Ken did ultimately follow up, and we were able to determine that QPC() was working correctly on his server hardware as advertised. It was, in fact, providing accurate timing information across cores. Drilling into the underlying problem, there was a timing anomaly impacting his application response times. We found it to be related to conventional resource contention, something we were able to start drilling into once we had established that the QPC() timings were, in fact, credible.

  • Anonymous
    July 14, 2010
    The comment has been removed

  • Anonymous
    July 18, 2010
    Echo! :) Just for reference, after further testing we've determined that QPC worked fine in our case too; our problem seems to be some kind of difference in behaviour for interrupt processing between XP and 7 (causing delays under 7 that weren't present in XP).  The exact cause hasn't been isolated yet.