Bug #64633 [Opn->Wfx]: microtime regression - resolution reduced to 64 ticks per second

Edit report at https://bugs.php.net/bug.php?id=64633&edit=1 ID: 64633 Updated by: cmb@php.net Reported by: phpbugs at musiclogistics dot net Summary: microtime regression - resolution reduced to 64 ticks per second -Status: Open +Status: Wont fix Type: Bug Package: Date/time related Operating System: Windows 7 PHP Version: 5.4.14 -Assigned To: +Assigned To: cmb Block user comment: N Private report: N New Comment: This is a non-issue as of Windows 8 and Server 2012, and won't be fixed for older Windows versions. Previous Comments: ------------------------------------------------------------------------ [2014-04-27 22:04:40] ab@php.net For those interested in the usage of performance counters - please try this http://php.net/hrtime . Firstly, it is anyway interesting to see how it competes to the classic microtime() on your machine. Secondly - the performance counter API is exposed to the user space there, so it is even possible to implement some custom timing, too. Please remember though, that hrtime has nothing to do with timestamps synchronizable to an external source. Thanks. ------------------------------------------------------------------------ [2014-02-10 16:20:23] ab@php.net Related To: Bug #65626 ------------------------------------------------------------------------ [2014-01-10 08:24:17] ab@php.net @louis, that's exactly what i'm talking about - with the current variant one would never get time1 > time2, i bet with the old variant using performance counters it could easy happen in your situation. Running chrome seems to be a catalyser for some instability in your case. In the current implementation time1 = time2 is the worst case, earlier it could be casual time1 > time2, or not. Now it's never time1 > time2, but with the trade off. @yohgaki, i don't think the patch you've posted is responsible, but merely the exclusion of the performance counters. On win8 one can profit from the new API call GetSystemTimePreciseAsFileTime(), which is comparable to Linux. On earlier it's GetSystemTimeAsFileTime(). The latter has poorer accuracy, but is stable and will never deliver time1 > time2. That's the trade off, as i've said above. Earlier performance counters was used instead of GetSystemTimeAsFileTime(), which led to even more confusing bugs, as in the bug #64370 and related. Turning back the old code will turn back time1 > time2 on win8 ancestors, as it's hardware+API dependent and is more random than now. ------------------------------------------------------------------------ [2014-01-08 14:13:19] louis at stovesonline dot co dot uk Having the same issue with 5.5.7 on Windows Server 2008 R2. Interestingly starting Google Chrome on the server increases the tick rate for a few seconds, meaning I can briefly get accurate results from my timing functions! ------------------------------------------------------------------------ [2013-08-01 06:53:57] yohgaki@php.net Anyone could verify that this wouldn't happen with Windows 8/Windows Server 2012? It seems different API is used for these platforms. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=64633 -- Edit this bug report at https://bugs.php.net/bug.php?id=64633&edit=1