Consulta ultra-rápida usando pacotes UDP

10

Estou implementando um sistema em que um dispositivo em uma rede consulta com uma frequência muito alta (centenas ou milhares de consultas por segundo) enviando um pequeno pacote UDP com 8 ou mais bytes de dados. Isso é recebido por outro aplicativo, talvez em outro dispositivo, que faz um processamento muito simples e envia o resultado de poucos bytes de tamanho grande envolvido em outro pacote UDP.

Gostaria de saber que tipo de tempos de ida e volta são possíveis com o hardware típico, onde os sistemas de comunicação talvez estejam conectados via Ethernet com fio a alguns metros de distância, levando em consideração os atrasos de propagação e transmissão, etc.

Outros pensamentos e sugestões também são bem-vindos.

ethernet latency speed

— John Smith
fonte

2

você pode ver latências em dezenas ou centenas de microssegundos ... definitivamente latência abaixo de milissegundos ... com base na sua descrição, parece que você está considerando um sistema de negociação financeira ... as latências solicitadas dependem muito do seu hw específico , e é muito melhor realizar testes do que pedir aconselhamento gratuito #

— Mike Pennington

Muito obrigado pela sua resposta. Na verdade, não é para um sistema de negociação financeira neste caso. Eu só queria uma vaga idéia do que era possível antes de iniciar a implementação, mais como um estudo de viabilidade do que qualquer outra coisa.

— John Smith

11

Como exemplo, o Juniper MX80 possui um atraso de entrada e saída> 8us, no comutador de baixa latência, pode ser <1us (talvez 0,7us). (Lembre-se de que o switch de corte não pode executar o corte 100% do tempo, apenas quando a porta de saída estiver ociosa!)

1 km de fibra é de aproximadamente 5us de latência (novamente, direção única).

O atraso de serialização @ 10G para carga útil de tamanho mínimo (46B) é de cerca de 67ns (0,067us). Ao aumentar a velocidade do link, você diminui o atraso de serialização.

O cabeçalho IP é 20B, o cabeçalho UDP é 8B, os dados são 8B, então você tem apenas 36B de dados, o que significa que sua carga ethernet incluirá 10B de lixo que DEVE enviar, ou seja, se você tiver algo a acrescentar à sua carga, adicione-o, tem 0 custo de latência.

Espero que você possa extrapolar o RTT a partir deles, multiplicando o atraso do dispositivo pela contagem de dispositivos e adicionando 5us por cada quilômetro de fibra e depois multiplicando por 2.

Não resisto a acrescentar alguns pensamentos sobre o HFT.

De acordo com esse volume de HFT, reduzido pela metade entre 2009 e 2012. Sugerindo que as vitórias fáceis se foram. Eu adoraria ver algum artigo científico ou apenas dados reais sobre a latência da HFT e seu efeito no lucro. Suspeito que a latência que afeta os lucros comerciais seja de outra magnitude que não a latência de que estamos falando agora. Um amigo meu que constrói uma rede para uma das maiores empresas de intercâmbio parece pensar que é apenas um cliente que 'baixa == melhor' sem entender as escalas.
Compreendo perfeitamente como a HFT era útil quando poucas pessoas o faziam, quando era possível observar o mercado. Não vendo mudanças O mercado B vê e capitaliza isso. Alguns estão falando sobre o uso da regulamentação para impedir o HFT, tributando cada comércio, tornando-o caro para todos, não acho que seja necessário, acho que a janela de oportunidade já está se fechando.

— ytti
fonte

Excelente resposta e muito informativo, obrigado. Mesmo alguns pensamentos pessoais sobre o HFT!

— John Smith

11

@JohnSmith, não deixe de considerar o atraso introduzido nos pontos de extremidade (como o agendador do SO ou o processamento do kernel) ... isso pode contribuir significativamente para o atraso que mencionei em um comentário anterior.

— 9118 Mike Pennington

Excelente argumento sobre o uso de tamanho mínimo de pacote completo a 0 custo de latência.

— generalnetworkerror 12/13

1

Eu acho que no hardware semi-sintonizado convencional você deve ser capaz de:

Sair da sua pilha de rede host
A sua próxima pilha de rede
Faça o backup dessa pilha de rede com seu pacote 'novo'

Em ~ 10 nós na 10gig. Se você realmente trava as coisas, esse número pode ser significativamente menor.

Quase toda a latência que você verá não é de hardware / cabos de rede, mas de seus sistemas host. Um switch de corte razoável (Arista, Gnodal, New Cisco, etc) ficará abaixo de 1us.

Comece assegurando que os processos que consomem os pacotes UDP estejam fixados no mesmo núcleo que sua NIC interrompe. A partir daí, verifique se a coalescência na sua NIC está desativada e, a partir daí, verifique se o MSI-X e o DCA estão ativados.

Se você é mais sério ... confira o OpenOnload do SolarFlare. Eles também têm um ótimo conjunto de ferramentas para testar / verificar o desempenho.

— radikalus
fonte