TCP acks são pausados, depois retomados e, em seguida, pausados novamente. Por quê?

Question

Gostaria de receber ajuda para encontrar o motivo da taxa de transferência de dados reduzida no meu aplicativo.

Eu tenho 12 sistemas embarcados e um servidor Linux. Os sistemas embarcados enviam dados para o servidor por meio de TCP em um link Ethernet por meio de um comutador. O seguinte é um StreamGraph TCP feito de uma captura Wireshark do tráfego de uma placa.

Comovocêpodever,atransferênciadedadosaconteceemtornode5,8MBit/satécercade0,25segundos.Issoétãorápidoquantopossoesperarqueosistemaembarcadosiga.Depoisdisso,osatrasossãoinseridosnatransferência.Aseguir,umclosedográfico:

A curva em forma de escada na parte inferior denominada ACK mostra quantos dados foram confirmados pelo servidor a qualquer momento. A curva correspondente rotulada RWIN mostra quanto haveria espaço nos buffers no datapc. Os segmentos verticais menores rotulados SENT DATA são os pacotes reais enviados.

No ponto A, o servidor registra os dados com a mesma rapidez com que são enviados, mas, por um período de 23ms, nenhuma mensagem é enviada pelo servidor. O sistema embarcado tem permissão para enviar até RWIN sem esperar por um ACK, mas não o faz porque precisa manter os dados enviados por perto até que sejam acesos (caso precisem ser retransmitidos) e o espaço de buffer de envio é limitado.

Em seguida, no ponto B, todos os dados recebidos são confirmados de uma só vez e o acking normal e o envio é retomado por 2,5 ms antes que outra pausa ocorra.

A captura do Wireshark foi feita a partir de um PC diferente que foi conectado a uma porta no switch que foi configurada para espelhar todos os dados enviados e recebidos na porta à qual o sistema embarcado estava conectado.

O servidor Linux executa um aplicativo Java que processa os dados e os armazena no disco. Não mostra sinais de ter maximizado a CPU. O sistema operacional é o Ubuntu Server 12.04 com configurações de rede padrão.

Eu posso ver que provavelmente eu poderia me beneficiar da alocação de mais espaço de buffer de envio no sistema embarcado para corresponder à quantidade de espaço de janela de recebimento no servidor Linux, mas isso não parece ser o fator limitante aqui.

Minhas perguntas são:

1. Qual poderia ser a razão para o servidor Linux pausar os ACKs, embora seja obviamente capaz de receber tudo muito bem?
2. Como posso depurar isso?

Answer 1

Tente desativar os quadros de PAUSE da Ethernet com ethtool -A devname autoneg off rx off tx off

Se isso não ajudar, pode ser um problema de escalonamento de janelas TCP e / ou um problema de storming de IRQ no host de envio ou receptor. Você pode investigar os dois problemas tentando configurações diferentes com ethtool e sysctl entradas que regulam o tráfego TCP. Sem outras informações, é muito difícil dizer o que está acontecendo aqui ...

    

Answer 2

A outra pergunta óbvia é por que os clientes param de enviar? Normalmente, o cliente não parava e aguardava o ACK antes de enviar o próximo pacote TCP. Eles estão possivelmente enviando mensagens de byte único que estão sendo atrasadas pelo Algoritmo de Nagle?

link

Se eles estiverem e seu servidor Linux estiver usando confirmação TCP atrasada, você poderá esperar atrasos de ACK de até 500 ms.

link

Se esta é a situação, então é facilmente corrigido usando mensagens maiores ou desabilitando o Algoritmo do Nagle nos sistemas embarcados (TCP_NODELAY).