Performance Test online


#15

Dem liegt wohl ein Denkfehler meinerseits zu Grunde. Ich hatte erwartet das der erste Host auf der Route mit öffentlicher IP (also der eigentliche Übergabepunkt des FF Traffics) identisch ist mit der IP mit der ich mich durchs Netz bewege. Aber in Wirklichkeit ist es wohl die öffentliche IP vom 100.64.4.228.
Ist das der BGP Konzentrator (=> Eulenfunk Doku)? Ich hatte nicht erwartet das der mit “echten” IP4 Adressen arbeitet…

Danke


#16

WOW! Ich hatte heute Nacht einen “IP-Wechsel” im FF-netz. Er hat mich auf WUPPER2 umgeswitcht.

War ich schon betrübt über die Leistung vom WUPPER4 so muss ich nun feststellen das der WUPPER2 erst mal eine tiefe Delle in den WGET Transfer geschlagen hat.

Lag der Durchsatz auf WUPPER4 immer so um die 480KB/s so ist der Schnitt jetzt abgesunken auf unter 300KB/s - und das ausserhalb der Primetime!

http://it-userdesk.de/ff-wtal-netzwetter/check_ff_ping_stat_2016-06-09.html

Danke für den Hinweis auf die unterschiedlichen Gateways. Hätte ich das nicht eingebaut so wäre ich jetzt möglicherweise komplett confused …

Klaus


#17

Möglicherweise liegt dem Geschwindigkeiteinbruch ein generelleres Problem zu Grunde:

Habe auf jeden Fall eine neue Version gemacht und klippe jetzt immer auch den eth0 Durchsatz des aktiven Supernodes, sowie die Generalstatistik der Domain Wuppertal mit ein. Da hat man dann alles auf einem Blick!

Klaus


#18

Du wirst von der Position des Nodes aus kaum sinnvoll den Backbone ausmessen können.
Allenfalls ein “alles ist super” wird möglich sein, wenn es denn so ist.
Aber wenn es es hakt, dann wirst Du nicht herausbekommen, woran es liegt.
Dafür sitzt Du schlicht an der falschen Stelle mit Deinem Probe.

Ich würde vorschlagen, dass Du Dich bei den Messungen auf das beschränkst, was Du von dort sinnvoll beurteilen kannst.

Das ist nach meiner Einschätzung:
-Packetloss und Durchsatz zu den public-IPv4 und public-IPv6 der fastd-server
-Aufbau (OK/NOK) der fastd-tunnel via IPv4 und IPv6 der fastd-server
-batman Anbindung der gateway (TQ vom lokalen batman zu IPv4-Gateway)
-Packetloss zu den allen ipv4-gateways von allen fastd-servern aus (2-dimensionale Tabelle, um Quertraffic zu erfassen)
-DHCP-Performance (request UND renewal)

Was der Probe dafür tun müsst? eine site.conf als Parameterfile bekommen und sich dann selbstständig durchfräsen durch die Optionen/Möglichkeiten, die sich daraus ergeben.
Alles andere wird in Kaffeesatzleserei und gereizten gegenseitigen Vorhaltungen enden.


#19

Danke für den Hinweis. War ich zu voreilig, sorry. Ich dachte da bestünde ein Kausalzusammenhang.


#20

Wuppertal Durchsatz mit wget auf 270KB/s gesunken.

http://it-userdesk.de/ff-wtal-netzwetter/check_ff_ping_stat_2016-06-09.html

greetz

Klaus


#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.