Message203968
Steve, I'm afraid sleeping 100ns wouldn't be enough. The more data I collect, the more bizarre this gets :-(
Across 300 runs I recorded the difference, in nanoseconds, between the "old" and "new" timestamps. A negative difference is a test failure. I was very surprised (for one thing) to see how few *distinct* values there were:
-600: 5
-500: 9
-200: 1
-100: 8
0: 13
100: 1
975800: 7
975900: 58
976000: 69
976100: 7
976300: 9
976400: 48
976500: 52
976600: 6
1952400: 1
1952500: 1
1952800: 1
1952900: 3
1953000: 1
---
300
So the vast bulk of the differences were close to a millisecond (1e6 nanoseconds), and a handful at the tail close to 2 milliseconds. Anyone know the precision of NTFS file creation time? I know the time structure is _capable_ of 100ns resolution, but the numbers above strongly suggest the precision is a lot closer to a millisecond.
Anyway, on the failure end, the biggest difference seen was 600 nanoseconds. A 100ns sleep wouldn't cover that ;-) |
|
Date |
User |
Action |
Args |
2013-11-23 06:16:04 | tim.peters | set | recipients:
+ tim.peters, loewis, pitrou, tim.golden, jkloth, brian.curtin, python-dev, steve.dower |
2013-11-23 06:16:04 | tim.peters | set | messageid: <1385187364.63.0.716892504929.issue19715@psf.upfronthosting.co.za> |
2013-11-23 06:16:04 | tim.peters | link | issue19715 messages |
2013-11-23 06:16:04 | tim.peters | create | |
|