[TÓPICO DEDICADO] Redes Modulares, Roteadores e mini roteadores de Alta Performance - NanoPi, Raspberry Pi, Orange Pi, Banana Pi, x86 e etc.

[_dsouza_]

Para quem interessar, abaixo um teste comparativo de desempenho do NanoPi R4S com NanoPi R5S com OpenWrt.

Fora ativar o "Software Flow Offloading", todas as demais configurações estavam no default.

O que achei "estranho" é que com cake / piece_of_cake o download foi limitado pela CPU, porém apenas 1 core estava em 100% (os demais cores estavam com baixa utilização ou em idle). Acredito que o SQM do OpenWrt não seja multithread, o que explicaria esse comportamento. Fiz o texto em inglês pois postei no fórum do OpenWrt também.

De qquer maneira com fq_codel / simple.qos o R4S consegue segurar 1Gbps com SQM com sobra. O R5S nessa mesma configuração aguenta 1Gbps também, mas no "talo". Para o R5S operar SQM com folga, teria que usar SQM fq_codel / simplest.qos.

 

[Arris]

Para quem interessar, abaixo um teste comparativo de desempenho do NanoPi R4S com NanoPi R5S com OpenWrt.

Fora ativar o "Software Flow Offloading", todas as demais configurações estavam no default.

O que achei "estranho" é que com cake / piece_of_cake o download foi limitado pela CPU, porém apenas 1 core estava em 100% (os demais cores estavam com baixa utilização ou em idle). Acredito que o SQM do OpenWrt não seja multithread, o que explicaria esse comportamento. Fiz o texto em inglês pois postei no fórum do OpenWrt também.

De qquer maneira com fq_codel / simple.qos o R4S consegue segurar 1Gbps com SQM com sobra. O R5S nessa mesma configuração aguenta 1Gbps também, mas no "talo". Para o R5S operar SQM com folga, teria que usar SQM fq_codel / simplest.qos.

Da pra fazer o balanço de carga entre os núcleos com uns comandos de
Echo

Inclusive da até pra definir qual interface usará qual núcleo

 

[EvertonPlay75]

Tava olhando os valores dos x86 no Aliexpress com as taixas, com o valor o x86 não vale mais apena pegar um udm pro

 

[luis_12]

Tava vendo os valores dos x86 no Aliexpress com as taixas, com o valor o x86 não vale mais apena pegar um udm pro

Tenho um ryzen 3 3200g + b450 + 16gb ddr4 + 120gb ssd parados. Compensa eu criar um x86 openwrt com essa config? Suportaria até quantos gigas de Internet com QoS Cake ativado?

 

[[<o>] Top´s]

Da pra fazer o balanço de carga entre os núcleos com uns comandos de
Echo

Inclusive da até pra definir qual interface usará qual núcleo

Queria fazer isso no meu minipc...
Tens alguma documentação a respeito?

 

[Arris]

Queria fazer isso no meu minipc...
Tens alguma documentação a respeito?

Nesse próprio tópico aqui se pesquisar por Echo vai achar um post do xxShark falando sobre esse balanço no Nanopi R4s.

No caso de Minipc, se você estiver usando virtualização com Proxmox, o próprio virtualizador já faz esse trabalho de gerenciar a carga em núcleos.
Recomendo habilitar o packet steering no openwrt (esqueci em qual menu fica)

 

[igormp]

Esses dias tava estudando sobre eBPF, e me veio a cabeça de fazer um load balancer usando ele pra substituir o mwan3, me pergunto o quão eficiente isso seria...

 

[tdlsb]

Pessoal, tenho um x86 e com a questão de licenciamento do pfsense pensei em mudar para openwrt mas nao tenho interesse em virtualização. Tem algum tutorial bom e completo de como devo fazer?

 

[Meritiboy]

Para quem interessar, abaixo um teste comparativo de desempenho do NanoPi R4S com NanoPi R5S com OpenWrt.

Fora ativar o "Software Flow Offloading", todas as demais configurações estavam no default.

O que achei "estranho" é que com cake / piece_of_cake o download foi limitado pela CPU, porém apenas 1 core estava em 100% (os demais cores estavam com baixa utilização ou em idle). Acredito que o SQM do OpenWrt não seja multithread, o que explicaria esse comportamento. Fiz o texto em inglês pois postei no fórum do OpenWrt também.

De qquer maneira com fq_codel / simple.qos o R4S consegue segurar 1Gbps com SQM com sobra. O R5S nessa mesma configuração aguenta 1Gbps também, mas no "talo". Para o R5S operar SQM com folga, teria que usar SQM fq_codel / simplest.qos.

Excelente teste, estava cogitando o R5S mas com esses resultados vou de R4S sem pensar 2x.

pq excluiu o simplest_tbf dos testes? vi que no fórum do openwrt algumas pessoas relatam que ele resulta em qualidade melhor que o cake.

 

[Arris]

Pessoal, tenho um x86 e com a questão de licenciamento do pfsense pensei em mudar para openwrt mas nao tenho interesse em virtualização. Tem algum tutorial bom e completo de como devo fazer?

Só baixar o backup das config do pfsense, instalar a versão pfsense CE e restaurar o backup.

 

[_dsouza_]

Da pra fazer o balanço de carga entre os núcleos com uns comandos de
Echo

Inclusive da até pra definir qual interface usará qual núcleo

Sim, mas acho q é só para o firewall/NAT. Tenho a impressão que o SQM (pelo menos o CAKE) é single threaded. Pelo menos foi o que um forista comentou lá no tópico do OpenWrt sobre isso. Pelo menos o SQM no 22.03.5 está indo sempre para um core "big". No 23.05.0, é aleatório e às vezes a thread do SQM cai num core LITTLE, e aí a desempenho despenca... Por essas e outras vou continuar com o 22.03.x por mais um tempo até que o 23.05.x amadureça...

--- Post duplo é unido automaticamente: 30/10/2023 ---

(...) pq excluiu o simplest_tbf dos testes? vi que no fórum do openwrt algumas pessoas relatam que ele resulta em qualidade melhor que o cake.

Apenas não testei mesmo... Achei que a principal diferença de qualidade era sobre os dois algoritmos qdisc (fq_codel vs CAKE). Sinceramente não sabia que os scripts simple/simplest teriam impacto significativo na qualidade (no geral a recomendação é o cake/piece_of_cake, só que o mesmo é pesado...). Quando der testo de novo e aí coloqo o simplest_tbf com fq_codel...

 

[Meritiboy]

Sim, mas acho q é só para o firewall/NAT. Tenho a impressão que o SQM (pelo menos o CAKE) é single threaded. Pelo menos foi o que um forista comentou lá no tópico do OpenWrt sobre isso. Pelo menos o SQM no 22.03.5 está indo sempre para um core "big". No 23.05.0, é aleatório e às vezes a thread do SQM cai num core LITTLE, e aí a desempenho despenca... Por essas e outras vou continuar com o 22.03.x por mais um tempo até que o 23.05.x amadureça...

--- Post duplo é unido automaticamente: 30/10/2023 ---

cara aqui tb notei diferença entre as versoes. Uso um archer c6 v3 com o MT7621, e na 22.03.5 eu conseguia SQM de 425mb sem variar a velocidade. na 23.05 SQM fica na média de 350mbs, variando bastante a velocidade as vzs até caindo p/ 250mbs

 

[_dsouza_]

cara aqui tb notei diferença entre as versoes. Uso um archer c6 v3 com o MT7621, e na 22.03.5 eu conseguia SQM de 425mb sem variar a velocidade. na 23.05 SQM fica na média de 350mbs, variando bastante a velocidade as vzs até caindo p/ 250mbs

Sim, desempenho é uma coisa, o disc "fq_codel" com script "simplest" é o que tem mais desempenho com CPUs mais fracas. Mas o consenso geral é que o CAKE é um disc superior.

Porém vc comentou que o simplest_tbf tem mais "qualidade" que os outros. O que você quis dizer com qualidade aqui?

 

[Meritiboy]

Sim, desempenho é uma coisa, o disc "fq_codel" com script "simplest" é o que tem mais desempenho com CPUs mais fracas. Mas o consenso geral é que o CAKE é um disc superior.

Porém vc comentou que o simplest_tbf tem mais "qualidade" que os outros. O que você quis dizer com qualidade aqui?

então, quando tava pesquisando sobre, eu vi que no fórum do openwrt quem utiliza fq_codel sempre aplicava o script do simplest_tbf, e alguns até alegavam que conseguiam a mesma "snapness" do cake, e menor latência que utilizando o cake. inclusive aqui no meu roteador o fq_codel + simplest também resulta em menores latências que o cake. Com cake eu consigo 150mbs e geralmente +4ms, com fq_codel eu consigo 400mbs e 0~+2ms

mas eu não faço a menor ideia de quais as diferenças entre o TBF e o HTB. Testando aqui no MT7621, não notei qualquer diferença entre o simplest e o simplest_tbf, e to usando o simplest.qos já que pela descrição o TBF funcionaria melhor em algumas arquiteturas (talvez as mais novas?)

 

[Arcanidus]

Cara eu devo admitir que quando eu testava cake e fq_codel, eu sentia pouca diferença entre os 2.
Na epoca eu botava um edgerouter com a distro padrao dele com codel e um raspberry pi com cake
e ficava melhor no fq_codel viu

Mas sei la todos falam que o cake é melhor que o codel, varios testes e graficos indicando, mas acredito que se vc não deixar torrent comendo solto deve dar quase a mesma coisa por menos processamento.

 

[natan_eliasz]

Galera eu uso o openwrt virtualizado no proxmox. uma coisa que sempre notei e esse packet loss que da as vezes no ip router. não sei se é alguma config errada ou algum bloqueio de flood. pois rola mais quando tem muita aba dando ping e tem atlas ripe virtualizado em um docker na rede.

 

[_dsouza_]

Galera eu uso o openwrt virtualizado no proxmox. uma coisa que sempre notei e esse packet loss que da as vezes no ip router. não sei se é alguma config errada ou algum bloqueio de flood. pois rola mais quando tem muita aba dando ping e tem atlas ripe virtualizado em um docker na rede.

Isso é uma característica do traceroute. Para cada hop, o mesmo manda por default 3 probes ICMP (ping), um atrás do outro, sem pausa. Muitos roteadores consideram isso flood e dropam pacotes ICMP se os mesmos forem mandados com um intervalo de tempo muito curto. Então packet loss no traceroute não indica necessariamente problema.

No traceroute do Linux pode ser adicionado a opção "-z 1" que inclui uma pausa de 1 segundo nos 3 pings para cada hop, que ameniza esse problema. Exemplo:

~$ traceroute -I -z 1 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  router.home (192.168.1.1)  1.111 ms  0.963 ms  0.894 ms
 2  c925a801.virtua.com.br (201.37.168.1)  3.136 ms  2.951 ms  2.873 ms
 3  c915e52d.virtua.com.br (201.21.229.45)  2.944 ms  2.290 ms  2.032 ms
 4  c915c004.virtua.com.br (201.21.192.4)  3.216 ms  2.879 ms  3.045 ms
 5  c915d3da.virtua.com.br (201.21.211.218)  3.105 ms  11.618 ms  2.704 ms
 6  one.one.one.one (1.1.1.1)  2.217 ms  2.485 ms  2.380 ms

Ainda assim é possivel que algum hop decida não responder os pings.

Para testar perda de pacotes o certo é usar o ping para o destino final. Se acuar perda de pacotes sim pode ser um indicativo de problema.

 

[luis_12]

Pessoal, alguém saberia informar se consigo montar um x86 com ryzen 3 3200g/16gb ddr4? Aguenta 1gb com cake?

 

[Meritiboy]

Para quem interessar, abaixo um teste comparativo de desempenho do NanoPi R4S com NanoPi R5S com OpenWrt.

Fora ativar o "Software Flow Offloading", todas as demais configurações estavam no default.

O que achei "estranho" é que com cake / piece_of_cake o download foi limitado pela CPU, porém apenas 1 core estava em 100% (os demais cores estavam com baixa utilização ou em idle). Acredito que o SQM do OpenWrt não seja multithread, o que explicaria esse comportamento. Fiz o texto em inglês pois postei no fórum do OpenWrt também.

De qquer maneira com fq_codel / simple.qos o R4S consegue segurar 1Gbps com SQM com sobra. O R5S nessa mesma configuração aguenta 1Gbps também, mas no "talo". Para o R5S operar SQM com folga, teria que usar SQM fq_codel / simplest.qos.

cara fazendo uns testes aqui eu também percebi que usando Cake + simplest.qos o uso na cpu é relativamente baixo e o troughput é bem maior que usando o pCake.qos. Sendo assim, teria alguma desvantagem em combinar o Algoritmo do Cake com o script do simplest?

 

[_dsouza_]

cara fazendo uns testes aqui eu também percebi que usando Cake + simplest.qos o uso na cpu é relativamente baixo e o troughput é bem maior que usando o pCake.qos. Sendo assim, teria alguma desvantagem em combinar o Algoritmo do Cake com o script do simplest?

Sinceramente não sei, teria que pesquisar.

 

[Tanaka.M]

Depois de uma queda de energia aqui em casa o R5S não ligou mais. A fonte está normal. Será que já era? Tem alguma coisa que eu possa tentar fazer?

 

[igormp]

Depois de uma queda de energia aqui em casa o R5S não ligou mais. A fonte está normal. Será que já era? Tem alguma coisa que eu possa tentar fazer?

Tenta ver os logs de boot dele pelo serial

 

[stratrock]

Meu setup CWWK N305 esta rodando há mais de 2 meses sem nenhum problema até agora, com quase 10 VMs rodando 24h x 7d, incluindo Zabbix server, proxmox, nginx (proxy reverso), guacamole (acesso remoto), etc...:

De ponto de melhoria esta apenas um repaste e talvez aplicar um thermal pad somente se houver um espaço entre o pipe e o die.

 

[Tanaka.M]

Tenta ver os logs de boot dele pelo serial

É, não dá output nenhum.

Alguém achou alguma alternativa mais em conta ou só tem nanopi e mini pc pelo dobro do valor agora?

 

[capa_da_gaita]

não sei se roda bem em minipc que é fraco, mas em servidores é a melhor opção (na minha opinião)