Performance Test online

Welchen Bezug hat das zur FFRL-Anbindung?

Sorry ich dachte das hier beschriebene Problem wäre dafür ursächlich das es so plötzlich bergab ging. Ich halte mich zurück bis ich mehr kapiere wo es durchläuft.

Klaus

1 „Gefällt mir“

Ich habe den Test noch einmal modifiziert.
Und zwar habe ich festgestellt das die Performance eines Wupper Zugangs sehr stark davon abhängt welcher Host als Gateway dient.

Zur Zeit (seit gestern) läuft der Test gegen Wupper6.
Wupper4 war bis zum 9. Juli das Hauptgateway. Danach wurde Wupper2 getestet.

Alle Hosts haben eine auffällige Charakteristik, doch keine ist wirklich gut.

Wupper4 (der Wechselhafte) z.B. hatte einen vergleichsweise „guten“ wget Download, der Tagesschnitt liegt so nahe an 500KB/s. Dafür bricht aber dieser Host in der Primetime stark ein.

Der Wechsel auf Wupper2 (der Lahme) erfolgte am 9.6.16, morgens um 2 Uhr und äusserte sich zunächst dadurch das der wget Download auf ca. die Hälfte absank, nämlich auf Werte so um die 250KB/s. Dieser Host aber hat dann den Vorteil das er diese „Leistung“ über den Tag konstant bringt. Er hat also diesen Bauch zur Primetime nicht.

Wupper6 nun (der Zittrige) bringt wieder bessere wget Transfers, scheint aber auch wieder Primetime Probleme zu haben. Auffällig an Wupper6 aber ist sein hoher Paketverlust, die Grafiken sind voller roter Punkte, 90% Paketverlust sind dort keine Seltenheit.

Klaus

Habe jetzt noch einmal einen manuellen Wechsel auf die WUPPER1 vorgenommen, WUPPER6 war gruselig, die armen Schweine die den als GW kriegen … :frowning:

Ab heute Nacht werden die GWs aber automatisch um 24:00 gewechselt, dann haben wir glaube ich recht aussagekräftige Kurven, jeweils immer 24 Stunden auf einem Host. Plötzliche Krisen kriegt man so zwar nicht unbedingt mit, aber einen guten Gesamteindruck.

Suche noch Nicks für die anderen Hosts, bis jetzt sind ja vergeben: Der „Zittige“ (WUPPER6), der „Lahme“ (WUPPER2) und der „Wechselhafte“ (WUPPER4) … :joy:

Ah so noch was, hat einer vlt. was Fertiges am Start um mit BASH die nodes.json auseinanderzuparsen. Könnte man die STATS noch ein bisserl schön aufpimpen…

greetz Klaus

Wobei Du Dir auch immer neue Fastd-Tunnel holen solltest, also neu Fastd-Tunnel zum Server des jeweiligen gateways (keine Ahnung, ob Du das nicht schon tust).

Ach ja, ein fastd-wupper42 muss nicht zwangsweise auch der gleichen Maschine (oder dem gleichen Blech oder dem gleichen Rack oder dem gleich RZ) sitzen wie ein „cafeba42“

Denn wenn Du da über tendenziell lahme Quertraffic-Tunnel testest, dann würde ein guter Teil der fehlenden Performance auf das Konto gehen.

1 „Gefällt mir“

Scheisse, mach ich natürlich nicht! Aber Quertraffic dürfte obertödlich sein in der Konstellation. :unamused:

Kann ich die fastd tunnel mit uci aufbauen? Weil ich hab mir jetzt mangels Resourcen auf den TP-Plasten ein schoenes Interface mit sshpass gebaut. Oder wo kann ich das recherchieren?

Vielen Dank für Deine immer sachkundigen Hinweise! Nicht easy son simpler Performancetest …

Also wenn das irgendwie mit meinen Mitteln möglich ist das zu realisieren werde ich das auf jeden Fall einbauen.

Aber dennoch Quertraffic hin oder her, ich müsste im Moment noch einen Tunnel haben zum WUPPER2 (das war quasi der letzte „natürliche“ Wechsel).

Wenn man sich nun den Graph von heute anguckt wo ich vom WUPPER6 auf WUPPER1 umgestellt habe (also beide in Quertraffic), sieht man schon ganz deutlich das das ne ganz andere Nummer ist. Abrupt hören die „Windpocken“ (= Paketverlust) auf ebenfalls das Zittern im PING.

Ich denke man kann das was ich im Kern vermute, nämlch das manche der WUPPER Teile auf hoffnungslos überlasteten Blechen fahren, ganz gut rauslesen - oder?

Danke

Klaus

Ein gangbarer Weg wäre ein cronjob auf dem gluon Knoten.

Dieser setzt täglich bei einen einzelnen anderen supernode enabled und startet dann fastd neu.

Dein Testrechner dahinter erhält vom DHCP Server automatisch (zum nächsten renew) eine neue IP und Route.

Mein Angebot einer entsprechend ausgerüsteten VM samt Remote-Console (für „Rettungsaktionen“) steht nach wie vor.
Ich denke, dass man so etwas mit einer Kiste mit reichlich (virtuellen) Interfaces, Bridges und Ram tun sollte.
Und wo man sich frei bei allen Toolchains (perl, python, awk, jquery… oder ganz banal: https fürs git-clone von confi-Dateien) bedienen kann, um die Scripte „rund“ zu bekommen, also nicht im OpenWRT-Korsett steckt.

Hallo @adorfer

Da ich grade mit diesen kleinen GL150 Teilen rumexperimentiere habe ich mir mal die Daten angeschaut die mein Tool das ich im Sommer 16 online gestellt habe produziert. (aktuell habe ich alle TP Links aus und mache alles über diese Minirouter)

Davon abgesehen das alles nach wie recht schlechte Performance hat fiel mir auf das meine „Supernode Grafiken“ schon seit geraumer Zeit nicht mehr aktuell sind.

Liegt daran das die URL

http://statistik.freifunk-wuppertal.net/wupper

nicht mehr existiert. Sind die komplett weggefallen oder liegen die jetzt woanders?

Danke

Die URL kenne ich nicht. Und ich weiss auch nicht, was dort früher mal gewesen ist.

Aber ihr könnt natürlich gern in das Grafana verlinken:
https://map.eulenfunk.de/stats/dashboard/db/global?var-job=wup&orgId=1

1 „Gefällt mir“

Ach dieses… Das lief/läuft vermutlich auf einer der Netcup-VMs.
Und die kommen meines Wissens nach einem Reboot nicht automatisch wieder hoch, wegen Security-Foo (mount-PW für die Datenplatte oder so)

Das dürfte dann aber auch schon länger down sein. Kann man irgendwen bitten das wieder hochzufahren? Anyway ist ja kein wirkliches Problem.

Danke

So sieht es aus.

Keine Ahnung was das für ein Server war, glaube aber der wurde gekündigt. Ping geht zwar, aber SSH auf Port 22 geht nicht.