76

Odp: Test wydajności routera Netgear R6220 z flow offloading

to chyba na wszystkich platformach z 5.4 kernelem zwolnił nat , nawet na x86

router https://imgur.com/I4Li5lr | pihole https://imgur.com/lrqh63O.png | ESXI https://imgur.com/UZTeGiy.png | zyxel gs2210-48 | gs108t | rb hex poe gbit sfp | ja76pf2  n+an pro wifi @alubox na działce | ezviz w3 ac1200 openwrt ap | kilka kamer i jakieś tam jeszcze ustrojstwa połączone światłowodami, skrętką i wifi ,  apc smart ups 750 lcd smile

77 (edytowany przez sugnuf 2020-04-18 16:32:28)

Odp: Test wydajności routera Netgear R6220 z flow offloading

Cezary napisał/a:

Niestety nie mam takich doświadczeń. Mój r6220 ma uszkodzony wan, wykorzystałem więc lan1 jako wan. I po testach wyszło ok 380Mbps z włączonym  flowoffload (!)

U mnie troszkę lepiej, bo 204Mbps bez FO i 507Mbps z FO (445 dla 10 połączeń).

78 (edytowany przez mar_w 2020-09-22 23:38:09)

Odp: Test wydajności routera Netgear R6220 z flow offloading

Dzisiaj zrobiłem podobny test co kiedyś ale na obrazie z gałęzi master (kernel 5.4.65). Parę rzeczy mnie dziwi, ale przecież to master więc...
Wszystkie testy odbyły się tylko na jednym wątku procesora! CPU0 - 100%, CPU1 - 3%
Jeżeli będzie normalnie (czyli bez dodatkowych czarów ze strony użytkownika), ruszy drugi wątek to licząc liniowo wink powinno zamknąć Gigabita bez Flow_offloading smile
https://s6.ifotos.pl/mini/r6220jpeg_qqnpnnw.jpg
Wifi jak to wifi,  przy 3 równoległych połączeniach w moich okolicznościach przyrody puknął 333 Mbps na kliencie z kartą Broadcom BCM94352HMB dla radia 5GHz (AC)

EDIT: Analizując plik:

# cat /proc/interrupts
           CPU0       CPU1       
  8:   22100547   22100547  MIPS GIC Local   1  timer
  9:      24503          0  MIPS GIC  67  IPI call
10:          0      29289  MIPS GIC  68  IPI call
11:     229651          0  MIPS GIC  69  IPI resched
12:          0     216858  MIPS GIC  70  IPI resched
13:          0          0  MIPS GIC  19  1e000600.gpio-bank0, 1e000600.gpio-bank1, 1e000600.gpio-bank2
15:         12          0  MIPS GIC  33  ttyS0
16:          0          0  MIPS GIC  29  xhci-hcd:usb1
17:     917277          0  MIPS GIC  10  1e100000.ethernet
19:          2     641823  MIPS GIC  11  mt76x2e
21:         23          0  MIPS GIC  32  mt7603e
22:          0          0  1e000600.gpio   7  keys
23:          0          0  1e000600.gpio   8  keys
24:          0          0  1e000600.gpio  14  keys

widać, że używany jest tylko jeden wątek (CPU0) a przecież powinien używać DWÓCH wątków w miarę równomiernie. I tak ma wpisane w:

# cat /proc/irq/17/smp_affinity
3

czytając /proc/irq/*smp_affinity można zauważyć, że prawie wszystkie "usługi" mają wpisaną możliwość rozkładania obsługi przerwań na 2 wątki oprócz irq 19 oraz 21 czyli wifi które są przypięte tylko do CPU1.

W celach eksperymentalnych wrzuciłem wifi - 19 i 21 do CPU0 a cały "ethernet" tylko do CPU1:

# cat /proc/irq/17/smp_affinity
2
cat /proc/irq/19/smp_affinity
1
cat /proc/irq/21/smp_affinity
1

i od razu widać, że przypisanie na sztywno tylko jednego CPU działa:

# cat /proc/interrupts 
           CPU0       CPU1       
...
 17:          9     129428  MIPS GIC  10  1e100000.ethernet
...

I co się stało? Wzrosło zużycie na obu rdzeniach: CPU0 - 100%, CPU1 - 72%
a korzyści prawie żadnej, bo co prawda wzrosła prędkość do 750 Mbps, ale to jest wzrost tylko o 10,5% w stosunku do stanu sprzed eksperymentu (~680 Mbps, CPU0 - 100%, CPU1 - 3%)

EDIT2: A tak w ogóle to przejście na kernel 5.4 potrzebne jest chyba tylko dla lepszego WiFi, bo na ostatnim obrazie z eko.one  wyciąga 935 Mbps ze 100 równoległymi połączeniami i zużycie tylko 1 wątku proca na poziomie 8% w htop.
Dla pewności puściłem równolegle z testem natu - openssl speed ...

* WR1043v1 16MB@64MB * || * WT3020-16MB * || * Xiaomi Miwifi Mini * || Netgear R6220 *
* E3276 HiLink + RTL2832 + IT9135 + Siano + EC103 *