[fyi] fastd 841Nv9 vs 940Nv3 vs 842Nv3 live_test (poor mans speed test)

Technik Hardware
1

hab die beiden Verglichen, auf sehr einfach Art : kommt raus bei 3 Tests in Minuten
(mit allem Real Live Foo der dazu gehört an Paketen und Meshen mit 4 Routern …)
841v9 550Mhz 100Mbyte 2:52 2:41 2:44 entspricht 166s oder 4.8Mbit
940Nv3 750Mhz 100Mbyte 2:04 2:08 1:59 entspricht 124s oder 6.5Mbit
842v3 650Mhz 100Mbyte 2:28 , also 148 Sekunden also 5,4 Mbit
DIR505 400Mhz 100Mbyte 2:44, also 166 Sekunden also 4,81Mbit
(gleichzeitige Test → unwesentliche abweichungen)

(meshende Knoten dahinter 841v10 mit lede (2:53), dir505(2:10) mit gluon erreichten dann wie zu erwaren ebensolche Werte - wobei uplink magic schön wäre … (immerhin gab es ebendiese 2 unterschiedlichen uplinks)

zum nachvollziehen / selber machen …

salsa2012+umac - fastd v18

hab mir in unserem FreifunkNetz eine Dicke 100Mbyte Random Datei gebaut - die ist gut zu erreichen.
(auf dem firmware server mit abgelegt)

dd if=/dev/urandom of=random1M bs=1K count=1024
dd if=/dev/urandom of=random10M bs=10K count=1024
dd if=/dev/urandom of=random100M bs=100K count=1024

dann hab ich mit wget nach /dev/null die Zeit gestoppt

# time -v wget -O /dev/null http://firmware.fffr/random100M

Am 940Nv3 mit 750 Mhz 8Mb aktuellem Gluon Master
(940Nv3 = 940NDv6)

real	2m 3.74s
user	0m 2.39s
sys	0m 10.88s

am 841v9

# time -v  wget -O /dev/null http://firmware.fffr/random100M
real	2m 52.70s
user	0m 5.55s
sys	0m 10.03s

mehr zum 940N

[    0.000000] CPU0 revision is: 00019750 (MIPS 74Kc)
[    0.000000] SoC: Qualcomm Atheros TP9343 rev 0
...
[    0.000000] Memory: 27996K/32768K available (2855K kernel code, 151K rwdata, 576K rodata, 248K init, 200K bss, 4772K reserved)
[    0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] NR_IRQS:51
[    0.000000] Clocks: CPU:750.000MHz, DDR:400.000MHz, AHB:250.000MHz, Ref:25.000MHz
[    0.000000] Calibrating delay loop... 373.55 BogoMIPS (lpj=1867776)

mehr zum 841v9

[    0.000000] CPU0 revision is: 00019374 (MIPS 24Kc)
[    0.000000] SoC: Qualcomm Atheros QCA9533 ver 1 rev 1
...
[    0.000000] Memory: 27480K/32768K available (3079K kernel code, 165K rwdata, 772K rodata, 328K init, 205K bss, 5288K reserved, 0K cma-reserved)
[    0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] NR_IRQS:51
[    0.000000] Clocks: CPU:550.000MHz, DDR:399.218MHz, AHB:199.609MHz, Ref:25.000MHz
[    0.000000] clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 6950037990 ns
[    0.000010] sched_clock: 32 bits at 275MHz, resolution 3ns, wraps every 7809031678ns
[    0.008244] Calibrating delay loop... 366.18 BogoMIPS (lpj=1830912)

Leitung war eine Freie 50/10 Mbit vDSL Leitung.
im übrigen time -v blubb erzählt auch von den contextswitchen und viel viel mehr

2

noch ein bonus
der 842 braucht 2:28 , also 148 Sekunden also 5,4 Mbit,

da er zwar mehr Speicher hat - (Flash und RAM) aber ansonsten dem 841er entspricht, mit etwa 650MHz durchaus realistisch.

TPlink 842Nv3

[    0.000000] CPU0 revision is: 00019374 (MIPS 24Kc)
[    0.000000] SoC: Qualcomm Atheros QCA9533 ver 2 rev 0
...
[    0.000000] Clocks: CPU:650.000MHz, DDR:390.917MHz, AHB:216.666MHz, Ref:25.000MHz
[    0.000000] Calibrating delay loop... 432.53 BogoMIPS (lpj=2162688)

und weil ich die hier rumliegen hab - cpe210v1 und dir505 unter gleichen bedingungen
(yet to come …)

Dlink DIR505 rev A2

2:42 entspricht 166Sekunden bei 100Mbyte oder 4,81Mb

[    0.000000] CPU0 revision is: 00019374 (MIPS 24Kc)
[    0.000000] SoC: Atheros AR9330 rev 1
...
[    0.000000] Memory: 60484K/65536K available (2855K kernel code, 151K rwdata, 576K rodata, 248K init, 200K bss, 5052K reserved)
[    0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] NR_IRQS:51
[    0.000000] Clocks: CPU:400.000MHz, DDR:400.000MHz, AHB:200.000MHz, Ref:25.000MHz
[    0.000000] Calibrating delay loop... 265.42 BogoMIPS (lpj=1327104)
1 „Gefällt mir“
3

das der DIR505 mit 400Mhz unter real bedingungen dem 841v9 mit 550Mhz gleicht liegt nach Rücksprache vermutlich daran, dass es sehr viele kleine Pakete und damit Contextswitche sind die einen wesentlichen Teil der Limitierung ausmachen (bei 100 Mbyte in der Größenordnung 70000, wenn ich time -v richtig interpretiere, entspricht etwa 1460 Byte pro switch).
Salopp viel die Idee : „packet per Mhz is wohl wichtiger wie Byte per Mhz“
ich zitiere mal aus dem #Gluon Chat (rein als Info)

@fuzzle: fastd: warum hat ein ar9330 (dir505) mit 400 mhz den gleichen durchsatz wie ein QCA9533 (841v9) mit 550Mhz…wo ist da noch der wesentliche Unterschied
@anon75826926 : Bei einem reinen Benchmark ist der Unterschied wahrscheinlich gut sichtbar, aber mit den vielen kleinen Paketen ist die CPU hauptsächlich mit Context Switches und ähnlichem beschäftigt und kommt nicht wirklich zum Rechnen
…
Mit Babel haben wir keine Broadcasts mehr, die ganze dauerhafte Grundlast fällt weg (und es gibt nur noch eine Art Broadcasts bei signifikanten Topologieänderungen)
…
Und die Grundlast ist es, die fastd langsam macht, weil die aus sehr vielen kleinen Paketen besteht
…
in typischen Gluon-Szenarien ist einfach die Rechenzeit pro Paket viel relevanter als die Rechenzeit pro Byte, weil die meisten Pakete sehr klein sein
Das sorgt für die große Diskrepanz zwischen den Benchmarks auf https://projects.universe-factory.net/projects/fastd/wiki/Benchmarks und den Werten in der Praxis
Gibt natürlich auch andere Faktoren, aber die kleinen Pakete sind wohl das Hauptproblem

2 „Gefällt mir“