Hi Anatol, all,
Sorry for top post... Stas must be getting confused with all these details!
:-) Is Pierre going to weigh in? Are there any other Windows people?
While I don't think I'd disagree with much of what you've said, I don't see
that using my patch is *causing* or *creating* new issues that you're
referring to. Whatever is broken with Windows is still the *same* with
what's there now since last year.
All I wanted to do, that I think Windows users want, is make microtime() at
least resemble *micro* time (very well, resolution-wise) so that it *is*
suitable for performance measurements. It's useless for that now. And it
happens to fix the uniqid() problem to boot.
I don't think there were [m]any issues over 10+ years using microtime() for
that? It was that implementation's errors over time (which mine doesn't
have) that were revealed when compared to another value, like
REQUEST_TIME[_FLOAT].
Maybe I used the wrong subject wording or NEWS file update -- I'm not trying
to improve actual "accuracy" over what's available now -- just insure that
it stays accurate as it can be (within range) with respect to the current
time, unlike the old implementation.
So things are MUCH better for microtime() useable resolution and uniqid().
What are some actual usage scenarios that my implementation would make WORSE
than they are now? I don't see how... It seems you're against the idea, in
principle, of it working at all like the old way (in a good way)? :-/ The
patch doesn't make all these new problems like you are suggesting.
More below...
----- Original Message -----
From: "Anatol Belski"
Sent: Tuesday, September 09, 2014
Hi Matt,
[...]
coming to this right now. I'm just responding here as otherwise we'd have
three parallel threads to follow, not handy.
I've tested your new variant and it doesn't show $t1 < $t0 on the same VM.
However I still see an issue. The main issue that it tries to solve a
hardware bug with math, that can work or not.
I'm not trying to solve a hardware bug at all with math. The idea is only
to indicate the *certain* passage of time between calls while the returned
time, otherwise, remains the same (as one example).
Furthermore, looking closer
at the math in the patch, I don't think it's correct. Obviously we neither
should care about winxp at this times, nor about vista. Regarding win7,
there are still too many issues to have a stable synchronizable timing in
high resolution. You can agree or not, here are just the facts:
You are talking about "synchronizable," etc. but I'm not trying to do
anything like that. Just a time that usually moves forward (except window
of x amount of time it could stay the same if clock is advancing *very*
slowly (QPC too far ahead and "clamped" to max); still better than now).
- time-of-day clock accuracy depends on tick frequency (RTC interrupt)
and/or additionally on HPET
- QPC can be based on HPET, RDTSC, ACPI, etc.
- the interrupt frequency depends on HW used
And on timer resolution, right? AFAIK the default timer resolution (lowest)
is always equal to the time_update_rate (lpTimeIncrement). Again, not that
this matters much anyway, since currently results are same or worse than my
implementation. Mine doesn't make anything worse.
- QPC is not synchronizable to an external source, while time-of-day clock
is
See above again. :-) Only moving the micro time forward when it doesn't
otherwise change.
- QPC and partly time-of-day clock additionally depends whether it's a
real HW or a VM, number of processors, thread safety, function call
latency, etc.
- while retrieving QPC is cheap, time-of-day clock will lead to loosing
some microseconds
I was actually wondering about the QPC latency (but not an issue raised
before) on diff systems... I don't see why there'd be a delay getting
system time. Regardless, I can call microtime() on my system (older Q9400)
2 million times/sec. (inc. loop overhead), so not losing microseconds when
half the calls return the same value. :-)
- there are also some new HW which provides multimedia timing chips
For more I'd just mention the site you already was linking to (did read
that also a lot before), and especially to this doc
http://www.windowstimestamp.com/PartIIAdjustmentofSystemTime.pdf starting
at 4. As well as the MSDN pages for the corresponding functions.
The consequence of all this is that it's completely unpredictable to mix
QPC and time-of-day clock. There's no guarantee that time update interval
will match the interrupt interval. Back to the math in the patch,
lpTimeIncrement from GetSystemTimeAdjustment() will be constant, but
lpTimeAdjustment can change. You currently don't take it in account.
lpTimeAdjustment can be changed by a SetSystemTimeAdjustment() call, from
an arbitrary source like some program or NTP update. Time adjustment can
be disabled (and effectively that's not handled atm). That means from the
patch
I already said how I'm purposely not taking any SetSystemTimeAdjustment()
calls into account (besides the fact that it's probably never used).
Complicates things much more than is needed to simply estimate time passage
between actual system time updates. The clock changing +/- 1 sec/hour
(that's probably getting extreme as far as errors) is less than 5
microseconds per 1/64 second update interval. Doesn't matter when it's less
than any fluctuation anyway. Certainly not an issue compared to now!
ts = target - time_update_rate
doesn't bring you to the time at the previous update interval.
If the estimate is behind (either over time or because clock jumped
forward), that simply brings it to the minimum amount within range (so it
"jumps" as little as acceptable). The only way that could *not* be
at/within the previous update interval is if the clock was updating *slower*
than normal (TimeAdjustment < TimeIncrement) in which case the estimate
would be *ahead*, not behind.
Say when
lpTimeAdjustment == lpTimeIncrement, there were no gain at all (same as if
time adjustment were disabled).
There's always some gain -- can't stop the clock. :-) But if could, still
no worse than now!
That's why I meant
GetSystemTimeAdjustment() should be called as frequently as
gettimeofday(). From
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724394%28v=vs.85%29.aspx
I read the following:
=============
For each lpTimeIncrement period of time that actually passes,
lpTimeAdjustment will be added to the time of day. If the lpTimeAdjustment
value is smaller than lpTimeIncrement, the system time-of-day clock will
advance at a rate slower than normal. If the lpTimeAdjustment value is
larger than lpTimeIncrement, the time-of-day clock will advance at a rate
faster than normal. If lpTimeAdjustment equals lpTimeIncrement, the
time-of-day clock will advance at its normal speed.
=============
Yes, I know all that...
The conclusion - while QPC is constant (or actually should be), the
time-of-day clock might shift at an arbitrary rate. Taking in account,
that the update interval can most likely be not the same (for instance
RDTS vs PM clock), the result of the math is arbitrary. For more,
GetSystemTimeAsFileTime() and GetSystemTimeAdjustment() will surely take
several microseconds to complete, which add to the uncertainty. So even
when used, they should be feched right after QPC. At the end, we have
"some" value which passes into the range between the current QPC and the
time-of-day clock values, but it's obviously not the value one could call
even approximately correct. The uncertainty might be low enough to fit
into the max resolution (say 300us were the max resolution and 30ms the
uncertainty), however that's just a hope.
For an application which really matters about the microsecond resolution
it'll be not suitable. The timestamp will be just phony. That's what i
meant with the example of the ebay bid, apart from net latency of course.
But ebay uses the millisecond resolution anyway, like actually almost any
real world app nowadays, still. It's more like example when you have PHP
with this patch and try to communicate with another machine which is
synchronizing time say per NTP and as in that case exact timing would
matter, how much discrepancy will it have? After one month of running an
FCGI process? And so on.
Discrepancy? No more than now. After running for any amount of time? No
more than now.
It would be very hard to synchronize a Windows system's time anyway (I guess
on windowstimestamp.com it's trying to help with that, but who's using
that?), so the bidding resolution stuff is almost moot anyway -- problem is
same now, my patch doesn't hurt anything like I'm saying.
You can't do any synchronized communication now either anyway. How would
you? Even IF a clock was truely synchronized, there's no way in PHP (or
anything) to wait for/until a certain time to the millisecond...
But of course this is all theory stuff that applies now/regardless and
nothing to do with my patch implementation.
IMHO how it looks with pre win8 - the time-of-day API is not suitable for
performance measurements. I actually always presumed that it was your
goal. For this goal the hrtime stuff can be used where you even can
measure with pure QPC ticks when on a fast machine (say when you're out of
even ns range). As if we cannot provide a valid synchronizable timestamp
with QPC, the qualitative performance measurement is easy done using
relative time intervals.
Most would not be using something not commonly available... And regarding
relative time intervals, couldn't QPC counter roll over on some system (like
VM)? Or it handles that somehow? Or be out-of-sync between cores on some
hardware with XP?
May I suggest you to pack your work into a PECL extension, or maybe even
merge with hrtime. As there are several aspects anyway where we have an
issue, more or less. For example uniqid() you've mentioned. Or actually,
usleep() IMHO - much more of issue than microtime currently as the
resolution used there can be much worse. Anyway, it can come back to core
after it was good tested, is well thought and solid. That's what I would
suggest to do.
Yeah usleep() is way more coarse on Windows because of timer res., right?
Nothing can be done about that.
Best regards
Anatol
Thanks,
Matt
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
