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.