On Mon, 17 Nov 2025 03:11:25 GMT, Chris Plummer <[email protected]> wrote:
>> This is wrong. The "expected" accuracy is still 10ms or even 1ms, it is >> never 32ms. The test may need to wait longer but changing this value makes >> no sense. > > I think the real issue is that EXPECTED_ACCURACY is incorrectly named. It is > being used as a max amount of elapsed time, not as an "accuracy" value. The > comment on the WIN32 part just adds to the confusion. The "max elapsed time" > has to be 16 ms because that is the clock is only accurate to 16ms, so even > 1ms of elapsed times will show up as 16ms. The comment "16ms is longest clock > update interval" should read "shortest", not "longest". > > EXPECTED_TIMEOUT_ACCURACY_NS also seems to be misnamed. Thank you, Chris. My intention was to fix this intermittent failure and achieve better stability. My preference would be to get rid of these troublesome and useless checks instead of fixing confusing constant names and comments. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28206#discussion_r2535742944
