tl; dr
Para dar uma resposta definitiva, mais testes parecem necessários. Porém, evidências circunstanciais sugerem que o Linux é o sistema operacional usado praticamente exclusivamente na comunidade de latência ultrabaixa, que também processa rotineiramente as cargas de trabalho de Mpps. Isso não significa que seja impossível com o Windows, mas o Windows provavelmente ficará para trás um pouco, mesmo que seja possível obter números de Mpps. Mas isso precisa ser testado e, por exemplo, descobrir a que custo (CPU) esses números podem ser alcançados.
NB: Esta não é uma resposta que pretendo aceitar. O objetivo é dar a qualquer pessoa interessada em uma resposta à pergunta algumas dicas sobre onde estamos e onde investigar mais.
Len Holgate, que de acordo com o Google parece ser o único que testou o RIO para obter mais desempenho das redes Windows (e publicou os resultados), apenas esclareceu em um comentário em seu blog que estava usando um único combo IP / Port para enviar os pacotes UDP.
Em outras palavras, seus resultados devem ser comparáveis às figuras de núcleo único em testes no Linux (embora ele esteja usando 8 threads - o que, sem ter verificado seu código ainda, parece prejudicial ao desempenho ao lidar com apenas um único fluxo de pacotes UDP e não fazendo qualquer processamento pesado dos pacotes, e ele menciona que apenas alguns threads são realmente usados, o que faria sentido). Isso apesar dele dizer:
Eu não estava tentando tanto obter o desempenho máximo apenas para comparar o desempenho relativo entre APIs antigas e novas e, portanto, não fui tão minucioso em meus testes.
Mas o que está abandonando a zona de conforto (relativa) do IOCP padrão para o mundo mais difícil da RIO, além de "se esforçar"? Pelo menos no que diz respeito a um único fluxo de pacotes UDP.
Eu acho que o que ele quer dizer - como ele tentou várias abordagens de design em vários testes do RIO - é que ele não ajustou, por exemplo, as configurações de NIC para reduzir o último desempenho. Que, por exemplo, no caso de Receive Buffer Size, pode ter um enorme impacto positivo no desempenho de recebimento de UDP e nos números de perda de pacotes.
O problema, porém, ao tentar comparar diretamente seus resultados com os de outros testes Linux / Unix / BSD é o seguinte: A maioria dos testes, ao tentar empurrar o limite de "pacotes por segundo", usa o menor tamanho possível de pacote / quadro, ou seja, uma Ethernet quadro de 64 bytes. Len testou pacotes de 1024 bytes (-> um quadro de 1070 bytes), que (especialmente para o No-Nagle UDP) podem obter valores muito mais altos de "bits por segundo", mas podem não forçar o limite de pps o máximo possível com pacotes menores . Portanto, não seria justo comparar esses números como estão.
Resumindo os resultados de minha busca no Windows UDP, recebo desempenho até agora:
- Ninguém realmente está usando o Windows ao tentar desenvolver aplicativos de latência ultra baixa e / ou alto rendimento, hoje em dia eles estão usando o Linux
- Hoje em dia, praticamente todos os testes e relatórios de desempenho com resultados reais (ou seja, não são meros anúncios de produtos) estão em Linux ou BSD (obrigado Len por ser pioneiro e fornecer pelo menos um ponto de referência!)
- O UDP (soquetes padrão) no Windows é mais rápido / mais lento que no Linux? Ainda não sei dizer, teria que fazer meus próprios testes
- O UDP de alto desempenho (RIO x netmap) no Windows é mais rápido / mais lento que no Linux? O Linux lida facilmente com velocidade de linha total de 10 Gb com um único núcleo a 900 MHz, Windows, no melhor caso publicado, pode subir até 43% ou 492 kpps para um tamanho de pacote UDP grande de 1024, ou seja, números de bps para tamanhos menores provavelmente serão significativamente pior, embora os números de pps provavelmente aumentem (a menos que o manuseio de interrupção ou algum outro custo adicional do espaço do kernel seja o fator limitante).
Quanto ao motivo pelo qual eles usam o Linux, isso deve ser porque o desenvolvimento de soluções que envolvem alterações no kernel como netmap ou RIO - necessário quando o desempenho é levado ao limite - é quase impossível com um sistema fechado como o Windows, a menos que seus salários cheguem a Redmond, ou você tem algum contrato especial com a Microsoft. É por isso que o RIO é um produto MS.
Por fim, apenas para dar alguns exemplos extremos do que eu descobri foi e está acontecendo no Linux:
Já há 15 anos, alguns estavam recebendo 680kpps usando uma CPU Pentium III de 800 MHz e barramento frontal de 133 MHz em uma placa de rede de 1 GbE. Edit : Eles estavam usando o Click , um roteador no modo kernel que ignora grande parte da pilha de rede padrão, ou seja, eles "trapacearam".
Em 2013, a Argon Design conseguiu obter
assinale para negociar latências tão baixas quanto 35ns [nano segundos]
Btw eles também afirmam que
A grande maioria do código de computação existente para negociação atualmente é escrita para arquiteturas de processadores Linux on x86.
e Argon usam o switch Arista 7124FX , que (além de um FPGA) possui um SO
construído sobre um kernel Linux padrão.
