On Mon, 17 Nov 2025 01:10:12 GMT, David Holmes <[email protected]> wrote:
>> I feel that all these checks are just a source of this test instability. :) >> I'm not sure I fully understand why those are needed and what was the >> original design. It is always possible to have some delays in waiting time, >> so the original assumptions about expected accuracy are not fully correct as >> they are a little bit overly strong. >> From this point of view, I do not see why the comments are confusing. The >> `EXPECTED_ACCURACY` values are just based on the high frequency clock >> updates interval but should not be equal to it. >> Would you like me to change the comments to something like below ? : >> `high frequency clock updates expected` >> => >> `expected accuracy is based on high frequency clock updates` >> I do not want to change the Windows part until any failure is observed but >> can update the comment for consistency. > > 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28206#discussion_r2532529663
