Messages sent from a local companion wait for the same random relay delay as packets being relayed #174

New Issue

2026-10-27T09:36:11+01:00

adam commented

2026-10-27 09:36:11 +01:00

While testing, I noticed that a message a local companion sends goes through the same scheduling as a packet this repeater is relaying: _calculate_tx_delay(pkt) picks a random delay, then schedule_retransmit(..., local_transmission=True) queues it behind other traffic and listen-before-talk.

As far as I understand, the random delay exists so that repeaters hearing the same flood packet don't all transmit at once. A packet that originates here has no other repeater competing to send the same copy, so I wonder whether it needs that delay at all, or whether a much shorter one would do.

I ran a small simulation using openHop's own schedule_retransmit and _calculate_tx_delay (with AirtimeManager for the airtime), against a modelled radio. The radio's listen-before-talk behaviour and the traffic levels are my assumptions, not measurements, so please read the numbers as shape and scale only. Settings: 869.618 MHz, 62.5 kHz, SF8, CR 4/8, 110-byte message, lbt_max_attempts 5, default delay factors.

Time from a companion sending a message until it goes out (simulated seconds):

Other traffic (share of air time)	Median	90th percentile	Random delay alone (median)	Delivered
5% (quiet)	3.8	5.9	2.4	25 of 25
25% (busy)	2.7	5.9	2.3	15 of 25
50% (very busy)	4.7	8.3	2.9	11 of 25

On a quiet radio, most of the wait is the random delay. On a busy one, messages are lost when listen-before-talk runs out of attempts, which is a separate matter, but the extra random delay adds to the time they spend queued.

Questions:

Is the random delay on locally originated packets intentional?
If so, would a separate, shorter delay (or a setting) for local_transmission=True be acceptable?
Is the failure after lbt_max_attempts reported anywhere the sender can see?

I can share the simulation script if it helps. Happy to be told I've misread how this works.

While testing, I noticed that a message a local companion sends goes through the same scheduling as a packet this repeater is relaying: `_calculate_tx_delay(pkt)` picks a random delay, then `schedule_retransmit(..., local_transmission=True)` queues it behind other traffic and listen-before-talk. As far as I understand, the random delay exists so that repeaters hearing the same flood packet don't all transmit at once. A packet that originates here has no other repeater competing to send the same copy, so I wonder whether it needs that delay at all, or whether a much shorter one would do. I ran a small simulation using openHop's own `schedule_retransmit` and `_calculate_tx_delay` (with `AirtimeManager` for the airtime), against a modelled radio. The radio's listen-before-talk behaviour and the traffic levels are my assumptions, not measurements, so please read the numbers as shape and scale only. Settings: 869.618 MHz, 62.5 kHz, SF8, CR 4/8, 110-byte message, `lbt_max_attempts` 5, default delay factors. Time from a companion sending a message until it goes out (simulated seconds): | Other traffic (share of air time) | Median | 90th percentile | Random delay alone (median) | Delivered | |---|---|---|---|---| | 5% (quiet) | 3.8 | 5.9 | 2.4 | 25 of 25 | | 25% (busy) | 2.7 | 5.9 | 2.3 | 15 of 25 | | 50% (very busy) | 4.7 | 8.3 | 2.9 | 11 of 25 | On a quiet radio, most of the wait is the random delay. On a busy one, messages are lost when listen-before-talk runs out of attempts, which is a separate matter, but the extra random delay adds to the time they spend queued. Questions: 1. Is the random delay on locally originated packets intentional? 2. If so, would a separate, shorter delay (or a setting) for `local_transmission=True` be acceptable? 3. Is the failure after `lbt_max_attempts` reported anywhere the sender can see? I can share the simulation script if it helps. Happy to be told I've misread how this works.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/pyMC_Repeater#174