STINNER Victor added the comment:
but 0.0156001 isn't close enough to 0.015625 for rounding errors to be at
all a plausible explanation for why it's so strange.
0.0156001 is close to 0.0156, and this number cannot be representated exactly
in binary:
(0.0156).hex()
'0x1.ff2e48e8a71dep-7'
STINNER Victor added the comment:
GetSystemTimeAdjustment is not the function to look at.
This sentence comes from
http://stackoverflow.com/questions/7685762/windows-7-timing-functions-how-to-use-getsystemtimeadjustment-correctly
which describes the wall clock (GetSystemTimeAsFileTime), not
Zachary Ware added the comment:
That's weird. I ran the same test on the same computer with an installed
64-bit 3.3.2, and got the same results (70+% failure). I just ran the same
test on a different computer (32-bit Windows 7), and also got the same results
with both 3.4.0b1+ and 3.3.2
Tim Peters added the comment:
Hmm. One obvious difference on my box:
Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:03:43) [MSC v.1600 32 bit
(Intel)] on win32
time.get_clock_info('monotonic')
namespace(adjustable=False, implementation='GetTickCount64()', monotonic=True,
STINNER Victor added the comment:
For more info on time, you can refer to the PEP 418.
I may be interesting to add sleep to time.get_clock_info(). time.sleep()
uses WaitForSingleObject() on windows. It may use internally a different
clock with a different resolution than time.monoyonic
Tim Peters added the comment:
@haypo, I've read the PEP and it has great ideas. What I'm wondering is
whether they've been implemented correctly in the relevant cases on Windows
here. That Zach see a resolution of 0.0156001 on Windows isn't plausibly a
question of rounding errors: that
Tim Peters added the comment:
FYI, this person seems to have made a career ;-) of making sense of the Windows
time functions:
http://stackoverflow.com/questions/7685762/windows-7-timing-functions-how-to-use-getsystemtimeadjustment-correctly
and their site:
Zachary Ware added the comment:
I think the minimum bound for dt could stand to be relaxed very slightly,
here's some results from my 64-bit Win7 box running 32-bit Python:
3.4.0b1 (default:eae6966d9734+, Dec 21 2013, 15:47:14) [MSC v.1600 32 bit
(Intel)]
sys.getwindowsversion(major=6,
Tim Peters added the comment:
@Zach, it would be nice to know more about this. I tried your little program
on a desktop box, 32-bit Windows Vista, Python 3.3.2, but I boosted the loop
count to 10,000. So it ran well over an hour, with a wide variety of other
loads (from 0 to 4 (of 4) cores
New submission from Christian Heimes:
I have seen this failure multiple times.
http://buildbot.python.org/all/builders/x86%20OpenIndiana%203.x/builds/7353/steps/test/logs/stdio
==
FAIL: test_monotonic
Roundup Robot added the comment:
New changeset 4864c0b914ae by Victor Stinner in branch '3.3':
Close #1: tolerate coarse time when testing time.monotonic() on very
http://hg.python.org/cpython/rev/4864c0b914ae
New changeset a34582c53911 by Victor Stinner in branch 'default':
(Merge 3.3)
STINNER Victor added the comment:
Hum, there is something wrong with this buildbot!
http://buildbot.python.org/all/builders/x86%20OpenIndiana%203.3/builds/1266/steps/test/logs/stdio
==
FAIL: test_monotonic
12 matches
Mail list logo
