This is a tradeoff one has to make, precision vs. accuracy. That's very depending on the hardware. While on one system using the performance timer it would work as expected, on another it's still more accurate time with a very variable precision. That's where you could see in your snippet currentTimeMs() - $startTimeMs < 0. That is much more weird than possibly having a worse resolution, say currentTimeMs() - $startTimeMs == 0.

Heres' an interesting reading about this http://blogs.msdn.com/b/oldnewthing/archive/2005/09/02/459952.aspx . The goal of the latest fix is to remove the random results. Also this will work in most cases as normally a script doesn't consist on just two subsequent microtime calls. Starting with win8 there is a much better API, but it of course doesn't help here. I'm not sure it should be touched, will look how to improve it without getting to the old erroneous behaviour. Maybe reimplement the performance timer part and make an ini option to let user decide if the performance timer should be used. As we really cannot foresee every hardware bugs.

Btw. usleep() isn't affected by that, it uses the waitable timer which has a better resolution.

We should use performance counters instead, which brings a much higher precision 
at less cost.

@ab@php.net: You are right: While usleep() only works in 1/64 second increments on my machine (640 loops of "usleep(1)" take about 10 seconds), this is not related to PHP 5.4.14. It's the same on 5.4.13 and probably a limitation of Windows' multitasking.

The same problem occurs in PHP 5.4.15 too!
Why developers ignore such an important issue?

The same problem occurs in PHP 5.5.1 too! Please fix this bug.

5.4.09 - OK, 5.4.10 - OK ... 5.4.14 - BUG, 5.4.15 - BUG
Why?

Just a note.
Linux does not have problem at all, it seems.

http://3v4l.org/nMBha

I guess this commit is the cause.

git show  b022e54bd100a914417e216
commit b022e54bd100a914417e216d0872d3e67edecaf9
Author: Anatol Belski <ab@php.net>
Date:   Sat Mar 23 17:40:06 2013 +0100

    Fixed possible precision loss in microtime
    
    This is related to the fix for bug #64370. MSVC natively supports __int64 
type,
    so calculating with 32 bit ints is neither necessary nor reliable. Therefore
    an older piece of code is reused.

diff --git a/win32/time.c b/win32/time.c
index 77e4504..7553974 100644
--- a/win32/time.c
+++ b/win32/time.c
@@ -50,6 +50,7 @@ int getfilesystemtime(struct timeval *tv)
        FILETIME ft;
        unsigned __int64 ff = 0;
        MyGetSystemTimeAsFileTime timefunc;
+       ULARGE_INTEGER fft;
 
        timefunc = get_time_func();
        if (timefunc) {
@@ -58,14 +59,20 @@ int getfilesystemtime(struct timeval *tv)
                GetSystemTimeAsFileTime(&ft);
        }
 
-       ff |= ft.dwHighDateTime;
-       ff <<= 32;
-       ff |= ft.dwLowDateTime;
-       ff /= 10; /* convert to microseconds */
+        /*
+        * Do not cast a pointer to a FILETIME structure to either a 
+        * ULARGE_INTEGER* or __int64* value because it can cause alignment 
faults on 64-bit Windows.
+        * via  http://technet.microsoft.com/en-
us/library/ms724284(v=vs.85).aspx
+        */
+       fft.HighPart = ft.dwHighDateTime;
+       fft.LowPart = ft.dwLowDateTime;
+       ff = fft.QuadPart;
+
+       ff /= 10Ui64; /* convert to microseconds */
        ff -= 11644473600000000Ui64; /* convert to unix epoch */
 
-       tv->tv_sec = (long)(ff / 1000000UL);
-       tv->tv_usec = (long)(ff % 1000000UL);
+       tv->tv_sec = (long)(ff / 1000000Ui64);
+       tv->tv_usec = (long)(ff % 1000000Ui64);
 
        return 0;
 }

Anyone could verify that this wouldn't happen with Windows 8/Windows Server 2012?
It seems different API is used for these platforms.

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!

@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.

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.

This is a non-issue as of Windows 8 and Server 2012, and won't be
fixed for older Windows versions.