3 ms·

Function you are looking for Windows is possibly not QueryPerformanceCounter(). It's unreliable when you consider various hardware, especially in multithreaded

by przemoc 12y ago

Function you are looking for Windows is possibly not QueryPerformanceCounter(). It's unreliable when you consider various hardware, especially in multithreaded applications on multi-core/CPU systems. Even more if you use Windows under VM. QPC can use RDTSC(P), but it's only one of its options, and even if RDTSC(P) is used it doesn't mean anything reassuring actually. Go with timeGetTime(), remembering about calling timeBeginPeriod(1) early (usually at the beginning of application) to set minimum resolution for periodic timers to 1 ms (well, it will happen only if HW provides that much resolution), and calling timeEndPeriod(1) after you stopped working with time (usually at the end of application). Milliseconds don't give you high-resolution, but at least working in this resolution is reliable. Having us or ns garbage is hardly any better...

daemin 12y ago
In recent years QueryPerformanceCounter is actually quite reliable since it's guaranteed not to change frequency during runtime. timeGetTime() and company though operate at the highest frequency that application has specified, and as such can be quite a drain on portable power systems (laptop etc). So when one application calls timeBeginPeriod(1) it means the laptop needs to wake up more frequently and hence is less power efficient.
- przemoc 12y ago
  What does it mean "in recent years"? Did QPC become better (and Sleep()/WaitForSingleObject() saner, as we're touching time-related stuff) in XP before EOLing? Assuming having Vista+, does it really work reliably even when called from a thread bound to only one core on various (not necessarily latest) hardware? Have you played with it under VMs? QPC was buggy and is still buggy for many users out there. After 15 years Microsoft is likely getting closer to sane behavior and maybe in latest Windows 8 (8.1) and Sever 2012 (2012 R2) it really works reliably in different setups and loads (haven't tested it yet). OTOH "getting better" by sole die out of setups, where it was working incorrectly, is not really getting any better. Viewpoint is important here. If you build your own infrastructure, you choose your HW/SW stack, can thoroughly test QPC behavior, then if it seems you go with same setup for your servers or what not [1]. But if you write software for all Windows users out there, then you don't have that much luxury. QPC is simply not good enough. You can always try with building some logic that falls back from QPC to lower resolution functions whenever odd behavior is detected, but unless you have HW/SW instances that you could test it on, then there is (high?) possibility you won't do it right, so maybe you shouldn't do it in the first place? 1 ms resolution at best should be enough in most cases. Increasing timer interrupt frequency from default 64 Hz (15.6 ms resolution) to 1000 Hz (1 ms resolution) indeed affects system behavior and can harm battery life, but it may be necessary evil. If we're talking about high-resolution time, then 1 ms resolution is simply that kind of thing for Windows (as ridiculous it may sound) if we take reliability into account. E.g. games, your multimedia applications and so on are already using timeBeginPeriod(1). Good news is that reportedly since Windows 8 the harm on battery is much less. [1] But if you really have control over HW/SW stack for your servers, then you'll quite likely happily avoid using Windows...

by przemoc 12y ago

daemin 12y ago

In recent years QueryPerformanceCounter is actually quite reliable since it's guaranteed not to change frequency during runtime. timeGetTime() and company though operate at the highest frequency that application has specified, and as such can be quite a drain on portable power systems (laptop etc). So when one application calls timeBeginPeriod(1) it means the laptop needs to wake up more frequently and hence is less power efficient.

przemoc 12y ago
What does it mean "in recent years"? Did QPC become better (and Sleep()/WaitForSingleObject() saner, as we're touching time-related stuff) in XP before EOLing? Assuming having Vista+, does it really work reliably even when called from a thread bound to only one core on various (not necessarily latest) hardware? Have you played with it under VMs? QPC was buggy and is still buggy for many users out there. After 15 years Microsoft is likely getting closer to sane behavior and maybe in latest Windows 8 (8.1) and Sever 2012 (2012 R2) it really works reliably in different setups and loads (haven't tested it yet). OTOH "getting better" by sole die out of setups, where it was working incorrectly, is not really getting any better. Viewpoint is important here. If you build your own infrastructure, you choose your HW/SW stack, can thoroughly test QPC behavior, then if it seems you go with same setup for your servers or what not [1]. But if you write software for all Windows users out there, then you don't have that much luxury. QPC is simply not good enough. You can always try with building some logic that falls back from QPC to lower resolution functions whenever odd behavior is detected, but unless you have HW/SW instances that you could test it on, then there is (high?) possibility you won't do it right, so maybe you shouldn't do it in the first place? 1 ms resolution at best should be enough in most cases. Increasing timer interrupt frequency from default 64 Hz (15.6 ms resolution) to 1000 Hz (1 ms resolution) indeed affects system behavior and can harm battery life, but it may be necessary evil. If we're talking about high-resolution time, then 1 ms resolution is simply that kind of thing for Windows (as ridiculous it may sound) if we take reliability into account. E.g. games, your multimedia applications and so on are already using timeBeginPeriod(1). Good news is that reportedly since Windows 8 the harm on battery is much less. [1] But if you really have control over HW/SW stack for your servers, then you'll quite likely happily avoid using Windows...