Performance Test online


#21

Welchen Bezug hat das zur FFRL-Anbindung?


#22

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


#23

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


#24

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


#25

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.


#26

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 



#27

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


#28

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.


#29

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.


#30

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


#31

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


#32

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)


#33

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


#34

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.