Packets, Transactions and Queues: Design Principles for HFT Systems from a Measurement Study of CME Market Data
Ao analisar mais de um ano de dados do mercado da CME, este artigo desafia o design convencional de HFT de thread única ao demonstrar que, embora uma thread seja suficiente para o processamento de pacotes de subperíodo, uma arquitetura de threads de dois estágios pode reduzir significativamente as caudas de enfileiramento causadas por rajadas de transações, desde que a divisão encurte o estágio mais lento do sistema.
Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo
No mundo do trading de alta frequência, onde computadores compram e vendem ações em frações de segundo, a velocidade não é apenas uma vantagem; é o jogo inteiro. Esses sistemas operam sob uma premissa simples: se você conseguir processar informações de mercado mais rápido do que qualquer outra pessoa, poderá lucrar com pequenas diferenças de preço antes que elas desapareçam. Para fazer isso, engenheiros constroem softwares especializados que escutam um fluxo constante de dados das bolsas de valores, decodificam-os e tomam decisões em microssegundos. Durante anos, a indústria operou sob uma regra estrita: manter a parte mais crítica deste software em um único núcleo de processador. A lógica era que mover dados entre diferentes núcleos, ou "threads", era muito lento e arriscado, adicionando atrasos que arruinariam a velocidade do sistema. Essa abordagem tratava o software como um trabalhador único e focado que nunca passa uma tarefa adiante, acreditando que qualquer interrupção custaria mais do que o próprio trabalho.
No entanto, essa crença de longa data baseava-se em uma suposição sobre como os dados de mercado chegam: que eles vêm em um fluxo constante e aleatório, como gotas de chuva caindo em intervalos imprevisíveis. Se isso fosse verdade, a abordagem de um único trabalhador seria, de fato, a mais rápida. Mas e se os dados não caírem aleatoriamente? E se eles chegarem em rajadas súbitas e intensas, onde milhares de atualizações atingem o sistema num piscar de olhos? Um novo estudo de medição de dados reais de mercado da Chicago Mercantile Exchange sugere que a antiga regra pode estar errada nos momentos de maior atividade. Ao rastrear bilhões de pacotes de dados ao longo de mais de um ano, os pesquisadores descobriram que os dados de mercado não chegam de forma aleatória. Em vez disso, eles chegam em aglomerados apertados, onde um evento desencadeia uma sucessão rápida de outros, criando um padrão "autoexcitável". Esta descoberta muda a matemática da velocidade. Acontece que, quando os dados chegam nestas rajadas específicas e agrupadas, dividir o trabalho entre múltiplos processadores pode, na verdade, tornar o sistema mais rápido e confiável, desde que o sistema seja projetado para lidar corretamente com o ritmo das rajadas.
Os pesquisadores começaram analisando o fluxo de dados brutos conforme ele viaja do mecanismo de correspondência (matching engine) da bolsa — onde as ordens são processadas — até os computadores dos traders. Eles acompanharam cada pacote de dados individualmente, anotando exatamente quando ele saiu da bolsa e quando chegou. Descobriram que o sistema da bolsa atua como um porteiro com um limite de velocidade fixo. Mesmo quando o mecanismo de correspondência processa ordens incrivelmente rápido — às vezes em uma fração de microssegundo uma da outra — o publicador de dados da bolsa não pode enviá-las todas de uma vez. Ele as envia uma por uma, com um intervalo mínimo de cerca de 7,5 microssegundos entre cada pacote. Isso cria um trem de pacotes de dados que chega ao computador do trader com um espaçamento rítmico e constante, independentemente de quão caótica tenha sido a atividade na origem.
Este arrival rítmico é a chave para as novas descobertas. Os pesquisadores construíram uma simulação de computador para testar como diferentes designs de software lidariam com este ritmo específico. Eles compararam a abordagem tradicional de thread única, onde um processador faz todo o trabalho, contra um pipeline de múltiplos estágios, onde o trabalho é dividido entre vários processadores trabalhando em sequência. Em sua simulação, eles alimentaram o sistema com o tempo exato dos pacotes de dados reais. Os resultados foram claros: para tarefas que levam mais tempo do que o intervalo de 7,5 microssegundos entre os pacotes, a abordagem de thread única cria um enorme congestionamento. Quando uma rajada de dados chega, o processador único fica sobrecarregado, e o atraso para os últimos pacotes da rajada torna-se dezenas de vezes maior do que a própria tarefa. Esse atraso é a "cauda" que os traders temem, pois significa que suas decisões são tomadas tarde demais.
Em contraste, o pipeline de múltiplos estágios lidou com essas rajadas com facilidade. Ao dividir o trabalho, o sistema pôde processar o trem de pacotes de entrada em paralelo. Enquanto o primeiro processador estava decodificando o primeiro pacote, o segundo já estava trabalhando no segundo, e assim por diante. Isso permitiu que o sistema escoasse o congestionamento muito mais rápido, mantendo o atraso para cada pacote baixo e consistente. A simulação mostrou que, para tarefas de 16 microssegundos ou mais, a divisão do trabalho reduziu os piores casos de atraso em um fator de dez ou mais, com apenas uma pequena penalidade para os momentos típicos e não ruidosos. Os pesquisadores confirmaram que essa melhoria não se deveu ao volume bruto de dados, mas especificamente à natureza agrupada e de rajada dos tempos de chegada. Quando simularam a mesma quantidade de dados chegando aleatoriamente, o sistema multiestágio não ofereceu vantagem, e o sistema de thread única permaneceu eficiente.
O estudo também descartou outras causas potenciais para os atrasos. Eles descobriram que o tamanho dos pacotes de dados ou o número de mensagens dentro deles não era o principal motor da lentidão. Mesmo quando reorganizaram os dados para remover as rajadas, mantendo o mesmo número de pacotes, os atrasos massivos desapareceram. Isso provou que o problema era puramente sobre o tempo de chegada. Os pesquisadores também analisaram a própria bolsa para entender por que os dados chegavam nesses aglomerados. Descobriram que o mecanismo de correspondência da bolsa frequentemente processa múltiplas ordens quase simultaneamente, provavelmente porque muitos traders estão reagindo ao mesmo evento de mercado ao mesmo tempo. No entanto, o publicador da bolsa então as espaça, criando o trem rítmico que os sistemas dos traders devem lidar.
Para os designers desses sistemas de trading, o artigo oferece um guia claro, baseado em dados. Se o tempo de processamento de um sistema for menor que o intervalo de 7,5 microssegundos entre os pacotes, a regra antiga ainda se aplica: mantenha-o em uma única thread. Não há benefício em dividir o trabalho, e isso apenas adiciona complexidade desnecessária. Mas se o tempo de processamento for maior que esse intervalo, a abordagem de thread única falhará durante as rajadas, e o sistema deve ser dividido em múltiplos estágios. Os pesquisadores enfatizam que o objetivo não é usar o maior número possível de processadores, mas garantir que a parte mais lenta do processo seja rápida o suficiente para acompanhar o ritmo da bolsa. Eles também descobriram que o arranjo específico dos processadores importa menos do que garantir que o estágio mais lento seja tratado de forma eficiente.
Este trabalho não afirma ter resolvido todos os problemas do trading de alta velocidade, nem sugere que a abordagem de thread única esteja obsoleta. Ele simplesmente fornece uma medição precisa de quando essa abordagem deixa de funcionar e quando um design diferente se torna necessário. Ao medir o mundo real em vez de confiar em modelos teóricos, os pesquisadores deram aos engenheiros um limiar concreto para medir. Eles mostraram que a natureza do fluxo de dados — especificamente sua tendência de chegar em rajadas autoexcitáveis — dita a melhor maneira de construir o software que o consome. A lição é que, no mundo de alta velocidade das finanças, entender o ritmo dos dados é tão importante quanto a velocidade do computador.
Afogado em artigos na sua área?
Receba digests diários dos artigos mais recentes que correspondam às suas palavras-chave de pesquisa — com resumos técnicos, no seu idioma.