Execução lenta de ordens em uma pequena empresa de prop trading: para onde vai o tempo e quem pode resolver

A execução lenta é corrigida por quem é dono da parte do caminho da ordem em que o tempo se perde, então a primeira tarefa é encontrar essa parte. Marque cada ordem com timestamps nos pontos que você consegue ver, e o maior intervalo diz quem chamar: seus desenvolvedores ou uma empresa de engenharia para atrasos dentro do seu software, um provedor de hospedagem para a distância, a corretora para atrasos do lado dela.

O que significa “a nossa execução de ordens está lenta demais”?

A reclamação pode significar quatro problemas, e cada um tem um dono diferente.

• Todas as ordens são lentas. O atraso é praticamente o mesmo numa manhã tranquila e na abertura. Isso aponta para um custo que toda ordem paga, como a distância, a forma como você se conecta à corretora ou um trabalho lento que o seu próprio software faz antes de cada ordem sair
• As ordens são rápidas até o mercado ficar movimentado. Na abertura ou quando saem notícias, o atraso dispara. As ordens estão esperando em alguma fila, atrás de um programa que não dá conta, de um limite de mensagens ou de uma máquina ocupada com outro trabalho
• As ordens chegam a tempo, mas são executadas tarde. Uma ordem limitada fica no livro de ofertas até que alguém feche negócio com ela, e, num mercado rápido, o preço se afasta. Os timestamps mostram se a ordem chegou atrasada. Não conseguem mostrar que preço estava disponível
• A tela está atrasada. Se os preços na tela de trading ficam para trás, os traders clicam tarde e culpam a execução. Esse é um problema de dados de mercado, tratado em um artigo à parte deste blog

Só os timestamps de ordens reais, e dos preços aos quais elas reagiram, distinguem esses quatro casos. Use as reclamações dos traders para escolher quais dias verificar.

Para onde vão os milissegundos entre o nosso sistema e a bolsa?

Na ida, uma ordem atravessa quatro trechos, e a confirmação volta da corretora, às vezes só depois que a bolsa aceitou a ordem.

• O seu lado. A estratégia ou o trader decide, a ordem é montada, as suas próprias checagens rodam e a ordem é enviada. Os atrasos vêm do trabalho feito antes do envio, de pausas do programa, das configurações de rede ou de uma máquina ocupada. Seus desenvolvedores ou uma empresa de engenharia podem mudar essa parte
• A rede. A ordem viaja do seu servidor até o ponto de entrada da corretora. A distância, o roteamento da internet e saltos extras, como uma VPN, acrescentam atraso aqui. Um provedor de hospedagem ou de colocation, ou um engenheiro de redes, pode encurtar esse trecho
• A corretora. O gateway dela recebe a ordem, roda as checagens e a roteia para a bolsa. Os atrasos vêm dos próprios sistemas da corretora e das checagens obrigatórias. Só a corretora pode mudá-los; você escolhe como se conecta e qual corretora usa
• A bolsa. O matching engine aceita a ordem e devolve a confirmação. Aqui se gasta pouco tempo: a Nasdaq informa uma ida e volta da ordem à confirmação de menos de 50 microssegundos na sua rede de colocation 10G de alta velocidade. Ninguém que você possa contratar muda essa parte; você só pode chegar mais perto dela

Nos EUA, as checagens da corretora não são opcionais. A Regra 15c3-5 da SEC exige que uma corretora com acesso ao mercado “impeça a entrada de ordens que excedam limites de crédito ou de capital apropriados e predefinidos” e rejeite ordens “que excedam parâmetros apropriados de preço ou de quantidade”. A mesma regra coloca esses controles “sob o controle direto e exclusivo do broker ou dealer”. Você pode perguntar a uma corretora quanto tempo as checagens dela levam, mas a regra não permite que ela as desligue.

Como descobrir onde o tempo se perde?

Registre quatro timestamps para cada ordem:

• Decidida: a estratégia ou o trader escolheu enviá-la
• Enviada: a ordem saiu do seu servidor
• Confirmada: a mensagem da corretora confirmando que aceitou a ordem chegou ao seu servidor
• Executada: chegou o aviso de execução

O intervalo da decisão ao envio é o seu software. O do envio à confirmação é a rede e a corretora, na ida e na volta, mais a bolsa, se a corretora esperar por ela. Pergunte à corretora como funciona no caso dela. Para uma ordem que fica no livro de ofertas, o tempo da confirmação à execução é, em grande parte, o mercado.

Meça mais um número: a ida e volta de rede do seu servidor até o ponto de entrada da corretora. Ela mostra quanto do intervalo do envio à confirmação é rede.

FIX é um padrão de mensagens para trading, mantido pela FIX Trading Community. Se você se conecta por ele, as mensagens da corretora trazem dois timestamps: um de quando a mensagem foi enviada e outro de quando aconteceu o evento que ela informa. A especificação FIX chama esses campos de SendingTime e TransactTime, e a corretora pode dizer de quem é o relógio que preenche cada um. Ao lado dos seus próprios timestamps, eles mostram que parte da ida e volta aconteceu do lado de quem.

Comparar os seus timestamps com os da corretora só funciona se os dois relógios estiverem certos. A Regra 6820 da FINRA exige que os broker-dealers que reportam ao Consolidated Audit Trail mantenham os relógios operacionais a no máximo 50 milissegundos do relógio atômico do NIST. Pelas regras da UE, quem é membro de um local de negociação e usa negociação algorítmica de alta frequência precisa manter os relógios a no máximo 100 microssegundos do UTC. Um relógio que pode errar em até 50 milissegundos não consegue localizar um atraso de poucos milissegundos.

Os momentos de envio e de confirmação são lidos no seu próprio relógio, então o tempo entre eles não precisa de sincronização. Comece por aí. Se essa ida e volta for curta e as ordens ainda parecerem lentas, olhe o seu próprio software. Se for longa, verifique primeiro se o seu programa não estava pausado ou ocupado quando a resposta chegou; se não estava, o tempo está sendo gasto fora do seu software.

Depois, olhe as ordens mais lentas. Classifique as ordens de uma semana pela ida e volta e anote o tempo que só uma ordem em cada cem ultrapassa; faça o mesmo para os primeiros minutos depois da abertura e em torno de notícias com horário marcado. Uma média esconde os momentos de que os traders reclamam.

O que pode deixar a execução lenta em uma pequena prop firm?

Verifique primeiro estas seis causas.

• A API da corretora passa por um programa que você precisa rodar. A Interactive Brokers, por exemplo, descreve a TWS API como baseada na “conectividade com a Trader Workstation ou o IB Gateway”, então toda ordem passa primeiro por um desses programas. A documentação dela define um limite padrão de “50 requisições por segundo” por conexão de cliente e avisa que, em alguns casos, acima dessa taxa, “algumas ordens podem ser enfileiradas e atrasadas”. Para esse caso, a Interactive Brokers sugere passar para a API FIX dela. Se esse é o seu gargalo, pergunte à corretora de que outras formas você pode se conectar
• O servidor está longe do destino das ordens. Uma máquina no escritório ou uma região de nuvem distante paga pela distância duas vezes em cada ordem, na ida e na volta, e nenhuma mudança de código elimina isso. Para a menor distância possível, a Nasdaq oferece aos clientes a oportunidade de “instalar seus servidores e equipamentos em colocation dentro do Nasdaq Data Center”. Antes de pagar por colocation, meça a ida e volta de rede do seu servidor até o ponto de entrada da corretora
• Trabalho lento roda antes de a ordem ser enviada. Gravar a ordem em um banco de dados, esperar uma linha de log chegar ao disco ou perguntar a outro serviço se a operação é permitida acrescenta uma espera a cada ordem. Quando o banco de dados ou o disco está ocupado, a espera cresce. Mantenha em memória o que a ordem precisa e grave os registros depois que a ordem tiver saído
• As configurações de rede seguram mensagens pequenas. Uma ordem é uma mensagem pequena. O manual do Linux diz que, a menos que uma opção de socket chamada TCP_NODELAY esteja ativada, os dados de saída ficam em buffer “até que haja uma quantidade suficiente para enviar”. Seus desenvolvedores podem verificar se ela está ativada
• O programa faz pausas. Alguns garbage collectors param o programa inteiro enquanto limpam a memória. Até o garbage collector do Go, que faz a maior parte do trabalho com o programa rodando, tem “breves pausas stop-the-world”, e o guia do garbage collector do Go as inclui entre as possíveis fontes de latência. Se uma pausa acontece enquanto uma ordem está saindo, a ordem sai atrasada. Gráficos, backtests ou relatórios rodando na mesma máquina têm efeito parecido, porque a ordem espera pelo processador
• O caminho dentro da própria corretora é lento. O gateway, as checagens e o roteamento dela estão no caminho de toda ordem, e você não consegue ver por dentro. Você pode perguntar onde fica o ponto de entrada dela, que tipos de conexão ela oferece, quais limites de mensagens valem para a sua conta e se ela compartilha os próprios timestamps das suas ordens

Como cada causa é corrigida, e qual é o tamanho do trabalho?

• O intervalo da decisão ao envio é grande em todas as ordens. Tire o trabalho lento do caminho da ordem e verifique as configurações de rede. O trabalho é uma mudança no seu código, às vezes em uma única configuração
• O intervalo da decisão ao envio dispara nos momentos de mais movimento. Descubra pelo que a ordem espera: uma pausa, uma fila, uma máquina compartilhada. O trabalho é uma mudança no código ou na hospedagem, ou a reconstrução do caminho da ordem, se o próprio design cria filas
• O intervalo do envio à confirmação é grande em todas as ordens. Leve o servidor para mais perto do ponto de entrada da corretora ou mude o tipo de conexão. Conte com um contrato de hospedagem e uma migração, ou com trabalho de integração para uma conexão nova
• O intervalo do envio à confirmação dispara com o volume. Encontre o limite que você atinge, na corretora ou na sua própria conexão. Pode bastar uma conversa com a corretora, ou menos mensagens do seu lado
• O intervalo da confirmação à execução é grande. Olhe o tipo de ordem e o mercado. Isso não é trabalho de engenharia

Corrija primeiro a causa confirmada mais barata e deixe uma reconstrução para o fim. Não reescreva o sistema nem troque de corretora antes que alguém tenha medido o tempo de uma ordem, porque o atraso pode estar em outro lugar.

Quem pode nos ajudar a resolver a execução lenta de ordens?

Quem pode ajudar depende de onde o tempo se perde.

• A sua corretora. A única parte que consegue ver e mudar o próprio lado. Peça os timestamps que ela tem das suas ordens, os limites dela e as opções de conexão
• Um provedor de hospedagem ou de colocation, ou o time de conectividade da bolsa. Eles alugam espaço perto do ponto de entrada da corretora ou da bolsa e vendem as linhas de rede até lá
• O fornecedor da sua plataforma de trading, se você opera por uma plataforma licenciada. Só o fornecedor pode mudar o funcionamento interno dela, então leve a ele os seus timestamps
• Uma empresa de engenharia que trabalha com sistemas de trading. Ela mede o caminho inteiro e depois altera ou reconstrói as partes do seu lado, como o caminho da ordem, as checagens de risco e a conexão com a corretora
• Os seus próprios desenvolvedores, se você tiver. Com os quatro timestamps, um desenvolvedor competente consegue verificar cada causa do seu lado do caminho

Contrate quem contratar, faça primeiro quatro perguntas:

• Vocês vão medir antes de propor uma correção, e o que exatamente vão marcar com timestamp?
• O relatório vai separar o nosso lado, a rede e a corretora, e mostrar as ordens mais lentas, não só a média?
• Para qualquer número que vocês citarem: em qual percentil, sob qual carga, em que data?
• Se no fim o atraso estiver na corretora, o que vocês vão nos dizer?

Se a resposta à última pergunta ainda for reconstruir o seu sistema, continue procurando.

Onde a amBrain se encaixa?

A amBrain é uma empresa de engenharia de software de Yerevan, Armênia, que constrói plataformas de trading de baixa latência, matching engines e sistemas de real-time bidding em Rust. A amBrain diagnostica sistemas lentos em trading, apostas e ad tech: a plataforma em funcionamento é medida de ponta a ponta, e o relatório aponta para onde vai o tempo.

A amBrain constrói infraestrutura de trading algorítmico: execução de ordens, dados de mercado e controles de risco pré-negociação. O trabalho dela em trading inclui desenvolvimento de terminais de trading, sistemas de gestão de ordens e integração com bolsas via protocolo FIX. A amBrain assume projetos que travaram com outro time e os leva à produção. Três formatos: entrega completa, time dedicado ou engenheiros embarcados no seu time.

Se você está no começo, registre os quatro timestamps em um dia normal e em um dia movimentado. Leve-os a quem você chamar, a amBrain ou qualquer outra empresa, para que a primeira conversa já comece por onde o tempo se perde.

Perguntas comuns

• Reescrever o nosso sistema em Rust vai deixar a execução mais rápida? Só se o tempo se perde dentro do seu software, e só na parte por onde a ordem passa. Rust dá garantias de segurança de memória “sem precisar de um garbage collector”, o que elimina as pausas de coleta de lixo como causa. Não resolve nada quanto a uma máquina ocupada, à distância ou à corretora
• Conseguimos medir sem mudar o nosso código? Sim, se o seu sistema já registra em log as ordens que saem e as confirmações que chegam, com os horários: a ida e volta do envio à confirmação está nesses logs
• Uma execução mais rápida vai nos dar preços melhores? Ninguém pode prometer isso. A velocidade encurta o tempo entre a decisão e a chegada da ordem; o preço que você consegue também depende da liquidez, do tipo de ordem e do que o mercado faz nesse meio-tempo