On Sat, Feb 17, 2007 at 12:12:36PM -0800, Brooks Moses wrote:
Steve Kargl wrote:
It's simply a timing problem. secnds.exe is trying to make a timing
measurement and the tolerance is IMHO too strict.
Theoretically, though, the patch he's referring to (which I put in)
should have fixed that problem, by eliminating tolerances -- it calls
SECNDS, calls DATEANDTIME, and calls SECNDS again, and checks that the
DATEANDTIME value is between the two SECNDS values. So it shouldn't be
doing that any more.
I'm not convinced. :)
However, after submitting the patch, I did discover with my
"instrumented" version of the testcase that it will very occasionally
still fail; the intermediate DATEANDTIME result was 40ms ahead of the
first SECNDS result, but the SECNDS result was only 20ms ahead. Since
it's never happened again for me, I haven't looked closer to see if
there's a "real" reason for it, but my guess is that it's a rounding issue.
You can make 3 system calls in less than 20 ms, and we're
rounding to ms resolution.
Maybe I should put a loop into the testcase to run it two or three times
and only abort if all of the passes fail.
Yep. The old-time spin loop.