Skip to content

Be more patient: increase companion timeouts#10

Open
weebl2000 wants to merge 3 commits intodevfrom
be-more-patient
Open

Be more patient: increase companion timeouts#10
weebl2000 wants to merge 3 commits intodevfrom
be-more-patient

Conversation

@weebl2000
Copy link
Owner

Increase base timeout constants and scale flood timeouts by attempt number.

Problem

The flood timeout (500ms + 16× airtime) only covers ~3-4 hop round trips. Each forwarding node adds ~airtime + random(0-5)×airtime/2 delay, so a 10-20 hop destination needs 15-31 seconds round trip — but the timeout fires after ~6s, causing premature retries that add congestion and make subsequent attempts even less likely to succeed.

Changes

Increased base constants:

  • SEND_TIMEOUT_BASE_MILLIS: 500 → 1000
  • FLOOD_SEND_TIMEOUT_FACTOR: 16 → 32
  • DIRECT_SEND_PERHOP_FACTOR: 6 → 10
  • DIRECT_SEND_PERHOP_EXTRA_MILLIS: 250 → 500

Attempt-based scaling for flood timeouts: base_timeout × (attempt + 1)

For a typical 345ms airtime packet (29B, SF8, BW62.5kHz, CR4/8):

Attempt Timeout
0 (first send) 12.0s (~7 hop RT)
1 24.1s (~15 hop RT)
2 36.1s (~23 hop RT)
3 48.2s (~31 hop RT)

Only sendMessage and sendCommandData pass attempt — other send functions (login, anon req, contact request) default to attempt=0, no behavior change.


Build firmware: Build from this branch


Mirror of meshcore-dev#1691

liamcottle and others added 2 commits March 4, 2026 01:39
And use attempt to progressively wait longer. Currently we only wait 3-4
hops of airtime. When destination is 10-20 hops away we send 3 flood
messages before the first one will have a chance of arriving.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants