Em geral, o “ping” do Linux deve ser mais rápido que o “hrping” do Windows?

Question

Estou usando o HP DL360p Gen8. Eu instalei o Windows Server 2008 R2 de dupla inicialização e o RHEL7. Nos dois sistemas, configurei o LACP e as VLANs. Então, esse é o mesmo servidor, o mesmo hardware, a mesma rede, as mesmas tabelas de rotas, etc.

Eu me preocupo com a latência, incluindo a latência de rede, porque estou usando este servidor para negociação de HFT.

Agora eu esperava que, se eu fizesse ping no mesmo host do Windows e do Linux, o Linux deveria ser um pouco melhor. Surpreendentemente não é nada melhor. Na verdade, mesmo ~ 5-10 microsegundos pior, então o Windows, quando eu ping mesmo host.

• estou usando hrping no Windows e ping no Linux
• no Windows eu usei o utilitário da HP para formação de equipes, no RHEL 7 usei o "agrupamento" interno (não vinculado)

Eu esperava que o Linux fosse melhor, porque:

• suponho que a implementação da rede do RHEL 7 seja mais rápida que o Windows Server 2008 R2
• suponho que a implementação do agrupamento em equipe do RHEL 7 / LACP / VLANs seja mais rápida do que o Windows Server 2008 R2 / HP um

Minhas perguntas:

1. se tal número existir: quantos microssegundos são mais rápidos do RHEL 7 do que o Windows Server 2008 R2?
2. se indica problema potencial que o Linux ping é 5-10 microssegundos mais lento ou eu deveria simplesmente ignorar este fato?
3. o que posso fazer / diagnosticar / solucionar problemas para fazer o ping do Linux mais rápido do que o Windows

É claro que na vida real eu me preocupo mais com a latência do tráfego real, como o TCP / UDP, mas estou usando ping como primeiro passo. Provavelmente ping mostre os mesmos números porque é "simples" mas no tráfego TCP / UDP real o Linux será muito mais rápido?

    

Answer 1

Existem vários fatores. A primeira é a máquina que você está usando. Se windows e linux estiverem em hardware diferente, a medição não tem sentido.

Claro que você tem que medir o ping médio após muitas tentativas, os primeiros pings podem incluir outros atrasos.

Os pacotes precisam passar pelo kernel (pilha de ip e driver de dispositivo de rede) e, em seguida, entrar novamente quando a resposta é recebida. Nesse estágio, pode haver muitos fatores que influenciam a diferença:

1. o que é realmente cronometrado: duas implementações diferentes de ping podem fazer mais ou menos trabalho padronizado entre iniciar o cronômetro e realmente enviar a coisa (e o mesmo no caminho de recepção).
2. existência de filtros: firewalls e outros, podem introduzir etapas extras
granularidade do clock de
3. : quão finamente os processos são multiplexados pelo kernel? Mesmo entre diferentes níveis de linux, o tamanho do tick pode variar muito, ou o kernel pode ser mais ou menos tickless (executando sem interrupções se houver apenas um processo em execução).
4. gerenciamento de processos: com que rapidez e de que maneira o processo é despertado quando o pacote volta? O Windows e o Linux fazem isso de maneiras completamente diferentes.
5. O que o resto do sistema está fazendo? Há IO pesado acontecendo ao mesmo tempo que tornaria o kernel ocupado? Existe uma mudança se você nice o ping para uma prioridade mais alta?
6. Escala de frequência: o gerenciamento da frequência da CPU pode variar muito: o Linux tem muitos "governadores" que fazem as coisas de maneira diferente. Então, é possível que o Linux esteja rodando com menor velocidade de clock quando ocioso - também, um momento de comutação de frequência tem latência extra.
7. A implementação e compilação da ping utility também pode ter alguns efeitos menores (embora a latência in-kernel seja provavelmente a principal contribuição).

O kernel Linux é conhecido por atingir o limite de taxa de transferência de rede em nível de 10 gigabits . Então ... não deve fazer muita diferença a velocidades de microssegundos. É provável que seja uma questão de agendamento, latências do sistema operacional e assim por diante. E a latência de ping não representa o desempenho real sob carga. Você não deve tomar essa medida como um fator quando você decide alguma coisa. Você precisa de muitos outros benchmarks, particularmente sob cargas realistas.

E finalmente, as configurações do kernel do linux podem influenciar bastante o desempenho - os projetos em tempo real precisam de um kernel dedicado para executar em um nível ideal. Você encontrará mais variações entre diferentes configurações (em ambas as plataformas) do que encontrou nessas duas tentativas.