Neue Experimental Firmware 0.7.0

Technik Gluon
41

I got the experimental build running on a 841v8 and CPE210. The 841v8 has been running as mesh_only just fine so far. The CPE210 showed a bug today when it stopped meshing with the 841. A reboot of just the CPE 210 fixed things. Before the reboot the log of the CPE210 showed:

[22680.121566] ath: phy0: Timeout while waiting for nf to load: AR_PHY_AGC_CONTROL=0xd0d5a
[36979.679134] ath: phy0: Timeout while waiting for nf to load: AR_PHY_AGC_CONTROL=0xd0d5a
[98731.057987] ath: phy0: Timeout while waiting for nf to load: AR_PHY_AGC_CONTROL=0xd0d5a
[171043.089130] ath: phy0: Timeout while waiting for nf to load: AR_PHY_AGC_CONTROL=0xd0d5a
[171211.319424] ath: phy0: Timeout while waiting for nf to load: AR_PHY_AGC_CONTROL=0xd0d5a
[173551.824873] ath: phy0: Timeout while waiting for nf to load: AR_PHY_AGC_CONTROL=0xd0d5a
[190936.562159] ath: phy0: Timeout while waiting for nf to load: AR_PHY_AGC_CONTROL=0xd0d5a

42

It happened again. Meshing stopped. Seems like a ~2 day interval. Anyway I can debug this more? I figured this would trigger the ath9k-workaround, but it doesn’t b/c there are devices connected to client0.

The " ath: phy0: Timeout while waiting for nf to load: AR_PHY_AGC_CONTROL" bug has been fixed upstream in linux kernel 4.5+, but lede is still using 4.4. However I do not know if the two things are related.

43

Habe auf einem Futro die 0.7.0 x86-generic installiert. Beim Speichern der Konfiguration (allgemeine Seite, auf der der Name geändert wird) kommt folgender Fehler im Firefox 45:

ffrn-fehler-lede.png828×220 5.86 KB

44

Die Probleme mit dem externen USB-Netzwerk-Interface am Futro liegen am fehlenden Kernelmodul “kmod-usb-net”. Für Kernel 4.4.52 ist es auch nirgendwo fertiggebaut zu finde …

Im aktuellen Lede-Snapshot scheint es für Kernel 4.4.59 dabei zu sein.

45

Wie oben von mir vermutet…
@leah könntest du eventuell eine neue Experimental nachschieben?

46

Ich guck später mal das ich eine baue.

47

Das Paket sollte eigentlich enthalten sein. Zumindest ist es in der Builddefinition drin. Ich baue später trotzdem mal eine neue Version.

48

Gesagt - getan. Zweimal identischen Offloader installiert - einmal generic und einmal 64 Bit.

Allerdings bin ich gerade unkreativ bezüglich Testszenario - jemand eine Idee abgesehen von iperf laufen lassen?

49

Mit der aktuellen Beta und mit USB-Nic?
Was hast du für nen Anschluss - lass die iperf Ergebnisse mal hören… :)

50

FW ist experimental, PCI-Nic and 150er Unitymedia Kabel
http://[2a01:4f8:171:fcff:223:54ff:fe61:1559]/ und http://[2a01:4f8:171:fcff:223:54ff:fe61:12e2]/

Gemessen mit einem Laptop am Offloader gegen das GW (intern)
[ 4] 0.00-30.00 sec 284 MBytes 79.5 Mbits/sec 108 sender
[ 4] 0.00-30.00 sec 283 MBytes 79.2 Mbits/sec receiver

Nix aufregendes im Moment.

51

Erste kleine Testreihe ist durch:

64 bit

[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-300.00 sec 2.58 GBytes 73.9 Mbits/sec 1548 sender
[ 4] 0.00-300.00 sec 2.58 GBytes 73.9 Mbits/sec receiver

[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-300.00 sec 2.83 GBytes 81.1 Mbits/sec 1402 sender
[ 4] 0.00-300.00 sec 2.83 GBytes 81.1 Mbits/sec receiver

[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-300.00 sec 2.67 GBytes 76.5 Mbits/sec 1466 sender
[ 4] 0.00-300.00 sec 2.67 GBytes 76.5 Mbits/sec receiver

generic

[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-300.00 sec 2.25 GBytes 64.5 Mbits/sec 3048 sender
[ 4] 0.00-300.00 sec 2.25 GBytes 64.4 Mbits/sec receiver

[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-300.00 sec 2.41 GBytes 69.1 Mbits/sec 3527 sender
[ 4] 0.00-300.00 sec 2.41 GBytes 69.1 Mbits/sec receiver

[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-300.00 sec 2.41 GBytes 69.1 Mbits/sec 3041 sender
[ 4] 0.00-300.00 sec 2.41 GBytes 69.0 Mbits/sec receiver

Demnach sieht es so aus, als wäre der Durchsatz höher.

https://s.ffrn.de/dashboard/db/nodes?var-Node=ffrn-rgrTesti-64bit&var-Node=ffrn-rgrTesti-generic&from=1492292395894&to=1492301763286

Zeigt einen höheren Speicherverbrauch bei 64Bit. Bei der CPU-Last sehe ich keinen wirklichen Unterschied. Ich werd mal schauen ob ich heute Abend ein Setup machen kann, dass man mehr Messpunkte bekommt.

3 „Gefällt mir“
52

@rgr es wäre echt super wenn du die Speedtests nicht dauerhaft durchführen würdest. Das generiert jede Menge Traffic (300GB in den letzten 24 Stunden) auf dem entsprechenden Gateway und das muss wirklich nicht sein. Ich hab die IP deines Clients jetzt mal gesperrt. Bitte sag mir bescheid, wenn du das Problem beseitigt hast.

Screenshot2017-04-17_12-57-45.png931×170 24.3 KB

53

Sorry, ich ging nicht davon aus, dass es eine relevante Belastung wäre - hab ja extra Pausen eingebaut und 10 Durchgänge später wäre es auch schon fertig gewesen. Ziel war unter anderem eine halbwegs gleichmäßige Verteilung zu bekommen.

Liste mit den Messpunkten stelle ich gleich ein, damit wenigstens alle etwas davon haben.

54

Rohdaten 64bit: https://paste.ffrn.de/?40523b9d5158219a#TLO2S0evRfbXXCZAXHQp9PhnQTZdAj8oUSh8Tt0jIAk=

Rohdaten generic: https://paste.ffrn.de/?0f84491ef1433b45#4m2Ds1Citi5Nxxz6rZBsnCY6wg20M7qv5djR3WaEq0c=

Testaufbau: Client mit 1GB interner Nic, zusätzlich 100MBit USB-Nic. Wechselnder iPerf-Test, jeweils 300 Sekunden, mit Pausen zwischen den Durchläufen.

Zwei längere Läufe, einmal mit dem Tausch der Netzwerkkarten um den USB-Adapter als Fehlerquelle beurteilen zu können.

Allerdings ist beim zweiten Mal Grafana zu Folge (https://s.ffrn.de/dashboard/db/nodes?var-Node=ffrn-rgrTesti-64bit&var-Node=ffrn-rgrTesti-generic&from=1492375519226&to=1492426987942) etwas schief gelaufen. Es sieht so aus, als wäre die Umschaltung zwischen den beiden Offloadern schief gegangen. Ursache ist mir unklar - aber das sagen zumindest die Kurven aus
Dagegen spricht jedoch die Summe des Traffics auf den Offloadern - diese ist relativ ähnlich.

Grafana zeigt ebenfalls, dass 64Bit bei der zweiten Testserie scheinbar regelmäßig keine Clients hatte - obwohl der Client permanent angestöpselt war. Das ist merkwürdig - weiss jemand zufällig wie die Clientermittlung genau funktioniert?

Ergebnis:
Sowohl der Kurztest als auch der Langtest zeigen eine Verbesserung des Durchsatzes um ca 10% bei 64Bit.
64Bit hat etwas höheren Hauptspeicher und Festplattenplatz, aber in keinem relevantem Umfang.
Ich meine aus Grafana etwas mehr Load bei 32Bit abzulesen, aber eher nicht wirklich relevant.

Bemerkenswert finde ich, dass bei beiden der Load nicht auf 1 geht, sondern nur Richtung 0.8. Da müsste man sich mal genau anschauen, welche Zeiten exakt beim Load erfasst werden - scheint ja irgendwas zu geben was hier limitiert.

Ich werde die Kisten nachher noch etwas lokal quälen - falls noch jemand einen Tipp hat was man abseits von iPerf noch testen könnte und sich im Labor aufbauen lässt - für Ideen bin ich dankbar.
interessant fände ich z.B. noch einen Lasttest mit vielen Clients - habe nur gerade kein Fest mit ausrechend Besuchern verfügbar :-)