Autotune of delays based on number of neighbors

[stachuman]

Based on discussion: Algorithm to Automatically Adjust Repeater Parameters

Implements automatic tuning of txdelay, direct.txdelay, and rxdelay parameters based on active neighbor count, as described in White Paper 1 (Section 8.0). Delay factors are consolidated into the Mesh base class, eliminating duplicated override code across examples.

• Adds a lookup table (DelayTuning.h) indexed by active neighbor count (SNR > 0, heard within 7 (define value) days) with 13 entries ranging from sparse (0 neighbors) to regional (12+)

• Moves getRetransmitDelay, getDirectRetransmitDelay, and calcRxDelay from per-example overrides into the Mesh base class, driven by three configurable float members

• Repeater: counts active neighbors and recalculates on neighbor update, every 5 minutes (define value), and on CLI changes

• Room server / Sensor: use 0-neighbor baseline (no neighbor table available)

• Adds auto_tune_delays persisted preference (on by default for new installs), with CLI: get autotune, set autotune on/off

• Manually setting rxdelay, txdelay, or direct.txdelay via CLI auto-disables autotune

New variable (set/get):
autotune - with values on/off

The default - after upgrade - is autotune ON

This change is backward compatible.

[KPrivitt]

Are you planning to add a purge of stale neighbors? (remove all with a last heard greater than 10 days).

This is a necessary part of the algorithm to prevent neighbor count creep: when stale invalid neighbors are counted pushing up and possibly overflowing the index into the table. Left unchecked the values will continually increase an unchecked false count.

[KPrivitt]

One additional thing: my example table limited the txdelay to 2.0, which was the maximum value allowed by the CLI. This may not be a valid limitation, but I have no data to back this up, my leaning would be to increase this to 2.5 (possibly 3.0) to allow additional slots for a regional repeater. Additional slots is beneficial to regional repeaters since they have a set of non-conflicting values with the repeaters "below them", there is no possibility of a collision within this set. Eliminating a collision is always beneficial vs the increased airtime of the retransmission of failed message. But a larger vakue does add additional delay to the end to end transmission time (for that hop) it seems that the additional delay is not much to pay for a non-collision transmission (but that's my opinion, I have no information that points to the potential detrimental effect of a delayed transmission) In terms of the human timeframe it is not really noticeable.

For what it is worth, this seems reasonable.

[stachuman]

Are you planning to add a purge of stale neighbors? (remove all with a last heard greater than 10 days).

This is a necessary part of the algorithm to prevent neighbor count creep: when stale invalid neighbors are counted pushing up and possibly overflowing the index into the table. Left unchecked the values will continually increase an unchecked false count.

counting active neighbors take into account two factors -
SNR > 0 and LAST HEADR < NEIGHBOUR_ACTIVE_MAX_AGE

At the moment I've set it:
#define NEIGHBOUR_ACTIVE_MAX_AGE (7 * 24 * 3600) // 7 days

The way it works - every AUTOTUNE_INTERVAL_MILLIS (which now I set to 5 minutes - quite often, but this is fast function) I'm simply checking neighbors table and I'm counting number of neighbors according to above criteria.

[stachuman]

One additional thing: my example table limited the txdelay to 2.0, which was the maximum value allowed by the CLI. This may not be a valid limitation, but I have no data to back this up, my leaning would be to increase this to 2.5 (possibly 3.0) to allow additional slots for a regional repeater. Additional slots is beneficial to regional repeaters since they have a set of non-conflicting values with the repeaters "below them", there is no possibility of a collision within this set. Eliminating a collision is always beneficial vs the increased airtime of the retransmission of failed message. But a larger vakue does add additional delay to the end to end transmission time (for that hop) it seems that the additional delay is not much to pay for a non-collision transmission (but that's my opinion, I have no information that points to the potential detrimental effect of a delayed transmission) In terms of the human timeframe it is not really noticeable.

For what it is worth, this seems reasonable.

I have no data either. I went through the white paper (you are the author?), I've checked situation in my area (a lot of collision, I need to built better monitoring software to have more clear picture, at the moment I can only refer to my 3 companions and 3 nodes I have - which are located in different areas - rarely I'm able to make direct communication, most goes through flood).

The limit for delays - when setting in code - is of course non-existing.

[weebl2000]

Some people asked if they could test this, for those who wnat to, I've pushed this PR to my fork and people can try it with https://mcimages.weebl.me?commitId=stachuman

[stachuman]

Some people asked if they could test this, for those who wnat to, I've pushed this PR to my fork and people can try it with https://mcimages.weebl.me?commitId=stachuman

Thank you!

I realised that get command (e.g. get rxdelay) will NOT return auto-adjusted value - added fix get delays fix - so could be that some of the test builds won't return value - even if internally it is used.

[KPrivitt]

stachuman, Thank You! for implementing this. After I sent my comment, I realized that you had checked the last heard and didn't use it in the count, so your implementation works just fine.

But stale neighbors will build up in the database and should be purged (but that does happens every time a new version comes out, so it's not permanent).

I posted a request to #2123 for repeater owners to post their current Error Rate [# Errors/(Total RX + #Errors)], which I suspect is mostly due to collisions. This is some easily accessible data.