Estou investigando se posso implementar um aplicativo HPC no Windows querecebe pequenos datagramas multicast UDP (principalmente 100-400 bytes) em alta taxa, usando uma dúzia ou talvez até 200 grupos multicast(ou seja, usando MSI-X e RSS, posso escalar para vários núcleos), faz algum processamento por pacote e depois o envia. Envio via TCP Consegui subir o máximo que precisava (6,4 Gb/seg) sem bater na parede, mas receber datagramas em altas taxas de pps acabou sendo um problema.
Em umteste recenteem uma máquina NUMA de alta especificação com uma NIC Ethernet de 10 Gb de 2 portas no Windows 2012 R2, só conseguireceber centenas de milhares de datagramas UDP por segundo(descarte antecipado, ou seja, sem realmente processar os dados, para remover a sobrecarga de processamento do meu aplicativo da equação para ver o quão rápido ele fica) usando 2x12 núcleos, e a parte do kernel dos 12 grupos multicast testados parecia ser distribuída em 8 ou 10 núcleos de um nó NUMA (Máximo de filas RSSfoi definido como 16) - embora com um aplicativo .net, portanto, os aplicativos nativos devem ser capazes de funcionar mais rápido.
Mas mesmoLen Holgate só consegui receber pacotes UDP a 500kppsemseus testes de alto desempenho do Windows RIO, usando uma carga UDP de 1.024 bytes.
EmArtigo da QLogic(sistema operacional em teste não mencionado) os limites para "roteamento de pacotes superpequenos multithreaded" (de modo que inclui o recebimento e o envio subsequente?) são definidos em5,7 Mpps. EmartigossobreRede Linux, os limites são fixados em1Mpps a 2Mppspor núcleo (supostamente aumentando de forma mais ou menos linear), ou mesmo15Mppscom soluções especiais que contornam o kernel.
Por exemplomapa de rede
pode gerar tráfego na taxa de linha (14,88 Mbps) em um link 10GigE com apenas um único núcleo rodando a 900Mhz. Isso equivale a cerca de 60-65 ciclos de clock por pacote e é bem dimensionado com núcleos e frequência de clock (com 4 núcleos, a taxa de linha é alcançada em menos de 450 MHz).Taxas semelhantes são alcançadas no lado do recebimento.
Então, até onde posso levar (as versões mais recentes do) Windows/Windows Server, em particular recebendo multicast UDP conforme descrito no parágrafo inicial?
EditarHá uma postagem no blog cloudflare - e uma seção de comentários interessante - sobre como fazer isso no Linux:Como receber um milhão de pacotes por segundo, e há o correspondentepágina de comentários de notícias de hackers.
Responder1
Segundo a Microsoft, testes em seu laboratóriomostrouque "em um servidor específico em testes iniciais" deRIO, eles foram capazes de lidar
- 2Mpps sem perdano Windows Server 2008R2, ou seja, sem RIO
- 4Mpps no (pré-lançamento) Windows Server 8 usando RIO
Captura de tela desse vídeo (44:33):
Então a resposta para minha perguntaIs it possible to process millions of datagrams per second with Windows?seria:Sim, e aparentemente foi antes mesmo do RIO, no Windows Server 2008R2.
Mas além dos números oficiais, especialmente sobre software não lançado, terem que ser encarados com cautela, apenas com as informações esparsas fornecidas nesta apresentação, permanecem muitas dúvidas sobre o teste e, portanto, como interpretar corretamente os resultados. Os mais relevantes são:
- São os valores para Envio? Recebendo?Ou talvez para roteamento (ou seja, receber + enviar)?
- Qual tamanho do pacote?-> Provavelmente o mais baixo possível, como geralmente é feito quando se tenta obter números de pps para se gabar
- Quantas conexões (se TCP)/fluxos de pacotes (se UDP)? -> Provavelmente quantos forem necessários para distribuir a carga de trabalho para que todos os núcleos presentes possam ser usados
- Qual configuração de teste?Especificações e fiação da máquina e da NIC
O primeiro é crucial, porque Envios e Recebimentos exigem etapas diferentes e podem apresentar diferenças substanciais no desempenho. Para os outros números, podemos provavelmente assumir que o tamanho de pacote mais baixo, com pelo menos um fluxo de conexão/pacote por núcleo, estava sendo usado em uma máquina de alta especificação para obter os números máximos possíveis de Mpps.
EditarAcabei de encontrar um documento da Intel sobreProcessamento de pacotes de alto desempenhono Linux, e de acordo com isso, o (Linux)
plataforma pode sustentar uma taxa de transação de cerca de 2 milhões de transações por segundo
usando a pilha de rede padrão do Linux (em um host físico com 2x8 núcleos). Uma transação neste teste de solicitação/resposta inclui ambos
- recepção de um pacote UDP
- encaminhamento subsequente desse pacote
(usando o servidor de rede do netperf). O teste estava executando 100 transações em paralelo. Há muito mais detalhes no artigo, para os interessados. Eu gostaria que tivéssemos algo assim para o Windows comparar... De qualquer forma, aqui está o gráfico mais relevante para esse teste de solicitação/resposta:
Responder2
dr.
Para dar uma resposta definitiva, parecem necessários mais testes. Mas evidências circunstanciais sugerem que o Linux é o sistema operacional usado praticamente exclusivamente na comunidade de latência ultrabaixa, que também processa rotineiramente cargas de trabalho Mpps. Isso não significa que seja impossível com o Windows, mas o Windows provavelmente ficará um pouco para trás, mesmo que seja possível atingir números de Mpps. Mas isso precisa de testes para ser verificado e, por exemplo, para 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 nossa posição e onde investigar mais profundamente.
Len Holgate, que segundo o Google parece ser o único que testou o RIO para obter mais desempenho da rede Windows (e publicou os resultados), acaba de esclarecer em umcomente no blog deleque ele estava usando uma única combinação IP/Porta para enviar os pacotes UDP.
Em outras palavras, seuos resultados devem ser um pouco comparáveis aos números 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 para o desempenho ao lidar com apenas um único fluxo de pacotes UDP e não fazer nenhum processamento pesado dos pacotes, e ele menciona que apenas alguns threads são realmente usados, o que faria sentido). Isso apesar de ele dizer:
Eu não estava me esforçando tanto para obter 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 éabrindo mão da zona de conforto (relativa) do IOCP padrão para o mundo RIO mais difícilalém de "se esforçar"? Pelo menos no que diz respeito a um único fluxo de pacotes UDP.
Eu acho que o que ele quis dizer - já que ele tentou várias abordagens de design em vários testes do RIO - é que ele não ajustou, por exemplo, as configurações da NIC para extrair o máximo de desempenho. O que, por exemplo, no caso deReceber tamanho do bufferpoderia ter um enorme impacto positivo no desempenho de recepção do UDP e nos números de perda de pacotes.
O problema, entretanto, ao tentar comparar diretamente seus resultados com aqueles de outros testes Linux/Unix/BSD é este: A maioria dos testes, ao tentar ultrapassar o limite de "pacotes por segundo", usa o menor tamanho possível de pacote/quadro, ou seja, uma rede Ethernet quadro de 64 bytes. Len testou pacotes de 1.024 bytes (-> um quadro de 1.070 bytes), que (especialmente para UDP No-Nagle) pode gerar números de "bits por segundo" muito mais altos, mas pode não ultrapassar o limite de pps tanto quanto possível com pacotes menores . Portanto, não seria justo comparar esses números como estão.
Resumindo os resultados da minha busca pelo desempenho do Windows UDP até agora:
- Ninguém realmente está usando o Windows ao tentar desenvolver aplicativos de latência ultrabaixa e/ou de alto rendimento; atualmente, eles estão usando Linux
- Praticamente todos os testes de desempenho e relatórios com resultados reais (ou seja, não meros anúncios de produtos) hoje em dia são feitos em Linux ou BSD (obrigado Len por ser um pioneiro e nos dar 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 vs netmap) no Windows é mais rápido/mais lento do que no Linux? Linuxfacilmentesuporta velocidade de linha total de 10 Gb com um único núcleo a 900 MHz, Windows, nomelhor caso publicadoé capaz de ir até 43% ou 492kpps para um tamanho de pacote UDP grande de 1024, ou seja, os números de bps para tamanhos menores serão provavelmente significativamente piores, embora os números de pps provavelmente aumentem (a menos que o tratamento de interrupções ou alguma outra sobrecarga de espaço do kernel seja o limitante fator).
Quanto ao motivo pelo qual eles usam o Linux, deve ser porque desenvolver soluções que envolvem mudanças no kernel como netmap ou RIO - necessárias para levar o desempenho ao limite - é quase impossível com um sistema fechado como o Windows, a menos que seus contracheques venham de Redmond, ou você tem algum contrato especial com a Microsoft. É por isso que o RIO é um produto da MS.
Finalmente, apenas para dar alguns exemplos extremos do que descobri que estava e está acontecendo no mundo do Linux:
Já há 15 anos, alguns recebiam 680kpps usando umCPU Pentium III de 800 MHz, barramento frontal de 133 MHzem uma placa de rede de 1 GbE. Editar: Eles estavam usandoClique, um roteador em modo kernel que ignora grande parte da pilha de rede padrão, ou seja, eles "trapacearam".
Em 2013, Argônio Designgerenciouobter
marque para negociar latências tão baixas quanto 35ns [nano segundos]
Aliás, eles também afirmam que
e Argônio usam oInterruptor Arista 7124FX, que (além de um FPGA) possui um sistema operacional
construído sobre um kernel Linux padrão.
Responder3
Você certamente precisará “medir” diferentes configurações e cenários. Isso pode ser feito AFAIK com dois equipamentos fornecidos por 2 empresas.IXIAeEspiritual. Eles oferecem geradores de tráfego baseados em hardware capazes de bombear o tráfego na velocidade da linha. Eles oferecem teste de rampa onde você pode detectar a velocidade com que seu sistema específico pode entrar em colapso. Os dispositivos são caros, mas você pode alugá-los.