fix: reduce max packet receive time during leader window

[cavemanloverboy]

Problem

In certain cases (if the transaction container is emptied during a leader's window), the scheduler controller may wait up to 100 milliseconds for incoming packets.

Summary of Changes

Reduce the constant max wait from 100 ms to 10 ms.

[apfitzge]

@bw-solana Could you review this simple change; I have tested very similar changes previouly.

As @cavemanloverboy mentioned, something that can happen is we schedule or drop all txs in our buffer and enter a 100ms receive while leader - this can be extremely slow.

Before we get a better type for deserialization I think this is a reasonable stop-gap solution.
Code change itself is straight-forward, but since I've made previous changes in past I think its' a bit sketch for me to approve this.

[bw-solana]

LGTM.

"Okay, it's bad we'll wait up to 100ms, but surely we'll hit the packet limit first in the practical case"

checks packet limit

🤡

[cavemanloverboy]

LGTM.

"Okay, it's bad we'll wait up to 100ms, but surely we'll hit the packet limit first in the practical case"

• checks packet limit *

🤡

so then I said its okay we just need to get 700,000 packets

[apfitzge]

i never added the damn ci flag. will watch this and merge

[Jac0xb]

What are the implications of this change?

[cavemanloverboy]

What are the implications of this change?

from OP: "In certain cases (if the transaction container is emptied during a leader's window), the scheduler controller may wait up to 100 milliseconds for incoming packets."

There is a (somewhat rare) case where the scheduler will collect packets for 100 ms before it even begins scheduling. That's 1/4 of the a slot... This will reduce this time to 10ms so that there is never a time where the scheduler is twiddling its thumbs waiting for packets.

[mergify]

Backports to the stable branch are to be avoided unless absolutely necessary for fixing bugs, security issues, and perf regressions. Changes intended for backport should be structured such that a minimum effective diff can be committed separately from any refactoring, plumbing, cleanup, etc that are not strictly necessary to achieve the goal. Any of the latter should go only into master and ride the normal stabilization schedule.