-
Notifications
You must be signed in to change notification settings - Fork 716
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Increase the HZ to make test more reliable #1680
Conversation
Signed-off-by: Madelyn Olson <[email protected]>
Signed-off-by: Madelyn Olson <[email protected]>
Signed-off-by: Madelyn Olson <[email protected]>
Signed-off-by: Madelyn Olson <[email protected]>
Signed-off-by: Madelyn Olson <[email protected]>
Signed-off-by: Madelyn Olson <[email protected]>
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## unstable #1680 +/- ##
============================================
- Coverage 71.05% 71.03% -0.03%
============================================
Files 121 121
Lines 65243 65254 +11
============================================
- Hits 46357 46350 -7
- Misses 18886 18904 +18 |
Still flaky. I got this failure right now:
https://github.com/valkey-io/valkey/actions/runs/13201529468/job/36854504972?pr=1685#step:5:6269 |
Must be missing something else than, because that is way higher than should be possible. EDIT: I'm totally missing something, I misunderstood how the clients cron work. The value should be less than 200. |
What's the formula for the clients cron? Let's add a code about it in this test case when you've figured it out. |
After introducing, #1387, we saw a significant increase in other spurious wakeups because of the client cron that was added, which affected the "instantaneous eventloops per second" metric (showing it higher than before". All I did was increase the server hz to get more samples and increase the target value. This seems to work more consistently now. I also removed retries since the instantaneous value isn't dependent on number of retries.
Additionally,
assert_lessthan $value [expr $retries*22000]
makes no sense to me. The value is usually around 30-100us, since all it's doing is waking up and running a little bit of cron. The retries doesn't make much sense, since the retries don't impact the instantaneous value. I just removed the retries and left the 22k value for now, maybe valgrind is slow.