[Feature Request]: Introduce a metric of some kind to indicate when a mesh may be reaching a threshold for moving to a faster preset

[NomDeTom]

A node could gauge the airtime that itself and adjacent nodes are using, or the channel utilisation, or generally the time they spend throttling messages to work out whether there is high airtime contention generally. With this figure, and some kind of link-strength metric, it would be possible to see if a faster preset would be possible, desirable or useful.

[Ryu945]

Mesh networks can be huge and there could be one part of the network where you can swap to something faster but another part where you cannot. This sounds like it may be more impractical then it is worth the time working on because there would never be any consensus on the best Lora setting. Thus, you often have the slower and longer range setting as everyone's default (Long Fast).

It seems like optimizing the bandwidth might be a better use of time though there is a mode I think would be useful for this concept because it doesn't require the network to change.

Some Meshtastic devices can store messages and send them later. I know ESP32 can. I could see someone setting their device up to store messages when on one channel setting for some period of time. Then changing to a different Lora configuration and broadcasting all the messages under that. Then storing messages for awhile on that Lora setup. It would constantly swap back and forth.

Practically though, you might be better off just buying two devices and wire them together (Or one device that can operate both at once. This devices does exist). Then set them up to relay messages between each other. It will probably take some new software developed. I have thought about this idea with the Chirp chips that work both on Lora frequencies and Wifi frequencies. Wifi has the bandwidth but terrible range. Lora frequencies has the range but terrible bandwidth. I have suspected Wifi frequencies set to max range will offer a better trade off then Lora frequencies set to short range and higher bandwidth.

If I remember correctly, a desert environment with wifi frequencies set to Long Slow (though I think there is a better way to optimize Wifi since the channels are wider) has the same range as somewhere between a Lora frequencies set to Medium Slow and Medium Fast. If your on a network that is trying to use Short Fast or Short Slow, would wifi frequencies be better anyway?

[korbinianbauer]

Mesh networks can be huge and there could one part of the network where you can swap to something faster but another part where you cannot. This sounds like it may be more impractical then it is worth the time working on because there would never be any consensus on the best Lora setting. Thus, you often have the slower and longer range setting as everyone's default (Long Fast).

Yes, but in practice some regions DID switch to faster preset and are happy with the result.

The nodes suggesting it would be advantageous to make the move should make the collective effort more likely to succeed.

[NomDeTom]

Some of the functionality for this is contained in #8455

[github-actions]

This issue has not had any comment or update in the last month. If it is still relevant, please post update comments. If no comments are made, this issue will be closed automagically in 7 days.

[NomDeTom]

• Average number of retries

• Average number of acks to a flood packet..

[jake-b]

Some crazy ideas I posted to discord, that Tom suggested I post here:

Maybe we need to add features that give people “permission” to experiment with other presets
Ideas to that end:

• a “Juniper Mist” style dashboard that shows current capacity, channel utilization, active nodes, packet types —- with concrete recommendations “looks like this mesh would benefit from a switch to short turbo”. Or “reduce telemetry intervals due to high telemetry packet load”

• maybe even dedicated firmware (or even hardware like based on concentrator) that acts as diagnostic tool for people to find low interference, high performance settings for their mesh

• features that let mesh admins broadcast new settings to the mesh “we’re switching to short turbo in Jan 31st.” Apps could present this as an option: Would you like to join the new mesh at this time? (Possibly need something like an opt-in mesh control PKI to avoid abuse, for example when I join the nyme.sh I could add their net control public key to my node config that would watch for such messages and let me always allow or require opt in when the mesh control broadcasts changes presets)