Configurações TCP de baixa latência no Ubuntu

Question

Existe um servidor para medições em execução no Ubuntu no meu laboratório. E existe o programa C, que recebe dados através da conexão TCP e deve, o mais breve possível, enviar uma resposta.

Configuração

CPUs
• : 2 processadores x 4 núcleos - CPU Intel (R) Xeon (R) E5345 a 2.33GHz
• RAM: 12 GB
• NIC: Controladora Gigabit Ethernet 80003ES2LAN da Intel Corporation / Controlador Gigabit Ethernet 82546EB
• Switch de rede: Cisco Catalyst 2960
• Informação de dados: blocos de dados vêm aprox. cada 10 milissegundos. O tamanho do bloco de dados é de aprox. 1000 bytes.

A latência de rede ao receber pacotes é muito crítica (dezenas de microssegundos são importantes). Eu otimizei o programa ao máximo, mas não tenho nenhuma experiência com o Ubuntu.

O que pode ser configurado no Ubuntu para reduzir o atraso local de processamento / envio de pacotes?

    

Answer 1

Honestamente, Eu não usaria o Ubuntu para isso ... mas há opções que podem ser aplicadas a qualquer variante do Linux.

Você desejará aumentar seus buffers de pilha de rede:

net.core.rmem_default = 10000000
net.core.wmem_default = 10000000
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

Se o aplicativo estiver gravando no disco, talvez seja necessário alterar o agendador / elevador (por exemplo, o deadline elevator).

No nível do servidor, você pode modificar o gerenciador de CPU e o gerenciamento de frequência de energia e CPU (estados P, estados C).

No nível do SO, você pode alterar a prioridade em tempo real do seu aplicativo ( chrt ), otimizando para reduzir interrupções, fixando-o a uma CPU ou grupo de CPUs ( taskset ) e interromper serviços ou daemons desnecessários.

Você também pode ver algumas sugestões em: Como solucionar problemas de latência entre dois hosts linux

É difícil ser mais específico sem conhecer o hardware ou o equipamento de rede envolvido.

    

Answer 2

Se você estiver seguindo o caminho do alto desempenho, normalmente, você desejará executar o mínimo possível de processos (agendados), pois eles interferirão no seu aplicativo.

O Linux, como os sistemas operacionais clássicos do UNIX, foi projetado para rodar múltiplos aplicativos concorrentemente de uma forma justa e tenta evitar a privação de recursos e você estará apontando para o oposto, privar de tudo exceto seu aplicativo. Etapas simples no nível do SO estão alterando a boa prioridade em nível e em tempo real do seu aplicativo, alterando a scheduler ou indo para um em tempo real kernel.

O TCP / IP é normalmente ajustado para evitar quedas de conexão e fazer uso eficiente da largura de banda disponível. Para obter a menor latência possível de um link muito rápido, em vez de obter a maior largura de banda possível de uma conexão em que alguns links intermediários são mais restritos, você ajustará o ajuste da pilha de rede.

 sysctl -a 

mostrará uma série de configurações de kernels que você pode ajustar. As configurações dependem se você está ou não usando IPv4 ou IPv6 e o que exatamente você já faz em seu aplicativo, mas pode ser interessante:

• net.ipv4.tcp_window_scaling=1 RFC 1323 - suporte para IPV4 TCP tamanhos de janela maiores que 64K - geralmente necessários em redes de alta largura de banda
• net.ipv4.tcp_reordering=3 O tempo máximo que um pacote IPV4 pode ser reordenado em um fluxo de pacote TCP sem TCP assumindo a perda de pacotes e começar devagar.
• net.ipv4.tcp_low_latency=1 pretendido para dar preferência a baixa latência em relação ao maior rendimento; definição = 1 desativa o processamento de pré-processamento de IPV4 tcp
• net.ipv4.tcp_sack=0 configuração para 1 permite reconhecimento seletivo para IPV4, o que requer tcp_timestamps e adiciona alguma sobrecarga de pacotes, que você não precisa se você não experimenta o packetloss
• net.ipv4.tcp_timestamps=0 Apenas aconselhado nos casos em que o saque é necessário.
• net.ipv4.tcp_fastopen=1 Habilita para enviar dados no pacote SYN de abertura.

A maioria, se não todos, está documentada melhor na fonte do kernel .

É claro que você pode codificar soquetes TCP brutos e ignorar totalmente a pilha TCP / IP do kernel.

Frequentemente, sistemas altamente ajustados são executados em uma rede confiável e terão seus firewalls locais (iptables) desativados.