Algorithm to Automatically Adjust Repeater Parameters to Optimize the Mesh using a local density measurement

[KPrivitt]

Attached are two document that examines the various repeater parameters (rxdelay, txdelay, direct.txdelay, CR) and proposes a density metric to automatically adjust them to optimize a repeater for its current environment. By automating this, the entire mesh would improve (collisions would be reduced) and repeater owners that leave their repeaters at the non-optimum default values would have them automatically adjusted to an improved value.

Comments for improvements and corrections would be greatly appreciated.

https://discord.com/channels/1343693475589263471/1482520833476919427/1482520833476919427

https://discord.com/channels/1343693475589263471/1482520833476919427/1483211551463833772

[stachuman]

Well, why link to discord, not sure about others - but I can't read it.

[Magalex2x14]

Let me attach documents published by the author.

Proposal- MeshCore factors in selecting rxdelay txdelay and direct.txdelay.pdf
Probability of Collision with N Repeaters S Slots.pdf
White Paper 1 - Using rxdelay, txdelay and direct.txdelay to Minimize Collisions in a MeshCore Routing.pdf
White Paper 2 - How Acks and DMs work together.pdf
White Paper 3 - MeshCore Repeater AGC Behavior and Density Based Tuning.pdf
White Paper 4 - Duplicate Suppression and Random Transmit Backoff.pdf
White Paper 5- Why Flood DM Paths Jump.pdf
White Paper 6 - Why are Error Rates so High.pdf
White Paper 7 - Coding Rate (CR) Architecture.pdf

[stachuman]

I can only comment - super interesting papers

[stachuman]

Have created PR - Autotune delays based on White Paper 1
Not sure how contributors will assess it :) - but let's see
I'm running tests on my nodes

[stachuman]

I see that official contributors (I'm not official contributor - this is my first PR) are not convinced that delay autotune is something required to add to the code. I had a very short discussion at discord and conclusion is so far - "show results of tests", so can't say if PR is going to be accepted. On top, I'm not sure, I have the right environment. @KPrivitt do you have convincing test results?

The more popular solution becomes, the less users take care to configure it properly. That for sure I can see in my area :(

[stachuman]

Dears,

I took the simulator written by Matthew repo - made a fork to add missing features, which were not Matthew focus - like:

• CAD, half-duplex (detection rx...)
• ACK, PATH missing, public channel missing
• Radio settings impacting transmission time, duty cycle implementation
• Realistic adverts (was 0 time)
• New visualization client (with some more features) - kind of work in progress

Couple of more things, hard to count all - aiming to simulate as close as possible.
The overall Matthew idea was - use reald node code and attach it to simulated radio.

Now my ask - I need 2nd pair of eyes - help with:

1. Creating realistic topology test map (not just generic, simulated grid or unrealistic SnR values)
2. Review what I might be missing within simulated radio
3. 2nd pair of eyes on tests

My biggest struggles are:

1. With my test topologies I'm struggling to make reliable simulations, prepare stable network (whatever it means)
2. I have very high level of collisions (maybe that's true?), also - I can observe that messages can be within network even for 40-50sec - would need to have a check from someone from outside
3. Simulating rx/tx delays seems to not to work due to wrong test topologies (e.g. - all repeaters get the same settings due to network topology... but maybe that's correct?
   ...

You may contact me directly under mail: cgpsmapper at gmail.com or through the fork I prepared (I'm using - as Matthew - claude too) - meshcore_sim

[Magalex2x14]

Hello! Regarding realistic topology, I remembered www.meshcoresim.com, which runs simulations based on real neighbor data. Maybe this will help? Maybe you can cooperate with the author of this tool and load some real area for your simulation?

[stachuman]

So...

1. I've build simulator -> simv2
2. Based on my other project - I've tried to simulate real topology -> Meshcore optimizer - capturing real data
3. I've run couple of simulations -> Delays tests

I need someone else to check my approach.

Just to sum-up briefly results:
20 minutes simulation, 12 companions, every 200s (randomized) communication (1-1, 1-many, public...)
Parameter sweep: 63 combinations x 3 seeds = 189 runs

delivered - direct messages delivery rate
chan - public messages delivery rate

BUT - I'm more and more cautious for the numbers - as I'm still not convinced that I've put into test the right scenario.
The other question is - what is the success ratio :) - I do assume - we speak of what has been delivered

Radio: SF8, CR4, BW65200
=====================================================================================
  Completed 189 runs (63 combos x 3 seeds) in 3m45s
=====================================================================================
  Top 10 combinations (of 63):
=====================================================================================
   rxdelay   txdelay  d.txdelay    mean    std   min   max  delivered   acks   chan
  --------  --------  ---------  ------  -----  ----  ----  ---------  -----  -----
      0.00      0.00       1.50   19.3%   1.7%   17%   21%   197/1020    10%    46%
      1.00      0.00       1.50   19.3%   1.7%   17%   21%   197/1020    10%    46%
      0.00      0.00       1.00   19.3%   1.9%   18%   22%   198/1020    10%    45%
      1.00      0.00       1.00   19.3%   1.9%   18%   22%   198/1020    10%    45%
      0.50      0.00       0.50   19.0%   0.8%   18%   20%   194/1020     9%    45%
      0.00      0.00       3.00   19.0%   1.6%   17%   21%   194/1020     9%    47%
      1.00      0.00       3.00   19.0%   1.6%   17%   21%   194/1020     9%    47%
      0.00      0.00       0.00   18.7%   1.2%   17%   20%   192/1020     9%    43%
      1.00      0.00       0.00   18.7%   1.2%   17%   20%   192/1020     9%    43%
      0.50      0.00       0.00   18.3%   0.9%   17%   19%   187/1020    10%    44%

Radio: SF8, CR4, BW125000
=====================================================================================
  Completed 189 runs (63 combos x 3 seeds) in 3m50s
=====================================================================================
  Top 10 combinations (of 63):
=====================================================================================
   rxdelay   txdelay  d.txdelay    mean    std   min   max  delivered   acks   chan
  --------  --------  ---------  ------  -----  ----  ----  ---------  -----  -----
      0.50      0.00       0.50   26.3%   3.4%   23%   31%   267/1020    14%    58%
      0.00      0.30       0.50   24.0%   1.6%   22%   26%   246/1020    15%    59%
      1.00      0.30       0.50   24.0%   1.6%   22%   26%   246/1020    15%    59%
      0.00      0.00       0.50   24.0%   2.2%   22%   27%   245/1020    14%    61%
      1.00      0.00       0.50   24.0%   2.2%   22%   27%   245/1020    14%    61%
      0.00      0.30       0.00   23.7%   2.1%   21%   26%   241/1020    16%    61%
      1.00      0.30       0.00   23.7%   2.1%   21%   26%   241/1020    16%    61%
      0.50      0.00       1.00   23.3%   0.9%   22%   24%   235/1020    12%    59%
      0.50      0.00       1.50   23.3%   1.7%   21%   25%   238/1020    13%    58%
      0.00      0.00       2.50   23.3%   3.3%   19%   27%   235/1020    15%    58%

[stachuman]

Last couple of days spent on improving my simulator and test topology data.
Long story short - I see improvement.

1. Test topology - to not to go into details (I'll post full report on my meshcore_simv2 github page) - my topology repeaters distribution:

============================================================
  Neighbor count distribution (repeaters, SNR > 0.0)
============================================================
    0 neighbors:  0
    1 neighbors: ########################### 19
    2 neighbors: ################################## 24
    3 neighbors: ######################################## 28
    4 neighbors: ############################## 21
    5 neighbors: ################################## 24
    6 neighbors: ######################### 18
    7 neighbors: ######################## 17
    8 neighbors: #################### 14
    9 neighbors: ########### 8
   10 neighbors: ## 2
   11 neighbors: ##### 4
  12+ neighbors: ######## 6

============================================================
  Summary
============================================================
  Repeaters:       185
  Companions:      4
  Links:           463
  SNR threshold:   0.0
  Avg neighbors:   4.9
  Median:          5
  Min:             1 (19 nodes)
  Max:             12
  Isolated (0):    0

2. Test messages

============================================================
  Message schedules
============================================================
  Private messages: 50 schedule(s), 50 messages total
    With ack:      50
    Without ack:   0
    Senders:       4 (alice, bob, carol, dave)
    Receivers:     4 (alice, bob, carol, dave)
    Unique pairs:  7

    From            To               Count   Ack       Span
    --------------- --------------- ------ ----- ----------
    alice           bob                 10   yes      149s
    alice           carol                5   yes      389s
    alice           dave                10   yes      352s
    bob             carol                5   yes      109s
    bob             dave                 5   yes      264s
    carol           dave                10   yes      256s
    dave            alice                5   yes      175s

  Channel broadcasts: 16 messages total
    Channels:      [0]
    Senders:       4 (alice, bob, carol, dave)

    From             Channel  Count       Span
    --------------- -------- ------ ----------
    alice                  0      4      168s
    bob                    0      4      188s
    carol                  0      4      283s
    dave                   0      4      141s

3. Test methodology

• matrix of tx/rx/direct delay * 6 different random seeds

4. Results
   tx_b - base value, tx_s - slope,
   mean, std, min, max - statistical measurements for different seeds
   delivered - no of delivered messages (acks - for ACK, chan for public channel)

Base results - default firmware:
Delivered: 38%
Public: 46%
Acks: 6%

=========================================================================================================
  Completed 2304 runs (384 variants x 6 seeds) in 350m16s
=========================================================================================================
  Top 10 variants (of 384):
=========================================================================================================
    tx_b   tx_s   dtx_b  dtx_s    rx_b   rx_s    mean    std   min   max  delivered   acks   chan
  ------ ------  ------ ------  ------ ------  ------  -----  ----  ----  ---------  -----  -----
   0.000 0.3000   0.000 0.3000   0.500 0.3000   51.0%   3.3%   48%   56%   153/300      4%    51%
   0.000 0.3000   0.500 0.6000   0.500 0.3000   50.3%   3.4%   46%   56%   151/300      6%    54%
   0.000 0.3000   1.500 0.3000   0.500 0.3000   50.0%   5.1%   44%   56%   150/300      5%    47%
   0.000 0.3000   1.000 0.3000   1.000 0.3000   49.0%   3.3%   44%   54%   147/300      7%    50%
   0.000 0.3000   0.500 0.6000   1.000 0.3000   48.7%   3.5%   42%   52%   146/300      6%    47%
   0.000 0.3000   0.500 0.6000   0.500 0.6000   48.7%   3.7%   42%   52%   146/300      8%    54%
   0.000 0.3000   1.000 0.3000   0.500 0.3000   48.7%   4.1%   44%   56%   146/300      5%    48%
   0.000 0.3000   0.000 0.6000   0.500 0.3000   48.7%   4.5%   44%   56%   146/300      5%    46%
   0.000 0.3000   1.500 0.6000   0.500 0.3000   48.7%   4.5%   42%   56%   146/300      5%    50%
   0.000 0.3000   1.500 0.6000   0.000 0.3000   48.7%   6.2%   42%   58%   146/300      9%    49%

That gives proposed delays lookup table per number of neighbors:

  Generated table:
    [ 0] tx=0.050  dtx=0.050  rx=0.500
    [ 1] tx=0.300  dtx=0.300  rx=0.800
    [ 2] tx=0.600  dtx=0.600  rx=1.100
    [ 3] tx=0.900  dtx=0.900  rx=1.400
    [ 4] tx=1.200  dtx=1.200  rx=1.700
    [ 5] tx=1.500  dtx=1.500  rx=2.000
    [ 6] tx=1.800  dtx=1.800  rx=2.300
    [ 7] tx=2.100  dtx=2.100  rx=2.600
    [ 8] tx=2.400  dtx=2.400  rx=2.900
    [ 9] tx=2.700  dtx=2.700  rx=3.200
    [10] tx=3.000  dtx=3.000  rx=3.500
    [11] tx=3.300  dtx=3.300  rx=3.800
    [12] tx=3.600  dtx=3.600  rx=4.100

I'm looking for ppl willing to test their topology, provide test scenarios.

[KPrivitt]

Impressive work.
One question. In the Results table it shows the top 10 variants out of 384. What makes these the top 10? (the best success rate at that particular setting? It would be nice to have a column with the neighbor count so you could see the local density of neighbors for that entry)

I'm presuming that you ran the suite of txdelay, direct.txdelay and rxrelay against the various 185 repeaters and other nodes. The acks and channel percentage are the percent that were successfully received. (does the simulation give you a reason for non-delivery, like collision, which I believe is the primary cause).

The "generated table" was the result of the simulation, suggesting that this might be a suitable one to be used in the algorithm. (My example table in the paper was "close" but tended to have lower values, my intellectual best guess).

Can you run a simulation with everyone set to the defaults? This is the true "baseline", since it seems most repeater/node owners are not aware of the ability to set these. Since the algorithm would be automatic, this is the improvement we should expect to see across the mesh.

Regarding topologies, I would run a Sparce, Medium, Dense and Regional, but with a range of SNR. For example run Sparce with 4 neighbors, one with a strong (12dBm) SNR, two with an OK (4-5 dBm) and one with a weak (1 dBm) which is likely a typical configuration.
So, for each 25% strong 50% Okay and 25% weak.

My roof repeaters topology is: 12 total neighbors, 4 with a SNR greater than zero (three strong one Okay), which is just inside a Medium, I recently updated the firmware so no descent stats, it's only been up for 2 days.

Here is a friends repeater stats, one that has a lot of traffic.
Downey SanGabrielRiver in the Middle of Los Angeles in the West Coast Mesh, data since the 1.14.1 update: Uptime 29 days 21 hr., Total Packets RX 493,989, Total Packets TX 96,476, Received Packer Errors 304,728. Which is a 38% error rate (Err / (RX+ERR), just a little lower than your simulation, but close enough. 22 Neighbors, 9 with a SNR greater than zero.

In summary, this appears to be proof that the algorithm does indeed improve the mesh and simply using the defaults is hurting the mesh.

[1nerdherder]

If this auto optimization method is going to be delayed, then it is worth creating a pull request to change the current defaults.

[stachuman]

Thx for feedback. Indeed, we have to run it against different scenarios - and I'm going to do so. I'll post all raw input and output on my github - so it can get independent reviews.

Success rate is - at the moment - only direct message delivery. We may try to tune weighted.. added now collision/drop ratio. It's kind of tricky as single message can have A LOT collisions/drops and still be delivered, but could be interesting to measure.

All will be there: meshcore_simv2

[stachuman]

Maybe it makes sense to do full simulation + feedback round / proposal.
Now I'm running 3 simulations for sparse / medium / dense setup - tomorrow should be able to upload results.

[KPrivitt]

I agree that even with a lot of collisions a message can still be delivered. (that's what a redundant mesh is for).

I believe the simulator is running every "transmission", so it can (hopefully) count the total number of collisions across the entire simulated mesh for every message sent. This is the data I think we need to see.

It's not just the percentage of getting a message through (though that is the purpose of the mesh and a good metric). But, it how the mesh as a whole is colliding and how the delay variables influences that. This is what motivated me to think about this in the first place (why do my DMs fail so often, or never go through)

The delay features are there to reduce collisions, and knowing the overall number that occur in the mesh with the default setting and comparing this with a mesh with optimized settings is the "smoking gun" pointing to the need for the mesh to be setup "properly" (and automatically optimize itself).

I am very curious what the percent reduction turns out to be. This will tell us if optimization works (makes the mesh better), but also the effectiveness of this collision avoidance strategy.

I'd be curious to know what each one actually does (I'm not asking for more simulation, just musing). My belief is the txdelay is the most important and most influential factor. The others may not be as effective, but they are there so why not use them and get whatever incremental improvement they provide.

BTW, I really liked the fact that your simulations generated the "lookup table", this was the missing piece that needed to be understood and determined.

[stachuman]

It uses real firmware, so it fires every single event. It can be analyzed in the output file (and visualization).
Through visualization it's easy to see how the whole network could be busy with a single flood message, later it gets little better organized but... direction to autoadjust is something I believe, we should have in mind

If anything is missing, we can add.

What I'm really interested now is - will a different topology gives different results?

[fokcuk]

Following. Can you summarise to a formula for manually running to get recommend values for a specific repeater?
Also, would the core radio parameters like frequency etc impact the simulation results?

[stachuman]

Yes. You can adjust any parameter you want. It is as simple as sending command to the repeater (as explained - I'm using normal repeater firmware)
...
{ "at_ms": 5001, "node": "test_repeater", "command": "set txdelay 0" },
..

That will send in defined time command to 'test_repeater'

I did add some simplifications, e.g. created '@repeaters' which send specific command to all repeaters.

I did NOT tested different radio settings - only European ones (Nederland and Poland) - I can do test for different settings - no problems - what specific?

[stachuman]

Maybe a word - how simulator works - it reads json input parameters and creates output file with all the events. These events can be then visualized - using visualizer.py or can be interpreted in any different way.

This is (self explanatory - I believe) input file from one of test samples.
There is overlay which translate 'msg bob' to real address.

{
  "_name": "t29_txdelay_spread",
  "_desc": "Equal-SNR diamond with txdelay=2.0: both relays receive at same SNR (-5dB), but random backoff [0, 4431ms] spreads their retransmissions apart. rxdelay=0 (cannot help since SNRs are equal). Random spread avoids collision → message delivered.",
  "simulation": {
    "duration_ms": 25000,
    "step_ms": 5,
    "warmup_ms": 5000,
    "hot_start": true,
    "radio": { "sf": 8, "bw": 62500, "cr": 4 }
  },
  "nodes": [
    { "name": "alice", "role": "companion" },
    { "name": "hub", "role": "repeater" },
    { "name": "relay_a", "role": "repeater" },
    { "name": "relay_b", "role": "repeater" },
    { "name": "dest", "role": "repeater" },
    { "name": "bob", "role": "companion" }
  ],
  "topology": {
    "links": [
      { "from": "alice", "to": "hub", "snr": 10.0, "rssi": -70.0, "bidir": true },
      { "from": "hub", "to": "relay_a", "snr": -5.0, "rssi": -107.0, "bidir": true },
      { "from": "hub", "to": "relay_b", "snr": -5.0, "rssi": -107.0, "bidir": true },
      { "from": "relay_a", "to": "dest", "snr": 10.0, "rssi": -70.0, "bidir": true },
      { "from": "relay_b", "to": "dest", "snr": 10.0, "rssi": -70.0, "bidir": true },
      { "from": "dest", "to": "bob", "snr": 10.0, "rssi": -70.0, "bidir": true }
    ]
  },
  "commands": [
    { "at_ms": 5001, "node": "hub", "command": "set txdelay 0" },
    { "at_ms": 5001, "node": "hub", "command": "set rxdelay 0" },
    { "at_ms": 5001, "node": "relay_a", "command": "set txdelay 2.0" },
    { "at_ms": 5001, "node": "relay_a", "command": "set rxdelay 0" },
    { "at_ms": 5001, "node": "relay_b", "command": "set txdelay 2.0" },
    { "at_ms": 5001, "node": "relay_b", "command": "set rxdelay 0" },
    { "at_ms": 5001, "node": "dest", "command": "set txdelay 0" },
    { "at_ms": 5001, "node": "dest", "command": "set rxdelay 0" },

    { "at_ms": 8000, "node": "alice", "command": "msg bob txdelay-spread test" }
  ]
}

[fokcuk]

Claude does not think it would matter all that much
However it questioned your simulation results in regards to EU duty cycle settings etc
There was also an post about rxdelays with values between 0 and 1, with the suggestion of setting it to 1, which would have zero delay
#2064

With values set to 0, I do not know if it goes to defaults or not used at all

[stachuman]

Dears,

After very intense last days - I have a preliminary discovery report: Delay autotune - along with all the sources, steps, files, scripts.
I'm not hiding that I used claude in this work - I'd never be able to do the work so quickly otherwise (of course with heavy supervision).

I'm surprised by the final verdict.
And I really mean it.

I don't want to force you to go to this (pretty long) document to find the answer I did not expect. But before that - let me express that once again - it is simulation only - even if I spent significant time to make it as real as I can (and my rusty knowledge from University time allows me) - I may do some obvious mistakes I simply don't see.

OK, and now answer...
best results I got are with three zeros -
rxdelay=0
txdelay=0
direct txdelay=0

Meaning - that the actual default already in MeshCore are not optimal.

[fokcuk]

Rx and tx delays of 0 means they are not in use?
I have not looked at the core functions to see how it handles packets. I think we all want to avoid duplication by not sending to the ones with the low snr?

[stachuman]

No, no.
They are ALWAYS in use. They define the way transmission is fit into slots.

0 means - no delay (t is 0)

Flood retransmit (txdelay):
t = airtime * txdelay # e.g. 500ms * 0.5 = 250ms
delay = random(0, 5*t + 1) # random(0, 1251) → 0..1250 ms
schedule_retransmit(delay)

Direct forward (direct.txdelay):
t = airtime * direct_txdelay # e.g. 500ms * 0.3 = 150ms
delay = random(0, 5*t + 1) # random(0, 751) → 0..750 ms
schedule_retransmit(delay)

rxdelay (on reception, before processing):
if rx_delay_base <= 0: delay = 0
else: delay = (rx_delay_base^(0.85 - score) - 1) * airtime

With txdelay=0:
t = airtime * 0 = 0
delay = random(0, 1) = 0 # always zero

 Repeater override (simple_repeater/MyMesh.cpp:526-533) — uses the prefs:
  uint32_t MyMesh::getRetransmitDelay(const Packet *packet) {
    uint32_t t = (_radio->getEstAirtimeFor(...) * _prefs.tx_delay_factor);
    return getRNG()->nextInt(0, 5*t + 1);
  }
  uint32_t MyMesh::getDirectRetransmitDelay(const Packet *packet) {
    uint32_t t = (_radio->getEstAirtimeFor(...) * _prefs.direct_tx_delay_factor);
    return getRNG()->nextInt(0, 5*t + 1);
  }

[fokcuk]

Thank you for these. Had no chance to review the code

[KPrivitt]

Very interesting and unexpected results. A couple of comments from real life:

1. Simulations are models (you acknowledge this) and are only an approximation of reality (they are not reality). They don't always give valid results. One example, at Intel we used SPICE to model the transmission lines (the traces) connecting high speed components, the simulations determined the min/max trace length (that was guard banded) and was published in the design guidelines. I received a call from Compaq (now HP) that they were getting errors (that were real), it turned out that there was a "hole" in the solution space, by using a Monte Carlo analysis (effectively adding noise) the hole was revealed. That is when I learned to always treat model results with a grain of salt. They are a tool to guide us but not the answer.

2. AI is not always correct and hallucinates. I am not an AI expert, but early on in my career (40 years ago so those synapses are a little fuzzy) I was first introduced to Neural Networks (at Intel) and learned how they worked (tap weights) and what they could be used for. My belief (I cannot prove this) is that AI is based on these same principles. An AI takes in its training set and delivers a result based upon the inputs (your questions) and gives a result. The key here is if you ask something it was not trained on, it will give a bogus ("made up") response, it will always give an answer. The answer is a result of all the tap weights. (this is similar to 1 above in that there is a missing part).

I actually asked AI how MeshCore routing worked, I was curious how it determined the path from an ACK when the ACK doesn't include the path. So, I investigated and I wrote a White Paper two days ago on this. During the session I had to correct the AI by stating my observed behavior. It corrected itself about a dozen times, I finished the paper but I had a nagging inconsistency. After a little more research, I asked a few pointed question and it turned out the entire paper was wrong. The AI had used Meshtastic, but even some of the Meshtastic routing was wrong, it was using general routing mechanisms and crunched them all together. I believe I now understand MeshCore routing and it is what I started with and I now understand how the path is determined (from all the Flood ACKs received back across the Mesh, and some/many? get dropped due to collisions). So, I no longer trust AI, but it is a great tool to fix coding errors.

3. Are we seeing a 0/0 result, remember n/0 (n != 0) is infinite. 0/0 is any/every number. The metric you used is delivery success, which gets smaller in dense environments (and collisions are going up), should be metric be just total number of collisions? i.e. do the delay parameters reduce collisions (which I believe they do). So, if the settings do reduce collisions, what are the optimum values?

4. Are we seeing a boundary condition effect at 0/0/0? Remember 0 is a special number and does cause unexpected results (1/0 and 0/0)

5. The reason I started think about this was:
   Why are my DMs failing when I send them at midnight when there is virtually no activity on the Mesh (airtime is essentially 0). Why do they sometimes arrive, but I get a "Failed" result. This happened mostly when sending to a destination in a dense environment, but not locally (this is very sparse). This led me to ACKs and that lead me to collisions.

6. Yes, my paper calculated the probability of a one-one collision, I knew this was a simplification, but I later posted "Probability of Collision with N Repeaters S Slots" which analyzes multiple nodes, and I was surprised to see that the effect of increasing nodes quickly overrode the exponential drop of a one-one (becomes linear) with increased backoff. So, collision probability rises with density but are linearly countered by linearly increasing density.

I am perfectly happy to accept this result, but I don't have a good understanding of the underlying mechanism that is improving delivery in the presence of increasing collision. Increasing density does increase the overall number of collisions, dense environments are the worst situation, and collisions do cause messages to fail.

My intuition says to look at the overall number of collisions, not delivery. Are we seeing a situation the one packet is avoiding them and successfully delivered? (1 is very close to 0 ;-)

But I want to Thank You! again, some very impressive work.

If collisions are reduced in the real world, then message delivery will improve (my intellectual belief, and I think it reflects reality).

Let the discussion begin...

[stachuman]

First of all - we might be of similar age and experience :D - I recall neural network at University time as simple couple layers calculations. And I know very well SPICE or pspice...

But that's not about that.

It is always fair to question methodology and I'm questioning my methodology as well. It's super easy to fall in into a trap of not understanding, that simplification is too big, that assumptions are wrong, or that AI hallucinated in a very convincing way (one time it was persuading me strong into wrong... or maybe not one time).

Maybe I simplified too much that I used AI - I did - but in a way of 'stupid/quick junior developer' - but who knows, maybe he planted smart bugs I was not able to discover?

Anyway -

Ad 1. I do fully agree. Simulations are tempting, simplifying and might be totally wrong. For reference - in my other project: https://github.com/stachuman/meshcore-optimizer - I'm collecting real measurements from routers. I though that it will give real measurement. Probably it would - but I can get with that approach no more than 10% of real data. It can give 'feel' - which I used adjusting test topology - but it will NOT give the reality.

Ad 2. I believe, we have pretty similar view into that

Ad 3. It is difficult question - what we aim to minimize. In flooded routing - the more routers - the more collisions occur. Do we try to limit number of them? Here I'd advice to check visualizations I did prepare - it provides quite a good (or maybe I'm just a kind of person who needs to see a picture) view why there are collisions. If we would focus on minimizing them... Hmm, interesting --> that could be another scenario to simulate <---

Ad 4. Agree, and have no answer nor idea. It is boundary - switching off some kind of optimize mechanism

Ad 5. It was essentially same reason for me - I have two locations I did want to send some metrics in the middle of the night. Why it was not delivered? What happen?

Now - I can say - I have a little better idea what happens in the mesh network, but definitely I don't know answer - what's happening.
Maybe the simulated radio is still too simple? Or maybe there are factors we simply ignore? (Hey, what about interference of Meshtastic network? It works in my area on the very same frequency)

I'll do the collision focused simulation, I'll re-do review of simulated radio parameters - step by step - to see if maybe I forgot something? Again - to refer to manufacturer datasheet (it's super revealing compared to work I have to do as my official one :) )

Let's continue this work, as it's inspiring.

Thanks for the feedback!

[KPrivitt]

I agree with everything you said. I, and as I suspect you, am just trying to understand what's going on. It was quite surprising that 0/0/0 was the best successful delivery, and I fully accept the result. What I now need to do is figure out is what this means and understand why it comes out this way. I am not a routing expert, but I have come across this during my Ethernet work at Intel and my InfiniBand Specification work (I was a contributor and "co-writer" of Volume 2, with an engineer from IBM, we traded the Frame File that became the final spec).

I also agree with the other comment from 1nerdherder, can we get someone (an architectural expert) within the dev group to weigh in.

My gut tells me that reducing collisions (the reason the backoff is there in the first place, true of Ethernet and "true" for MeshCore?) and removing those collisions will allow those messages transversing the mesh to continue on and arrive at the destination (if they get there it is contributing to the success rate). A collision kills two packets by definition. Having messages reach the destination is a good thing.

[1nerdherder]

I think we are at a place where someone who is really intimate with the protocol needs to chime in. For me, it is not clear whether we should optimize for a minima of collisions or a maxima of what the model calls a successful delivery.
I have a question for the author of the simulation, "does a successful delivery also take into account the successful delivery of the ACK?" It seems that the ack is the item most critical to protect from collisions, no?
We would be grateful if any MeshCore developers involved with the current protocol evolution or thinking about the Meshcore roadmap to V2 could provide some directional guidance here.

[stachuman]

Success rate - for the sake of simulation - was defined as DM (direct message) successful delivery.
Public messages deliver and ACK were measured, but only DM were treated as success. It is important to note that ROUGHLY ack is half of DM delivery rate (it vary!) - what is not strange for two reasons:

1. Test messages are relatively short
2. First ACK is in fact PATH message - which spreads the same way (FLOOD) as initial message

[stachuman]

This is picture from my visualization tool - it show how single message propagate. Full box is TX, empty - RX.
With red crosses - we have collisions marked.
The reason - we have them - we have interference of TX from different sources - for example
Repeater_Assen_NL_so has interference for the message from Repeater_AssenWest - becauce after short delay WRDN_ASS_CTR_RPT2 started to TX.

Single message is creating a lot of collisions with itself - in attached picture - there are (nearly) no other messages competing for space.

[fokcuk]

Meshtastic interference was mentioned, but it's not the only thing that operates on this frequency. Local to me we have cell service on the 900mhz band, smart meters sending data on the same as well.
Then we have natural effects of nature
Forgive me from typing in bed and asking without checking available information- was double ack option enabled on the companions? Clocks in sync?