Ist jetzt eine 1Gbit/s Glasfaserleitung, also ja Latenz deutlich besser.
Im Moment denke ich aber das Gateway auf dem ich terminiere ist das Limit. Da läuft der fastd nämlich dann auf 95% wenn das PI 115Mbit/s durch drückt ;).
Edit:// Habe gerade das Gateway gewechselt nun gehen auch im Peak 150Mbit/s.
Also um einen Eindruck davon zu bekommen, dass ein Raspberry Pi 4 als Offloader brauchbar sein dürfte reicht es. Aber wie du, @awlnxb schon gemerkt hast, sind bei diesen Geschwindigkeiten durchaus die Gateways bereits ausgelastet. Man müsste das also mal lokal testen um wirklich herauszufinden was möglich ist.
Was verbraucht denn ein PI 4 wenn er mit Gluon im Idle ist und wenn er durch eine Datenübertragung ausgelastet ist?
Gute Frage, den genauen Stromverbrauch habe ich nicht gemessen. Ich war aber gestern mit Raspberry PI an ner Powerbank ( Anker PowerCore 10000mAh) und LTE per iPad den ganzen Tag unterwegs. Zwei Clients waren per Wifi AC am PI verbunden.
Und erst nach 8std war die Powerbank dann leer, Unschärfe bringt hier rein, dass das PI auch anfängt das iPad zu laden ;).
Danke für die Forschungsarbeit.
Das bedeutet, dass wir mit dem RPI4 den ersten haben, der sich wirklich als Offloader (und in begrenzter Weise auch als AP) eignet.
(Für den BCM-Wifichip gibt’s ja leider keine nutzbaren Opensource-Treiber, so dass sich 11s, also Mesh leider verbietet)
Ich hatte letzte Woche auch schon einige Messungen mit dem Pi 4 und fastd gemacht (ohne Batman!):
salsa2012+umac: 189 MBit/s
null-cipher: 270 MBit/s
Mit BATMAN 143 MBit/s und 210 MBit/s.
(Eckdaten fastd 18 und batman aus Debian buster Repo/Kernel)
TL-SG105E dran (~20€) und dann geht das auch ohne USB-Ethernet Adapter, die tatsächlich eher unschön sind.
Mit dem neuen VIA-USB Controller und einem ASIX-USB3.0 Chip hab ich zwar auch 844 MBit/s Durchsatz hinbekommen, diese Dinger waren bei mir aber in der Vergangenheit öfter von Paketverlust und spontanem Linkdowngrade auf 100Mbit HD geplagt…
das kann man nicht genug betonen. Gluon wird das, selbst wenn es mal OpenWrt dafür gibt, daher ungern oder nur als BROKEN aufnehmen - prophezeie ich, aufgrund des nicht vorhandenen Mesh.
Ach ja, heisst ja jetzt wieder OpenWRT und nicht mehr LEDE. Wir hatten ja mal kurzfristig „Embedded Devices“ als Target, jetzt ist es wieder „wireless first“ mit der Rückbenennung, d.h. Targets ohne „gute“ Wifi müssen sich hinten anstellen.
Was Gluon anbetrifft: x86 oder RPI2 sind auch nicht broken, obwohl dort kein wireless an Bord ist.