Resumo

  • A 5x9 Networks relata um Xeon 6780E de 144 núcleos, um forwarder, 64 mil assinantes, 200 Mpps com ACL e sem QoS hierárquica e 800 Gbps com pacotes de 500 bytes. Os 1,6 Tbps resultam da escala para duas CPUs.
  • A Big VM elimina cópias de estado que dezesseis Small VMs mantinham no cache. A eficiência é explicada, mas o limite maior de execução, mudança e sessões exige redundância e recuperação medidas.
  • O material público não mostra sincronização de estado, injeção de falhas, reinício, atualização, perda ou retorno de sessões. Vazão sem recuperação testada não é capacidade disponível.

Branimir Rajtar, CTO e cofundador da 5x9 Networks, apresentou Getting 1+ Tbps from an x86 server na sessão Network Operations da APRICOT 2026, em 11 de fevereiro, em Jacarta. As 19 páginas descrevem a evolução de um Broadband Network Gateway virtualizado, com SR-IOV, Intel DPDK e uma longa sequência de ajustes de CPU, memória, cache, PCIe, BIOS, NIC e código.

O BNG termina sessões PPPoE ou IPoE e encaminha o tráfego em camada 3. Também pode executar QoS e ACL por usuário, AAA e funções de interceptação legal. Esse conjunto transforma a capacidade em mais do que pacotes por segundo: há estado de assinante, uma obrigação de continuidade e uma recuperação que precisa caber no serviço vendido.

A configuração inicial usava duas CPUs Xeon Gold de segunda geração, cada uma com 18 núcleos, e dezesseis instâncias de forwarder. A 5x9 declara 40 Mpps sem QoS hierárquica e 26 Mpps com ela; para pacotes de 500 bytes, 160 e 100 Gbps. A diferença próxima de 35% é específica daquele desenho. Não autoriza uma regra geral sobre QoS, mas deixa claro que o conjunto de funções altera materialmente o número de capacidade.

O avanço seguinte teve várias origens. O deck atribui 30% a hardware mais recente e trabalho de aplicação, outros 30% a DPDK, CPU, PCIe, BIOS e NIC, e 20% a perfilamento e reescrita. Não se trata de uma fórmula que outra rede possa copiar. A lista é valiosa por expor as dependências reais que o rótulo x86 costuma esconder.

Segundo a 5x9, o gargalo principal tornou-se a espera causada por falhas de cache. Muitos objetos de memória consumiam cache, mudanças de dados provocavam stalls e a CPU lia linhas inteiras mesmo quando o objeto útil era menor. A equipe separou estruturas de leitura e escrita, alterou o escalonamento PCIe/DMA e os algoritmos de hash e afirma ter reduzido a pegada da tabela de rotas em 90%.

Daí nasceu a Big VM. As dezesseis Small VMs armazenavam a mesma informação várias vezes no cache. Ao combiná-las em uma VM que ocupa um domínio NUMA e todos os núcleos, o desenho passa a compartilhar um único conjunto de trabalho.

A melhoria é física e plausível: mais localidade reduz idas à memória principal, espera, tabelas duplicadas e processos. Também pode diminuir o número de servidores em atividade. Mas o estado continua dependente de software, CPU, memória, PCIe e NIC; ele apenas se torna menos repetido e mais concentrado.

No resultado atual, a 5x9 usa uma CPU Xeon 6780E de 144 núcleos. A especificação oficial da Intel traz 108 MB de cache, até 88 pistas PCIe 5.0 e TDP de 330 W no modo servidor. Isso não reproduz o benchmark do BNG, mas mostra que slots, pistas, memória, placas e energia são partes do caminho.

O deck registra um forwarder, 64 mil assinantes, 200 Mpps com ACL e sem QoS hierárquica, 800 Gbps para pacotes de 500 bytes e 32 GB de memória. Os 1,6 Tbps aparecem quando a solução escala para duas CPUs. A soma de um servidor de dois sockets não pode ser narrada como um resultado de CPU única.

As demais condições são igualmente importantes. O desempenho começa a cair depois de 100 mil assinantes, embora até 260 mil sejam suportados. QoS hierárquica para todos reduz aproximadamente 30%; NAT para todos, 30% a 40%. São declarações do fornecedor sobre sua implementação. Mesmo assim, impedem que os 800 Gbps representem automaticamente um BNG com todos os recursos e uma mistura real de assinantes.

O DPDK reduz partes da pilha ao permitir que Poll Mode Drivers acessem descritores de recepção e transmissão e consultem as filas diretamente. O SR-IOV faz um dispositivo PCIe expor Virtual Functions sob uma Physical Function. Esses mecanismos aceleram e dividem o acesso ao hardware; não dizem onde o estado será copiado, o que ocorre quando o processo termina, nem quantas sessões retornam após perder uma VF, NIC ou servidor.

O CUPS também separa funções, não resultados. Um plano de controle saudável pode continuar aplicando política enquanto o Big VM que encaminha pacotes desaparece. A separação não prova continuidade do plano de usuário diante da perda da CPU, do caminho PCIe, da placa ou do servidor.

O conjunto público não oferece topologia redundante, método de sincronização ou reserva N+1. Não há falha injetada no forwarder, VF, NIC, CPU ou servidor; tempo de reinício; sequência de upgrade e rollback; contagem de sessões perdidas e recuperadas; teste com mistura de pacotes e funções; resultado de cliente em produção.

Isso não demonstra que tais controles não existam. Também não demonstra que o Big VM falhou. Apenas impede transformar uma medição de desempenho em prova de disponibilidade.

O trade-off fica mais claro ao comparar as unidades. O Small VM paga pela duplicação de cache, mas pode associar cada processo a um grupo menor. O Big VM melhora o conjunto de trabalho e coloca mais sessões no mesmo limite de software, CPU e manutenção. Múltiplos Big VMs, servidores independentes e replicação de estado podem reduzir o impacto; o deck não mede essa camada.

Cada ator controla uma parte. A 5x9 controla código, instrumentação, configuração do teste e alegação do produto. Intel e fabricantes de NIC controlam silício, firmware e compatibilidade. A operadora de acesso controla topologia, reserva, recursos ativados, janela de mudança e aceitação para os clientes. A APRICOT publica a apresentação, sem certificar o serviço.

A operadora arca com CPUs recentes, placas suportadas, chassi com PCIe suficiente, engenharia, licenças, revalidação e capacidade ociosa. Menos servidores ativos pode economizar espaço e operação. A 5x9 não publica consumo medido nem custo total. O equipamento de reserva capaz de receber estado e funções faz parte da economia, mesmo parado.

O assinante recebe o benefício somente quando a recuperação funciona. Menos servidores e software flexível podem reduzir custo. Sem um limite de retomada, um evento único pode correlacionar mais sessões. Não há aqui alegação de incidente; há uma exigência verificável para separar benefício e exposição.

O contrafactual mantém a Big VM, mas acrescenta duas ou mais instâncias em servidores diferentes, estado sincronizado e reserva N+1. A aceitação declara tamanhos de pacote, IPv4/IPv6, ACL, QoS, NAT, AAA, transações de controle e sessões ativas. Em seguida, encerra o forwarder, retira VF ou NIC, reinicia a VM, perde CPU ou servidor, faz upgrade e rollback. O registro mede sessões resetadas, tempo de recuperação e vazão sustentada pelo reserva.

Em bordas menores, o Small VM pode continuar sendo melhor se o limite de falha menor compensar o custo de cache; o próprio deck mantém esse uso. ASIC e white box só entram na comparação se forem submetidos ao mesmo serviço e às mesmas falhas.

ASN, prefixos e BGP não completam essa prova. Eles identificam recursos e rotas externas. Não certificam estado PPPoE/IPoE, QoS ou NAT dentro do gateway. RIR e conferência não ganham autoridade sobre a capacidade interna por registrarem ou publicarem a rota.

O mérito de engenharia está em localizar limites em cache, objetos de memória, NUMA, PCIe, NIC e código e deslocá-los. O próximo limite também é material: um forwarder, o conjunto de estados e o servidor que os sustenta.

Vazão sem recuperação medida não é capacidade disponível. Os 800 Gbps de uma CPU e os 1,6 Tbps de duas têm valor dentro das condições declaradas. Para virarem um ativo de acesso, a mesma arquitetura precisa sobreviver à falha e à mudança que a operadora promete absorver.

Fontes