Hi,
For those who enjoy the technical discussions there is a good one based on research and a proposal for an algorithm for repeaters to self optimize themselves.
Aside from the fact that it may be implemented in upcoming firmware the numbers are interesting for those who would like to manually improve their repeaters for the benefit of the network.
A summary here
Full discussion is here including a link to a .zip file containing all the papers.
Ejony,
Serge
Ich schreibe auf Deutsch dass das Thema für die nicht English-sprechenden einfacher zu verfolgen ist.
Mir stellt sich zwangsläufig die Frage, ab welchem Moment die Rechenleistung unserer Repeater-Hardware zum Problem werden wird bei solchen Sachen. Gut - wenn das so einfach geregelt wird dass bei X-Anzahl Neighbors automatisch der und der Delay eingestellt wird, benötigt das sicherlich keine massive Rechenleistung. Aber beim RX-Delay stellt sich mir die Frage, ob das nun als „Effektiv“ getestet wurde? Meine letzte Info war, dass das noch Tests braucht um die Effektivität und den Nutzen zu validieren.
Bei unserem Mesh sind Noah und Ich, auf meine Nachforschung hin, nun dazu übergegangen, dass wir Kommunale/Nahbereichsrepeater wie Balkon-/Hausdachrepeater auf einem TX Delay von 0.5 lassen. Interkommunale/Regionale Repeater auf hohen und guten Stellen mit grossem Abdeckungsbereich auf 1.0 gestellt haben und, wenn es eines Tages soweit ist, Fernbereichrepeater welche z.B über Kantonsgrenzen hinweg auf Gipfeln arbeiten etc, würden wir diese auf 1.5-2.0 stellen.
Das alles wurde bei uns so eingesetzt, weil wir mehr und mehr Probleme hatten mit zuverlässigen ACKs und teilweise auch 3/4 oder mehr Sendeversuche benötigten. Durch die Topographie sind teilweise Repeater doch in relativ kurzer Nähe zueinander um Felsen/Hügel zu überwinden. Dadurch hatten wir grosse Probleme mit Packet Collisions welche wir dadurch angegangen sind. Unseres Empfinden nachs hat diese Veränderungen der TX Delays eine spürbare Wirkung gezeigt.
Direct TX Delays haben wir auf Standard belassen da diese ja einer fixen Route folgen. Solche Massnahmen konnten wir aber nur durchführen weil ein Grossteil des Meshs durch unsere Hardware läuft. Somit waren solche Massnahmen auch spürbar für das ganze Mesh und wir konnten merken dass das einen positiven Impact hatte.
Da bei grossen Mesh viele Player ihre Hardware haben, wäre ein automatisierter Weg sicher besser. Dann würde jeder Repeater selber die Einstellungen vornehmen. Denn die Koordination mit Einstellungen usw klappt ja nicht überall so gut wenn nicht jeder mitmachen will.
Hi,
Since many players in a large mesh network have their own hardware, an automated approach would certainly be better.
Yes and this is one of the drivers of this change. I think everyone is in agreement that these changes are an improvement, the exact values set and hence the algorithm is still being refined.
As you say, its already possible to set these values, I too have made the changes manually but coordinating across a larger distributed network is much more difficult.
The purpose of my post was raise some awareness about these settings so all repeater owners know of their existence and can potentially make changes on their own repeaters. Following the guidelines mentioned or using a slight variation like you do will in any case lead to an improvement and this has already been shown in several regions.
Maybe SETTINGS | MeshCore Switzerland could be further refined to give some guidance to current and future repeater owners.
There is already a github pull request ( Autotune of delays based on number of neighbors by stachuman · Pull Request #2125 · meshcore-dev/MeshCore · GitHub ) which implements the idea from the paper but I have no idea if and when it might make its way into the mainstream release.
Regards,
Serge
Ich denke nicht dass eine Anpassung der TX Delays usw bei jedem Repeater generell Sinn macht. Gerade in unserer Situation (kann nur von uns sprechen) sind auch die Balkon-/Hausrepeater in der Lage viele der höher gelegenen Repeater problemlos zu erreichen. Auch wenn die Verbindung nicht perfekt ist. Wenn die Automatik nun einen Heim-Repeater auf die selbe TX/RX Delay setzt wie ein Regional-Repeater, verliert sich die Sinnhaftigkeit dahinter wieder. Die TX Delays von z.B 1.5 öffnen ja auch nur den möglichen Bereich wann eine Nachricht versendet werden kann und nicht automatisch bedeutet dass es 1.5Sek. wartet, aber dennoch sollte, meiner Meinung nach, eine Differenzierung vom Repeaterstandort erfolgen.
Ein Regional-/ oder kantonsverbindender Repeater sollten, meiner Meinung nach, nicht automatisch die gleichen Delays erhalten nur Aufgrund der Anzahl Neighbors. Geschweige denn ein kommunaler bzw mehrere kommunale Heim-Repeater. Der Sinn hinter TX/RX Delay sollte ja, meiner Meinung nach, auch sein dass die Nahbereichsrepeater die Nachricht zustellen zu können ohne den Einsatz von kantonsübergreifenden Repeater. Abgsehen natürlich dass die Packet Collisions reduziert werden sollten.
Eine Differenzierung vom Repeater-Standort müsste in der Automatik berücksichtigt werden müssen bzw müsste der Montageort dem Algo mitgeteilt werden können dass dieser berücksichtigt wird. Denn innerhalb kommunaler Repeater einen grossartig höheren TX/RX Delay zu setzen ist, zumindest meiner Ansicht nach, kontraproduktiv. Wenn diese dann auf ähnlichen Settings sind wie Regional-Repeater, nur wegen den hörbaren Neighbors, macht das wieder die gesamte Funktion unsinnig bzw verhindert den Nutzen dahinter.
