O roteador limita o desempenho da rede, mas sua carga de CPU não é 100%

3

Estou usando um dispositivo APU do PC Engines executando o FreeBSD como um roteador NAT. A configuração é muito comum: uma conexão WAN e uma conexão LAN.

Teoricamente, a conexão WAN é 800/40 Mbit / seo LAN é 1/1 Gbit / s. Na prática, o roteador é conectado via ethernet gigabit tanto a um modem (WAN) quanto a um switch Netgear (LAN).

Se eu conectar um PC rápido diretamente à conexão WAN (modem), posso atingir velocidades reais de download de aproximadamente 700 MBit / s. Mas, se o roteador estiver entre as duas, haverá um grave impacto no desempenho e as velocidades de download nunca ficarão acima de 350 MBit / s.

O que poderia ser facilmente explicado pelo fato de o roteador não ser poderoso o suficiente.

A coisa é, eu tentei ver o que estava acontecendo e, ao tentar maximizar a conexão (a largura de banda real medida é de 350 MBit / s), as CPUs do roteador estão ociosas em 30% do tempo.

Eu entendo que isso significa que a CPU não é o gargalo. Mas então, o que é? Existe uma maneira de diagnosticar o que o roteador está realmente fazendo com mais precisão e por que ele está funcionando apenas com metade da capacidade?

Para esclarecer minha dúvida, aqui estão alguns detalhes adicionais.

Primeiro, uma representação visual do problema:

Em seguida, e para referência, a saída de top -S -C -H -P -s1 -ocpu

Quando há muito pouco tráfego no roteador:

last pid: 14077;  load averages:  0.00,  0.00,  0.00    up 0+18:13:58  12:02:53
118 processes: 3 running, 98 sleeping, 17 waiting
CPU 0:  0.0% user,  0.0% nice,  0.8% system,  0.0% interrupt, 99.2% idle
CPU 1:  0.0% user,  0.0% nice,  0.8% system,  0.0% interrupt, 99.2% idle
Mem: 16M Active, 89M Inact, 130M Wired, 497M Buf, 3678M Free
Swap: 8192M Total, 8192M Free

  PID USERNAME PRI NICE   SIZE    RES STATE   C   TIME     CPU COMMAND
   11 root     155 ki31     0K    32K CPU1    1  18.0H 100.00% idle{idle: cpu1}
   11 root     155 ki31     0K    32K RUN     0  18.0H 100.00% idle{idle: cpu0}
14077 root      20    0 21996K  3120K CPU0    0   0:00   0.10% top
   12 root     -92    -     0K   272K WAIT    1   5:22   0.00% intr{irq259: re0
   12 root     -92    -     0K   272K WAIT    0   4:21   0.00% intr{irq260: re1
    9 root     -16 ki-1     0K    16K pollid  0   1:51   0.00% idlepoll
   12 root     -60    -     0K   272K WAIT    0   1:40   0.00% intr{swi4: clock
    0 root     -16    0     0K   160K swapin  1   0:37   0.00% kernel{swapper}
    5 root     -16    -     0K    16K pftm    0   0:31   0.00% pf purge
24147 root      20    0 12464K  2176K select  0   0:25   0.00% apinger
11846 root      52   20 17144K  2692K wait    1   0:12   0.00% sh
52774 root      20    0 28172K 18060K select  1   0:10   0.00% ntpd{ntpd}
   15 root     -16    -     0K    16K -       0   0:09   0.00% rand_harvestq
87531 dhcpd     20    0 24820K 13576K select  1   0:08   0.00% dhcpd
44974 unbound   20    0 47020K 19840K kqread  0   0:08   0.00% unbound{unbound}
   20 root      16    -     0K    16K syncer  0   0:05   0.00% syncer

E quando tento maximizar a conexão WAN (e só tenho 318 MBit / s nesse caso):

last pid: 41402;  load averages:  0.02,  0.01,  0.00    up 0+18:15:40  12:04:35
118 processes: 4 running, 98 sleeping, 16 waiting
CPU 0:  0.0% user,  0.0% nice,  0.7% system, 34.3% interrupt, 64.9% idle
CPU 1:  0.0% user,  0.0% nice,  0.0% system, 68.7% interrupt, 31.3% idle
Mem: 16M Active, 89M Inact, 130M Wired, 497M Buf, 3678M Free
Swap: 8192M Total, 8192M Free

  PID USERNAME PRI NICE   SIZE    RES STATE   C   TIME     CPU COMMAND
   11 root     155 ki31     0K    32K CPU0    0  18.0H  82.86% idle{idle: cpu0}
   11 root     155 ki31     0K    32K RUN     1  18.1H  69.87% idle{idle: cpu1}
   12 root     -92    -     0K   272K WAIT    1   5:27  32.86% intr{irq259: re0
   12 root     -92    -     0K   272K CPU0    0   4:23  17.19% intr{irq260: re1
14077 root      20    0 21996K  3232K CPU0    0   0:01   0.10% top
    9 root     -16 ki-1     0K    16K pollid  0   1:51   0.00% idlepoll
   12 root     -60    -     0K   272K WAIT    0   1:40   0.00% intr{swi4: clock
    0 root     -16    0     0K   160K swapin  0   0:37   0.00% kernel{swapper}
    5 root     -16    -     0K    16K pftm    1   0:31   0.00% pf purge
24147 root      20    0 12464K  2176K select  0   0:25   0.00% apinger
11846 root      52   20 17144K  2692K wait    0   0:12   0.00% sh
52774 root      20    0 28172K 18060K select  1   0:10   0.00% ntpd{ntpd}
   15 root     -16    -     0K    16K -       0   0:09   0.00% rand_harvestq
87531 dhcpd     20    0 24820K 13576K select  1   0:08   0.00% dhcpd
44974 unbound   20    0 47020K 19840K kqread  1   0:08   0.00% unbound{unbound}
   20 root      16    -     0K    16K syncer  0   0:05   0.00% syncer
    
por Ecco 31.01.2015 / 13:09

6 respostas

2

Desenvolvi uma placa usando o chip phy Realtek RTL8211E e posso garantir que ela é capaz de operar em velocidade gigabit :) (na verdade, 10/100/1000). O único problema com esse chip phy seria se ele não tivesse sido conectado à CPU usando uma interface gigabit (como RGMII, por exemplo). Não encontrei o layout do PCB do seu roteador na internet para verificá-lo.

No entanto, como escrevi antes, parece mais provável que seja uma incompatibilidade bidirecional.

    
por 10.02.2015 / 21:51
1

Pode ser algo relacionado às placas de rede e ao caminho entre elas e o kernel / cpu (incluindo o processamento de interrupções). Você deve verificar as várias configurações de "offload" (desculpe, eu não estou familiarizado o suficiente com o FreeBSD para sugerir a ferramenta certa). Procure também outras configurações específicas do driver da placa de rede que possam ser ajustadas e experimente-as.

    
por 31.01.2015 / 21:17
1

A cpu não está inativa, um núcleo 68.7% outras 34.3% de interrupções de processamento ocupadas não estão ociosas. O espaço do usuário não está ocioso no kernel.

Não familiarizado com o openbsd, você pode configurar a afinidade de cpu para que um núcleo processe o irq259 e o outro irq260. Então veja o quão ocupado cada núcleo é.

    
por 01.02.2015 / 15:24
1

Como sobre a "média de carga" do topo depois de algum tempo fazendo o teste de velocidade? Alguma vez chega a 1?

Se não for a CPU, talvez algo esteja errado com algumas camadas inferiores? Eu sugiro verificar se o ethtool ou a ferramenta mii mostram 1000FD em ambos os casos (com e sem roteador no meio). Talvez a sua placa de roteador force algumas configurações de link e talvez você tenha um problema de incompatibilidade duplex?

Você poderia executar "iperf -s" no seu roteador para verificar como está a conexão entre o seu cliente e o roteador?

Atenciosamente

    
por 10.02.2015 / 13:40
1

Este é um tema bastante antigo, mas eu pensei que contribuiria de qualquer maneira. O gargalo no seu caso é a CPU . Esta CPU tem 4 núcleos, você provavelmente está maximizando um dos núcleos, e o openBS presumivelmente está usando thread único para roteamento.

Eu realizei testes de throughput no sistema APU em vários sistemas operacionais. Os resultados são diferentes entre o BSD e o Linux.

Sistemas operacionais baseados em BSD (OpenBSD, pfSense, etc) atingem 622Mbit / s na APU, enquanto sistemas baseados em Linux (IPFire, DD-wrt, etc) lidam com 1Gbit com facilidade.

Aqui estão informações mais detalhadas sobre o benchmark realizado: link

E aqui está o teste de taxa de transferência para o BSD: link

Se você não está comprometido com o OpenBSD, tente o IPFire. Ele fornecerá uma taxa de transferência total de gigabit.

    
por 19.03.2018 / 22:51
0

Dado que a CPU não está 100% em uso, a questão se torna o que mais no sistema está limitando o desempenho.

Minha aposta é que os chips ethernet simplesmente não têm o suco. De acordo com o link da pergunta, sua placa usa o chip Realtek RTL8111E. Eu não sei nada em particular sobre este chip, mas sei que nem todas as placas / chips de ethernet são iguais. Alguns breves googling sugerem que a Realtek não é uma marca particularmente respeitada.

Em meus próprios testes, há alguns anos, descobri que as placas PCIE "servidor" da Intel podiam ser facilmente executadas com taxa de linha, mesmo com todos os recursos de descarregamento desativados, mas os cartões PCIE "client" da Intel não podiam. O cartão do servidor foi de US $ 120, o cartão do cliente de US $ 30. Vai saber.

Uma coisa que pode ajudar a transferir, mas pode prejudicar a latência, é ver se a união de interrupção está habilitada (termo linux - não sei como configurar no freeBSD).

    
por 10.02.2015 / 18:33