Aussetzer bei der Alfred-Datenübermittlung

Wie habt ihr den die speichdauer erhoeht?

Man kann die Speicherdauer um Alfredmaster vor dem kompilieren festlegen.

Hat jemand aus unserem Team gemacht. Ich schau mal ob ichs raussuchen kann.

Wir haben das Problem nach Umstellung auf 2016.1 in Hennef auch, die Lösung dafür wäre prima :smile:

1 „Gefällt mir“

@anon68922371: Das waere super, wenn du einen Link haettest.

Naja eine Lösung ist es nicht nur ein Workaround… Wir haben das Problem schon mit 2015.1 … auf 2016.1 haben wir noch nicht gewechselt.

So nur kurz am Handy:
https://git.open-mesh.org/alfred.git/blob_plain/HEAD:/alfred.h

Alfred Data Timeout erhöhen. Wir nutzen im Moment 1200s (20min) das geht ganz gut.

Danke, aber irgenwie stehe ich da auf dem Schlauch. Wo finde ich die Einstellung, wenn ich aus dem Git-Repo von Freifunk Gluon klone?

Gar nicht.

Das ist eine Einstellung die auf dem Gateway gemacht werden muss auf dem der Alfred Master läuft.

Alfred liegt unter /usr/sbin/ und wird ueber einen Aufruf in der /etc/network/interfaces auf dem Gateway gestartet. Eine grundlegende Config fuer alfred finde ich nicht, so dass Parameter wohl nur ueber diesen Aufruf uebergeben werden. Ist diese besagte Einstellung jetzt fest in die Executable einkompiliert so dass ich neu kompilieren muss oder geht das auch anders?

Nein wie ich oben schrieb muss Alfred dafür neu kompiliert und installiert werden, damit diese Änderung greift.

Sie ist hart kodiert.

Ok, dann waere das schon mal ein Ansatz. Weiss denn jemand, was der Grund fuer das Problem ist und ob da ein Fix geplant ist? Das Problem scheinen ja mehrere Communties zu haben.

Bei uns kommen die Alfred Pakete nicht vollständig beim Server an, es fehlen ein paar Bits.

Dadurch werden die Daten vom Server verworfen und für die eingestellte Speicherdauer die aus dem Cache genutzt.

Aber warum die Daten unvollständig sind, wissen wir nicht. Das wird bei UDP sicher auch schwer zu ergründen.

Wohl wahr. Ist nur komisch, dass es bei uns mit der 2015.1.2 nicht auftrat, mit der 2016.1 aber schon.

Alfred wird es in nächsten (Haupt-)gluon-Release vermutlich nicht mehr geben, ist also sowieso nur ein Auslaufmodell.
Wer Probleme mit Gluon hat, der sollte als Lösung besser gleich den den Announced benutzen, das macht auch nur einmal Arbeit.

Also Announced hat bei uns in Tests nicht besser abgeschnitten, es sorgt sogar teils für noch mehr Traffic und oft kommen Metriken noch seltener an als in Alfred.
Wer Probleme mit Alfred hat das die „letzten Bits“ nicht ankommen, sollte Alfred mit einem Mac-Vlan Interface und geringerer MTU betreiben.
Alfred hat das Problem das es manchmal Pakete verwirft wenn diese fragmentiert ankommen.
Wir überlegen noch ob wir Metriken ala „prometheus-style“ via HTTP anbieten anstatt alfred bzw announced zu nutzen. Die Node würde sich dann einmalig via curl call an der Map anmelden und von da aus einfach alle 5 Minuten abgefragt wird.
Allerdings wird dann wohl die ursprüngliche Map nicht mehr klappen, die Topologiedaten werden ja auch via Alfred/Announced übertragen.

1 „Gefällt mir“

UDP ist so lange effektiv, wie es keinen/kaum Packetloss gibt, insbesondere bei Broadcast/Multicast.
Das mit Announced vorgesehene (und beim Node-Informant leider nicht wirklich funktionierend implementierte) Verfahren ist, bei (mehrfach) ausbleibenden Daten direkt bei den „vermissten“ Knoten die Daten zu pullen.

Angedachter Ansatz ist, den 1001er-Broadcast nur nur noch für „Discovery“ zu nutzen. (Und neue Nodes nach dem Boot ebenfalls ein paar Mal broadcasten zu lassen, damit es fixer geht.
Und ab „Knoten gelernt“ nur noch mit unicast zu arbeiten, nach dem Motto „Knoten Online ist häufiger als Knoten offline“. (kann man ja auch einstellen, sobald ein Knoten als Offline erkannt und vielleicht nochmal die doppelte Zeit verstrichen ist.)

Aber das hat jetzt weniger mit dem konkreten Alfred zu tun.
Faktisch ist es für mich, dass meshviewer zu Knoten, die per Alfred sich nicht melden, sagt „offline“ ist für viele Nutzende schlicht irreführend.

Richtig, Alfred nutzt auch UDP aber kommt damit anscheinend besser klar.
Ich nehme an das es daran liegt das es zwischen den Supernodes noch merged und wenn ich das richtig gelesen habe mittels Transaktion arbeitet.

Broadcast wollen wir halt komplett vermeiden für sowas, es gibt fest konfigurierte Fastd/L2TP Server… Da fällt ein zusätzlicher Eintrag für die Map nicht ins Gewicht und macht das ganze auch nicht unbedingt „dezentraler“ :wink:
Lieber eine solide Unicast Umsetzung als weiterhin Broadcast zu verwenden wo wir doch schon so viel davon filtern.

1 „Gefällt mir“

Gibt es einen konkreten Ansatz, den announced in Verbindung mit dem Meshviewer sauber zu implementieren? Hat das schon jemand so gemacht?

1 „Gefällt mir“

Mir ist jetzt nicht klar, worauf Deine Einschränkungen abziehen. (Fettung durch mich)

a) es gibt nicht einen, sonder zwei Ansätze.
b) Einer davon benutzt aber nicht den Meshviewer, sondern einen Fork davon
c) Eventuell sind jedoch beide Deiner Definition nach nicht „sauber genug“.

Ich würde mich auch über eine Möglichkeit freuen, einen Mapserver in der Site hinterlassen zu können, auf den die Daten dann ohne Nachfrage (vielleicht sogar bei Änderung) gepushed werden. „Sauber“ ist das aber nicht, dezentral auf jeden Fall auch nicht.
Der Hopglass-Server verursacht tatsächlich auch eine Menge Traffic. Effizienterer Pull-Code ist unterwegs.

Übrigens:
Hopglass macht mit Standardeinstellungen 7/3 Broadcast-Pings in 1 Minute und empfängt von jedem Router 1 x Statistiken, 1 x Linkinfos und alle 3 min Nodeinfos. Ich möchte das reduzieren auf 1 BC-Ping in der Minute, indem ich nur die Statistiken per Multicast abrufe und den Rest per Unicast aus der Liste der bekannten IPs.

3 „Gefällt mir“

Vielen Dank an alle, insbesondere an Tarnatos. Die modifizierte Alfred-Version macht jetzt zumindest die Auswirkungen der Paketverluste unsichtbar.