test: fix time resolution constrain#3981
Closed
gireeshpunathil wants to merge 1 commit intonodejs:masterfrom
gireeshpunathil:fix-time-resolution
Closed
test: fix time resolution constrain#3981gireeshpunathil wants to merge 1 commit intonodejs:masterfrom gireeshpunathil:fix-time-resolution
gireeshpunathil wants to merge 1 commit intonodejs:masterfrom
gireeshpunathil:fix-time-resolution
Conversation
test/parallel/test-fs-utimes.js
Outdated
Member
There was a problem hiding this comment.
I suggest Math.floor(mtime - real_mtime) <= 1
Member
There was a problem hiding this comment.
Or just mtime - real_mtime < 2?
Member
Author
|
Thanks @JungMinu and @bnoordhuis . I will try both, and get back with observations, |
The modification time of a file is assumed to happen at the exact time when it was requested. As the utime API specification delcares that the resolution of the result is 1 second, relax the constrain to 1 second helps the test case to be robust and consistent under different load conditions in the system
Member
Author
|
Both are working, picked up @bnoordhuis' suggestion as it is more compact. Please review and do the needful. Thanks! |
Member
Contributor
|
I'm a little late, but LGTM, and appreciate the detailed write up. |
Member
|
LGTM |
Member
|
@JungMinu Did you land this? Commit e918224 doesn't seem to belong to any branch. Aside, there's a small typo in the commit log: s/constrain/constraint/ |
Member
|
@bnoordhuis sorry to bug you, I will handle it now |
JungMinu
pushed a commit
that referenced
this pull request
Dec 5, 2015
The modification time of a file is assumed to happen at the exact time when it was requested. As the utime API specification delcares that the resolution of the result is 1 second, relax the constrain to 1 second helps the test case to be robust and consistent under different load conditions in the system PR-URL: #3981 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Minwoo Jung <jmwsoft@gmail.com>
Member
|
Thanks, Landed in cf65299 |
rvagg
pushed a commit
that referenced
this pull request
Dec 8, 2015
The modification time of a file is assumed to happen at the exact time when it was requested. As the utime API specification delcares that the resolution of the result is 1 second, relax the constrain to 1 second helps the test case to be robust and consistent under different load conditions in the system PR-URL: #3981 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Minwoo Jung <jmwsoft@gmail.com>
This was referenced Dec 8, 2015
Closed
MylesBorins
pushed a commit
that referenced
this pull request
Dec 29, 2015
The modification time of a file is assumed to happen at the exact time when it was requested. As the utime API specification delcares that the resolution of the result is 1 second, relax the constrain to 1 second helps the test case to be robust and consistent under different load conditions in the system PR-URL: #3981 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Minwoo Jung <jmwsoft@gmail.com>
MylesBorins
pushed a commit
that referenced
this pull request
Jan 19, 2016
The modification time of a file is assumed to happen at the exact time when it was requested. As the utime API specification delcares that the resolution of the result is 1 second, relax the constrain to 1 second helps the test case to be robust and consistent under different load conditions in the system PR-URL: #3981 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Minwoo Jung <jmwsoft@gmail.com>
Merged
scovetta
pushed a commit
to scovetta/node
that referenced
this pull request
Apr 2, 2016
The modification time of a file is assumed to happen at the exact time when it was requested. As the utime API specification delcares that the resolution of the result is 1 second, relax the constrain to 1 second helps the test case to be robust and consistent under different load conditions in the system PR-URL: nodejs#3981 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Minwoo Jung <jmwsoft@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The test case in one of its tests, is trying to change the modification time of a file, and validate that the modification applied (through stat call) is indeed same as what was requested, at an accuracy level of seconds. The output indicates that this validation fails a few times when checked for 10000 times back-to-back.
utime manual says "The utime() system call allows specification of timestamps with a resolution of 1 second." My interpretation of this is that one should expect a deviation of at most one second for the actual modification time, from the requested time. This is reflected in the output of failed cases as well, as every pairs have exactly a difference of one.
However, the test case seems to assume that the actual and request time should match at the seconds level. Excepts from test case:
// check up to single-second precision
// sub-second precision is OS and fs dependant
return Math.floor(mtime) == Math.floor(real_mtime);
While this works for small workloads (less file system activities), when the stress on fs APIs increases (for example, if I increase the depth level of runTest callbacks) then the failure rate increases, and starts affecting Linux as well. The small test case above is in fact a stressed version of the original test case.
with the proposed change, the test passes consistently.