Optimistic `MIN_SLEEP_DURATION` causes a problem

[byeonggiljun]

MIN_SLEEP_DURATION causes a flaky error in DecentralizedP2PUnbalancedTimeoutPhysical.lf (see this CI test result).

In the below logs, you can see that the federate doesn't wait until the physical time of 1 msec because the waiting time is less than MIN_SLEEP_DURATION (10 usec). However, this leads to advancing the current tag to 1 msec before the physical time exceeds 1 msec (994.0 usec). However, a message came through the physical connection, was scheduled at 996.6 usec, and invoked a fatal error.

DEBUG: -------- Waiting until physical time 1000000.
DEBUG: Wait time 6608 is less than MIN_SLEEP_DURATION 10000. Skipping wait.
DEBUG: Waiting is not interrupted. Current physical time is 993743.
DEBUG: Advanced (elapsed) tag to (1000000, 0) at physical time 993983.
Fed 1 (d): FATAL ERROR: DEBUG: get_next_event_tag(): Earliest event on the event queue ((996593, 0)) is earlier than the current tag ((1000000, 0)).

@edwardalee Do you think we can fix this by simply decreasing the amount of MIN_SLEEP_DURATION? Then, what should be the new value?

[erlingrj]

I think we should remove MIN_SLEEP_DURATION, it was a misguided optimization.

[erlingrj]

Actually, it is also used in update_ports_from_staa_offsets in federate.c, I am not sure about the exact function it serves there. But the usage in wait_until is not needed

[byeonggiljun]

I agree. But I found the PR #403 related to MIN_SLEEP_DURATION. This PR will fix the issue because it adds a busy wait when the wait duration is less than MIN_SLEEP_DURATION. So, why don't we merge that PR?

[edwardalee]

Wow, great detective work! The goal of MIN_SLEEP_DURATION and #403 was to reduce lag. I'm wondering if this bug could also be the cause for the watchdog failures.

[erlingrj]

I'm wondering if this bug could also be the cause for the watchdog failures.

Perhaps. We could try enabling the CI for watchdogs after merging these fixes!