On Wed Oct 11 21:11:31 2023 +0000, Michael Stefaniuc wrote:
I think the DMUS_E_ALREADY_SENT failures should not happen anymore
after d0c3a0e03d557498195a70693003deae5b3e4588 (or rather much less frequently as it's always timing dependent). Right, forgot about that and just looked at the top of MR where I saw those failures.\ So those can be dropped then.
Regarding the timing test I'm not completely sure making it flaky is
the best option. Maybe we should just get rid of the test entirely if there's too much variation. You're not sure and I'm deferring the decision to you.\ So going with flaky is the simplest workaround for now to stop that noise. And then later on we can remove the whole test if it isn't that useful.
Do we know why we are getting these timing failures?
Getting 150 ms instead of 125 ms I can understand: just a scheduling delay because the system is busy. But how can we get 31 ms, less than the expected 50 ms minimum?
What is the reasoning behind the 50 and 100 ms thresholds?