Sistemas de negociação de baixa latência

11 Práticas recomendadas para sistemas de baixa latência.
Foram 8 anos desde que o Google notou que um extra de 500ms de latência caiu o tráfego em 20% e a Amazon percebeu que 100ms de latência extra caíram as vendas em 1%. Desde então, os desenvolvedores estiveram correndo para o fundo da curva de latência, culminando em desenvolvedores de front-end espremendo todos os últimos milésimos de segundo de seu JavaScript, CSS e HTML. O que se segue é uma caminhada aleatória através de uma variedade de práticas recomendadas para ter em mente ao projetar sistemas de baixa latência. A maioria dessas sugestões são levadas ao extremo lógico, mas é claro que podem ser feitas compensações. (Obrigado a um usuário anônimo por fazer esta pergunta no Quora e me fazer colocar meus pensamentos por escrito).
Escolha o idioma certo.
As linguagens de script não precisam se aplicar. Embora eles continuem ficando cada vez mais rápidos, quando você está olhando para raspar os últimos milissegundos do seu tempo de processamento, você não pode ter a sobrecarga de um idioma interpretado. Além disso, você quer um modelo de memória forte para ativar a programação sem bloqueio para que você esteja olhando Java, Scala, C ++ 11 ou Go.
Mantenha tudo na memória.
I / O irá matar sua latência, portanto, certifique-se de que todos os seus dados estão na memória. Isso geralmente significa gerenciar suas próprias estruturas de dados em memória e manter um registro persistente, para que você possa reconstruir o estado após uma reinicialização de máquina ou processo. Algumas opções para um registro persistente incluem Bitcask, Krati, LevelDB e BDB-JE. Alternativamente, você pode fugir com a execução de um banco de dados local, persistente na memória, como redis ou MongoDB (com dados da memória & gt; & gt;). Observe que você pode perder alguns dados sobre falhas devido à sua sincronização de fundo no disco.
Mantenha dados e processamento colocados.
O lúpulo de rede é mais rápido do que o disco, mas mesmo assim eles vão adicionar muitas despesas gerais. Idealmente, seus dados devem caber inteiramente na memória em um host. Com a AWS fornecendo quase 1/4 TB de RAM na nuvem e servidores físicos que oferecem múltiplas TBs, isso geralmente é possível. Se você precisa executar em mais de um host, você deve garantir que seus dados e solicitações sejam adequadamente particionados para que todos os dados necessários para atender uma determinada solicitação estejam disponíveis localmente.
Mantenha o sistema subutilizado.
A baixa latência requer sempre recursos para processar a solicitação. Não tente executar no limite do que seu hardware / software pode fornecer. Sempre tem muita sala de cabeça para rajadas e depois algumas.
Mantenha os parâmetros de contexto ao mínimo.
Os switches de contexto são um sinal de que você está fazendo mais trabalho de computação do que você tem recursos. Você quer limitar seu número de segmentos ao número de núcleos em seu sistema e colocar cada segmento no seu núcleo.
Mantenha suas leituras seqüenciais.
Todas as formas de armazenamento, murchar é rotacional, baseado em flash ou memória, melhoram significativamente quando usado sequencialmente. Ao emitir leituras seqüenciais para a memória, você desencadeia o uso da pré-busca no nível de RAM, bem como no nível de cache da CPU. Se for feito corretamente, a próxima peça de dados que você precisa estará sempre em cache L1 antes de precisar. A maneira mais fácil de ajudar esse processo é fazer uso intenso de matrizes de tipos ou tipos de dados primitivos. Os ponteiros a seguir, seja através do uso de listas vinculadas ou através de matrizes de objetos, devem ser evitados a todo custo.
Lote suas escritas.
Isso parece contraintuitivo, mas você pode obter melhorias significativas no desempenho através de gravações por lotes. No entanto, existe um equívoco de que isso significa que o sistema deve aguardar uma quantidade arbitrária de tempo antes de escrever. Em vez disso, um segmento deve girar em um loop apertado fazendo I / O. Cada escrita irá lote todos os dados que chegaram desde a última gravação emitida. Isso faz com que um sistema muito rápido e adaptável.
Respeite seu cache.
Com todas essas otimizações no local, o acesso à memória rapidamente se torna um gargalo. Fixar threads para seus próprios núcleos ajuda a reduzir a poluição do cache da CPU e as E / S seqüenciais também ajudam a pré-carregar o cache. Além disso, você deve manter os tamanhos de memória para baixo usando tipos de dados primitivos para que mais dados se encaixem no cache. Além disso, você pode procurar algoritmos cache-inconscientes que funcionam recursivamente, quebrando os dados até que ele se encaixe no cache e depois faça qualquer processamento necessário.
Não bloqueando o máximo possível.
Faça com que os amigos não bloqueiem e aguardem estruturas e algoritmos de dados gratuitos. Toda vez que você usa um bloqueio, você precisa baixar a pilha para o sistema operacional para mediar o bloqueio, que é uma enorme sobrecarga. Muitas vezes, se você sabe o que está fazendo, você pode contornar os bloqueios através da compreensão do modelo de memória da JVM, C ++ 11 ou Go.
Async, tanto quanto possível.
Qualquer processamento e particularmente qualquer E / S que não seja absolutamente necessário para a construção da resposta deve ser feito fora do caminho crítico.
Paralelize o máximo possível.
Qualquer processamento e particularmente qualquer E / S que possa acontecer em paralelo deve ser feito em paralelo. Por exemplo, se sua estratégia de alta disponibilidade inclui o log de transações para o disco e o envio de transações para um servidor secundário, essas ações podem acontecer em paralelo.
Quase tudo isso vem de seguir o que o LMAX está fazendo com seu projeto Disruptor. Leia sobre isso e siga tudo o que Martin Thompson faz.
Compartilhar isso:
Relacionados.
Publicado por.
Benjamin Darfler.
29 pensamentos sobre & ldquo; 11 melhores práticas para sistemas de baixa latência & rdquo;
E feliz em estar na sua lista 🙂
Bom artigo. One beef: Go doesn & # 8217; t tem um modelo de memória sofisticado como Java ou C ++ 11. Se o seu sistema se encaixa com a rotina da rotina e a arquitetura dos canais, é bom demais, sem sorte. O AFAIK não é possível excluir o agendador de tempo de execução, portanto, não há falhas de sistema operacional nativas e a capacidade de criar suas próprias estruturas de dados livres de bloqueio como (colunas SPSC / anejadores) também faltam severamente.
Obrigado pela resposta. Embora o modelo de memória Go (golang / ref / mem) possa não ser tão robusto quanto o Java ou o C ++ 11, tive a impressão de que você ainda poderia criar estruturas de dados sem bloqueio usando isso. Por exemplo https: // github / textnode / gringo, https: // github / scryner / lfreequeue e https: // github / mocchira / golfhash. Talvez eu estivesse faltando alguma coisa? É certo que eu sei muito menos sobre o Go do que a JVM.
Benjamin, o modelo de memória Go detalhado aqui: golang / ref / mem é principalmente em termos de canais e mutexes. Eu olhei através dos pacotes que você listou e enquanto as estruturas de dados existem & # 8220; lock free & # 8221; eles não são equivalentes ao que um pode construir em Java / C ++ 11. O pacote de sincronização a partir de agora, não tem suporte para átomos relaxados ou a semântica de aquisição / lançamento do C ++ 11. Sem esse suporte, é difícil construir estruturas de dados SPSC tão eficientes quanto as possíveis em C ++ / Java. Os projetos que você liga usam atomic. Add & # 8230; que é um átomo consistente consecutivamente. Ele é construído com XADD como deveria ser # 8211; https: //github/tonnerre/golang/blob/master/src/pkg/sync/atomic/asm_amd64.s.
Eu não estou tentando derrubar Ir para baixo. É preciso um esforço mínimo para escrever IO assíncrono e concorrente.
código suficientemente rápido para a maioria das pessoas. A biblioteca std também está altamente ajustada para o desempenho. A Golang também tem suporte para estruturas que estão faltando em Java. Mas, como está, penso que o modelo de memória simplista e o tempo de execução da rotina estão no caminho da construção do tipo de sistemas de que você está falando.
Obrigado pela resposta em profundidade. Espero que as pessoas achem isso útil.
Enquanto um & # 8216; native & # 8217; O idioma provavelmente é melhor, não é estritamente necessário. O Facebook nos mostrou que pode ser feito em PHP. Concedido eles usam o PHP pré-compilado com sua máquina HHVM. Mas é possível!
Infelizmente, o PHP ainda não possui um modelo de memória aceitável, mesmo que o HHVM melhore significativamente a velocidade de execução.
Enquanto eu lutarei para usar linguagens de nível superior, tanto quanto o próximo cara, acho que a única maneira de alcançar os aplicativos de baixa latência que as pessoas estão procurando é deslizar para um idioma como C. Parece que a mais difícil é escrever em um idioma, mais rápido ele executa.
Eu recomendo que você olhe para o trabalho que está sendo feito nos projetos e blogs aos quais eu liguei. A JVM está rapidamente se tornando o ponto quente para esses tipos de sistemas porque fornece um modelo de memória forte e uma coleta de lixo que permitem a programação sem bloqueio quase impossivel com um modelo de memória fraco ou indefinido e contadores de referência para gerenciamento de memória.
Olharei, Benjamin. Obrigado por apontá-los.
A coleta de lixo para programação sem bloqueio é um pouco de um deus ex machina. As filas MPMC e SPSC podem ser criadas sem necessidade de GC. Há também muitas maneiras de fazer programação sem bloqueio sem coleta de lixo e a contagem de referências não é a única maneira. Os ponteiros de perigo, RCU, Proxy-Collectors, etc, fornecem suporte para recuperação diferida e geralmente são codificados em suporte de um algoritmo (não genérico), portanto, eles geralmente são muito mais fáceis de construir. É claro que o trade-off reside no fato de que os GCs de qualidade de produção têm muito trabalho colocado neles e ajudarão o programador menos experiente a escrever algoritmos sem bloqueio (eles deveriam estar fazendo isso?) Sem codificação de esquemas de recuperação diferida . Alguns links sobre o trabalho realizado neste campo: cs. toronto. edu/
Sim C / C ++ recentemente ganhou um modelo de memória, mas isso não significa que eles eram completamente inadequados para o código sem bloqueio anteriormente. O GCC e outros compiladores de alta qualidade tinham diretrizes específicas do compilador para fazer programação gratuita de bloqueio em plataformas suportadas por um tempo realmente grande # 8211; não era padronizado na língua. Linux e outras plataformas forneceram essas primitivas por algum tempo também. A posição única de Java foi que forneceu um modelo de memória formalizado que garantiu trabalhar em todas as plataformas suportadas. Embora, em princípio, isso seja incrível, a maioria dos desenvolvedores do lado do servidor trabalham em uma plataforma (Linux / Windows). Eles já tinham as ferramentas para criar código sem bloqueio para sua plataforma.
GC é uma ótima ferramenta, mas não é necessária. Tem um custo tanto em termos de desempenho como em complexidade (todos os truques necessários para evitar STW GC). C ++ 11 / C11 já possui suporte para modelos de memória adequados. Não vamos esquecer que as JVMs não têm responsabilidade em suportar a API insegura no futuro. O código inseguro é & # 8220; unsafe & # 8221; então você perde os benefícios das características de segurança da Java. Finalmente, o código inseguro usado para criar memória e simular estruturas em Java parece muito mais feio do que as estruturas C / C ++ onde o compilador está fazendo isso funciona de maneira confiável. C e C ++ também fornecem acesso a todas as ferramentas elétricas específicas de plataforma de baixo nível, como PAUSE ins, SSE / AVX / NEON etc. Você pode até ajustar seu layout de código através de scripts de linker! O poder fornecido pela cadeia de ferramentas C / C ++ é realmente incomparável pela JVM. O Java é uma ótima plataforma, no entanto, acho que a maior vantagem é que a lógica comercial comum (90% do seu código?) Ainda pode depender do GC e dos recursos de segurança e fazer uso de bibliotecas altamente sintonizadas e testadas escritas com inseguro. Este é um grande trade-off entre obter os últimos 5% de perf e ser produtivo. Um trade-off que faz sentido para muitas pessoas, mas um trade-off, no entanto. Escrever um código de aplicação complicado em C / C ++ é um pesadelo depois de tudo.
No dia 10 de março de 2018 às 12:52, CodeDependents escreveu:
& gt; Graham Swan comentou: "Tenho uma olhada, Benjamin. Obrigado por & gt; apontando para fora. & # 8221;
Falta o 12: Não use linguagens coletadas Garbadge. GC é um gargalo na piora. Provavelmente, interrompe todos os tópicos. É um global. Isso distrai o arquiteto para gerenciar um dos recursos mais craterais (CPU-near memory).
Na verdade, muito deste trabalho vem diretamente de Java. Para fazer uma programação livre de bloqueio, você precisa de um modelo de memória claro, que c ++ recentemente ganhou recentemente. Se você sabe trabalhar com GC e não contra isso, você pode criar sistemas de baixa latência com muita facilidade.
Eu tenho que concordar com Ben aqui. Houve muitos progressos no paralelismo do GC na última década, ou seja, com o coletor G1 sendo o incantation mais recente. Pode levar um pouco de tempo para sintonizar o heap e vários botões para obter o GC para coletar com quase nenhuma pausa, mas isso contrasta em comparação com o tempo de desenvolvimento necessário para não ter GC.
Você pode até dar um passo adiante e criar sistemas que produzem tão pouco lixo que você pode facilmente empurrar o seu GC fora da sua janela de operação. É assim que todas as lojas comerciais de alta freqüência o fazem quando são executados na JVM.
A coleta de lixo para programação sem bloqueio é um pouco de um deus ex machina. As filas MPMC e SPSC podem ser criadas sem necessidade de GC. Há também muitas maneiras de fazer programação sem bloqueio sem coleta de lixo e a contagem de referências não é a única maneira. Os ponteiros de perigo, RCU, Proxy-Collectors, etc, fornecem suporte para recuperação diferida e são codificados em suporte de um algoritmo (não genérico), portanto, eles são muito mais fáceis de construir. É claro que o trade-off reside no fato de que os GCs de qualidade de produção têm muito trabalho colocado neles e ajudarão o programador menos experiente a escrever algoritmos sem bloqueio (eles deveriam estar fazendo isso?) Sem codificação de esquemas de recuperação diferida . Alguns links sobre o trabalho realizado neste campo: cs. toronto. edu/
Sim C / C ++ recentemente ganhou um modelo de memória, mas isso não significa que eles eram completamente inadequados para o código sem bloqueio anteriormente. O GCC e outros compiladores de alta qualidade tinham diretrizes específicas do compilador para fazer programação gratuita de bloqueio em plataformas suportadas por um tempo realmente grande # 8211; não era padronizado na língua. Linux e outras plataformas forneceram essas primitivas por algum tempo também. A posição única de Java foi que forneceu um modelo de memória formalizado que garantiu trabalhar em todas as plataformas suportadas. Embora, em princípio, isso seja incrível, a maioria dos desenvolvedores do lado do servidor trabalham em uma plataforma (Linux / Windows). Eles já tinham as ferramentas para criar código sem bloqueio para sua plataforma.
GC é uma ótima ferramenta, mas não é necessária. Tem um custo tanto em termos de desempenho quanto em complexidade (todos os truques necessários para atrasar e evitar STW GC). C ++ 11 / C11 já possui suporte para modelos de memória adequados. Não vamos esquecer que as JVMs não têm responsabilidade em suportar a API insegura no futuro. O código inseguro é & # 8220; unsafe & # 8221; então você perde os benefícios das características de segurança da Java. Finalmente, o código inseguro usado para criar memória e simular estruturas em Java parece muito mais feio do que as estruturas C / C ++ onde o compilador está fazendo isso funciona de maneira confiável. C e C ++ também fornecem acesso a todas as ferramentas elétricas específicas de plataforma de baixo nível, como PAUSE ins, SSE / AVX / NEON etc. Você pode até ajustar seu layout de código através de scripts de linker! O poder fornecido pela cadeia de ferramentas C / C ++ é realmente incomparável pela JVM. O Java é uma ótima plataforma, no entanto, acho que a maior vantagem é que a lógica comercial comum (90% do seu código?) Ainda pode depender do GC e dos recursos de segurança e fazer uso de bibliotecas altamente sintonizadas e testadas escritas com inseguro. Este é um grande trade-off entre obter os últimos 5% de perf e ser produtivo. Um trade-off que faz sentido para muitas pessoas, mas um trade-off, no entanto. Escrever um código de aplicação complicado em C / C ++ é um pesadelo depois de tudo.
& gt; Não use linguagens coletadas garbadge.
Ou, pelo menos, & # 8220; tradicional & # 8221; Lixo coletado línguas. Porque eles são diferentes & # 8211; enquanto Erlang também tem um colecionador, não criou gargalos porque não pára o mundo & # 8217; t & # 8220; pára o mundo & # 8221; como Java, enquanto colecionava lixo e # 8211; em vez disso, interrompe os microcréditos pequenos individuais & # 8220; & # 8221; em uma escala de microssegunda, portanto, não é visível no grande.
Reescreva isso para & # 8220; tradicional & # 8221; algoritmos [i] de coleta de lixo [/ i]. Na LMAX usamos o Azul Zing, e apenas usando uma JVM diferente com uma abordagem diferente para a coleta de lixo, vimos grandes melhorias no desempenho, porque os GCs maiores e menores são ordens de magnitude mais baratas.
Existem outros custos que compensam isso, é claro: você usa um monte muito mais, e o Zing não é barato.
Reblogged this em Java Prorgram Exemplos e comentou:
Um dos artigos de leitura obrigatória para programadores Java, é a lição que você aprenderá depois de passar um tempo considerável de afinação e desenvolver sistemas de baixa latência em Java em 10 minutos.
Revivendo um tópico antigo, mas (incrivelmente) isso deve ser apontado:
1) Linguagens de nível superior (por exemplo, Java) não desejam a funcionalidade do hardware que não está disponível para idiomas de nível inferior (por exemplo, C); declarar que assim e assim é completamente impossível & # 8221; em C, facilmente acessível em Java, é um lixo completo sem reconhecer que o Java é executado em hardware virtual onde a JVM deve sintetizar a funcionalidade exigida pelo Java, mas não fornecida pelo hardware físico. Se uma JVM (por exemplo, escrita em C) pode sintetizar a funcionalidade X, então também pode um programador C.
2) & # 8220; Lock free & # 8221; não é o que as pessoas pensam, exceto quase por coincidência em certas circunstâncias, como o único núcleo x86; multicore x86 não pode ser executado sem bloqueio sem barreiras de memória, que tem complexidades e custos semelhantes ao bloqueio regular. De acordo com 1 acima, se o Lock Free funcionar em um determinado ambiente, é porque ele é suportado pelo hardware, ou emulado / sintetizado por software em um ambiente virtual.
Great Points Julius. O ponto que eu estava tentando (talvez sem sucesso) é que é proibitivamente difícil aplicar muitos desses padrões em C, pois eles dependem do GC. Isso vai além do simples uso de barreiras de memória. Você também deve considerar a liberação de memória, o que fica particularmente difícil quando você está lidando com algoritmos livres de segurança e sem espera. É aqui que o GC adiciona uma grande vitória. Dito isto, eu ouço que Rust tenha algumas idéias muito interessantes sobre a propriedade da memória que possam começar a abordar algumas dessas questões.

Sistemas de negociação de baixa latência
Obter através da App Store Leia esta publicação em nosso aplicativo!
Quão rápido são os sistemas de negociação HFT de última geração hoje?
Todo o tempo que você ouve sobre comércio de alta freqüência (HFT) e quão rápido são os algoritmos. Mas estou pensando - o que é rápido nos dias de hoje?
Não estou pensando na latência causada pela distância física entre uma troca e o servidor que executa um aplicativo comercial, mas a latência introduzida pelo próprio programa.
Para ser mais específico: qual é o tempo decorrido dos eventos que chegam no fio em um aplicativo para esse aplicativo, emite um pedido / preço no fio? Isto é, hora do tic-to-trade.
Estamos falando sub-milissegundo? Ou sub-microssegundo?
Como as pessoas conseguem essas latências? Codificação em montagem? FPGAs? Código de C ++ bom e antigo?
Foi recentemente publicado um artigo interessante sobre o ACM, fornecendo muitos detalhes sobre a tecnologia HFT de hoje, que é uma excelente leitura:
Você recebeu excelentes respostas. Há um problema, porém - a maioria das algotrading é um segredo. Você simplesmente não sabe o quão rápido é. Isso vai nos dois sentidos - alguns podem não dizer o quão rápido eles funcionam, porque eles não querem. Outros podem, digamos, "exagerar", por muitas razões (atraindo investidores ou clientes, por um).
Os rumores sobre picossegundos, por exemplo, são bastante escandalosos. 10 nanosegundos e 0,1 nanosegundos são exatamente a mesma coisa, porque o tempo necessário para que a ordem atinja o servidor de negociação seja muito mais do que isso.
E, o mais importante, embora não seja o que você perguntou, se você tentar negociar algorítmicamente, não tente ser mais rápido, tente ser mais inteligente. Eu vi algoritmos muito bons que podem lidar com segundos de latência e ganhar muito dinheiro.
Eu sou o CTO de uma pequena empresa que fabrica e vende sistemas HFT baseados em FPGA. Construindo nossos sistemas no topo do Solarflare Application Onload Engine (AOE), estamos constantemente oferecendo latência de um evento de mercado "interessante" no fio (10Gb / S UDP market data feed de ICE ou CME) para o primeiro byte do mensagem de ordem resultante atingindo o fio na faixa de 750 a 800 nanosegundos (sim, submicosegundo). Nós antecipamos que nossos sistemas de próxima versão estarão na faixa de 704 a 710 nanosegundos. Algumas pessoas reivindicaram um pouco menos, mas isso é em um ambiente de laboratório e na verdade não está sentado em uma COLO em Chicago e limpa as ordens.
Os comentários sobre física e "velocidade da luz" são válidos, mas não relevantes. Todo mundo que é sério sobre a HFT tem seus servidores em um COLO na sala ao lado do servidor da troca.
Para entrar neste domínio sub-microsegundo, você não pode fazer muito na CPU do host, exceto os comandos de implementação da estratégia de alimentação para o FPGA, mesmo com tecnologias como o bypass do kernel você tem 1.5 microssegundos de despesas gerais inevitáveis. então neste domínio tudo está jogando com FPGAs.
Uma das outras respostas é muito honesta ao dizer que, neste mercado altamente secreto, poucas pessoas falam sobre as ferramentas que eles usam ou seu desempenho. Cada um de nossos clientes exige que nem digamos a ninguém que eles usem nossas ferramentas nem divulguem nada sobre como elas as usam. Isso não só dificulta o marketing, mas também evita o bom fluxo de conhecimento técnico entre colegas.
Devido a esta necessidade de entrar em sistemas exóticos para a parte do mercado "wicked fast", você descobrirá que os Quants (as pessoas que aparecem nos algoritmos que fazemos rápido) estão dividindo seus algos em eventos-a - camadas de tempo de resposta. No topo da tecnologia, o heap é o sistema de microsecondos secundários (como o nosso). A próxima camada são os sistemas C ++ personalizados que fazem uso intenso do bypass do kernel e estão na faixa de 3-5 microsegundos. A próxima camada são as pessoas que não podem se dar ao luxo de estar em um fio de 10Gb / S apenas um roteador de lúpulo da "troca", eles podem estar ainda em COLO, mas por causa de um jogo desagradável que chamamos de "roleta de porta" eles estão no dezenas de centenas de microsecondos. Uma vez que você entra em milissegundos, quase não é HFT.
"sub-40 microssegundos", se você quiser acompanhar a Nasdaq. Esta figura é publicada aqui nasdaqomx / technology /
Um bom artigo que descreve o estado do HFT (em 2018) e oferece algumas amostras de soluções de hardware que tornam possível o uso de nanosegundos: as ruas de parede precisam de velocidade de negociação: a era de nanosegundos.
Com a corrida pela menor "latência" continuando, alguns participantes do mercado estão falando sobre picossegundos - trilhões de segundo.
EDIT: Como Nicholas mencionou gentilmente:
O link menciona uma empresa, a Fixnetix, que pode "preparar um comércio" em 740ns (ou seja, o tempo de um evento de entrada ocorre a uma ordem que está sendo enviada).
Para o que vale a pena, o produto de mensagens FTL da TIBCO é sub-500 ns para dentro de uma máquina (memória compartilhada) e alguns micro segundos usando RDMA (Remote Direct Memory Access) dentro de um data center. Depois disso, a física se torna a principal parte da equação.
Então, essa é a velocidade com que os dados podem ser obtidos a partir do feed para o aplicativo que toma decisões.
Pelo menos um sistema reivindicou.
30ns mensagens interthread, que provavelmente é um benchmark tweaked up, então qualquer um que fala sobre números mais baixos está usando algum tipo de CPU mágica.
Uma vez que você está no aplicativo, é apenas uma questão de quão rápido o programa pode tomar decisões.
Hoje em dia, o tic-to-trade de um dígito em microssegundos é a barra para empresas HFT competitivas. Você deve poder fazer dígitos únicos altos usando apenas o software. Então & lt; 5 usec com hardware adicional.
O comércio de alta freqüência ocorreu pelo menos desde 1999, depois que a Bolsa de Valores dos EUA (SEC) autorizou as trocas eletrônicas em 1998. Na virada do século 21, os negócios da HFT tiveram um tempo de execução de vários segundos, enquanto que até 2018 isso diminuiu em milissegundos e até mesmo em microssegundos.
Nunca será inferior a alguns microsegundos, devido ao limite de velocidade de em-w / luz, e apenas um número sortudo, que deve estar em menos de um quilômetro de distância, pode até sonhar em aproximar-se disso.
Além disso, não há codificação, para alcançar essa velocidade, você deve se tornar físico ... (o cara com o artigo com o interruptor 300ns, que é apenas a latência adicional desse switch!, Igual a 90m de viagem através de um óptico e um pouco menos em cobre)

Ultra-Low Latency Trading.
A latência ultra baixa é a chave para ganhar o seu comércio pelo preço que deseja antes do movimento do preço das ações. Isso é verdade se você é um comerciante de alta freqüência, um criador de mercado ou um comerciante de arbitragem estatística.
Os sistemas de negociação algorítmica usam técnicas como a co-localização, as redes de caminho mais curtas e, cada vez mais, interfaces Ethernet 10G e tecnologias de matriz de portas programáveis ​​de campo (FPGA), a fim de minimizar a latência e obter uma vantagem competitiva. As tecnologias FPGA de baixa latência - muitas vezes chamadas de dispositivos lógicos programáveis ​​- são inestimáveis ​​na competição no primeiro nível. O New Wave DV oferece dispositivos programáveis ​​personalizados para suas necessidades comerciais de baixa latência.
A tecnologia de dispositivo programável da New Wave DV dá aos nossos clientes a vantagem que faz a diferença entre ganhar o comércio e assistir alguém ganhar. É por isso que os principais nomes nos mercados financeiros confiam em nossos produtos. Entre em contato para a tecnologia de negociação de latência ultra baixa que você precisa.
Como funcionam os dispositivos lógicos programáveis ​​para o comércio de alta freqüência?
Um sistema de negociação analisa dados de mercado de múltiplas bolsas de valores, usa estratégias de negociação financeira para encontrar oportunidades de negociação e usa uma interface de latência ultra baixa para obter pedidos na fila comercial primeiro.
Para reduzir a latência, é necessário empurrar a tomada de decisão em negociações para a placa de interface de rede (NIC), o que alivia a necessidade de envolver o processador principal do sistema, o que pode causar atrasos indesejáveis ​​no tempo de resposta. Este processamento em rede (onde o processamento ocorre o mais próximo possível da interface de rede) é essencial para o design de um sistema de negociação de latência verdadeiramente ultra-baixo.
Benefícios da tecnologia FPGA Custom Low Latency da New Wave DV.
Com base na tecnologia FPGA de baixa latência, nossa tecnologia de negociação de baixa latência oferece inúmeras vantagens.
Executar negociações em um FPGA de Nova Onda DV localizado perto da interface física da rede elimina as latências causadas pelo barramento host, o processador host e o sistema operacional. Isso reduz drasticamente o tempo de resposta da negociação. Nossos FPGAs de baixa latência fornecem desempenho de velocidade de fio, permitindo a execução quase instantânea da parte do algoritmo que detecta e atua sobre oportunidades de negociação antes que outros percebam a oportunidade. Nossos FPGAs podem ser reprogramados durante a operação, permitindo que os parâmetros e algoritmos sejam alterados e atualizados e mantendo você à frente da concorrência. As FPGA de Nova Wave DV são excelentes em processamento paralelo, o que lhes permite atuar em vários negócios simultaneamente. Nossos FPGAs de baixa latência podem incluir uma estrutura de desenvolvimento que encurte o ciclo de desenvolvimento para os usuários e os permite concentrar-se no desenvolvimento de seus sistemas e algoritmos proprietários. Cada FPGA da New Wave Design & amp; A verificação é um dispositivo de lógica programável personalizado; Vamos projetar seu dispositivo programável para atender às suas necessidades e superar sua concorrência.
Entre em contato com New Wave DV para Soluções de Negociação de Latência Ultra-Baixa.
O New Wave DV fornece os cartões FPGA de 10 G de ultra-baixa latência da mais alta classe, com uma estrutura de desenvolvimento de aplicativos fácil de usar. Nossa experiência em tecnologia de baixa latência comercial vem de anos de fornecer soluções para os mercados financeiros. Entregamos a tempo e orçamento em uma indústria onde cada segundo e cada centavo faz ou quebra um acordo.
Entre em contato com New Wave DV para tecnologia FPGA de alta performance e ultra baixa latência. Ou, navegue nos nossos produtos para encontrar a solução que você precisa.

Sistemas de negociação de baixa latência
Cambridge, Reino Unido e ndash; 23 de junho de 2018 & ndash; A Argon Design, uma empresa de serviços de design especializada em sistemas digitais complexos, anunciou hoje que desenvolveu um sistema de negociação financeira de baixa latência para uma casa de negociação proprietária fazendo arbitragem de latência em uma das principais bolsas nas Américas.
A plataforma de negociação completa que inclui funções de ingesta de dados de mercado em tempo real através de suporte a algoritmos para colocação de pedidos baseada em FIX foi atualizada em maio de 2018. Ele baseia-se nos resultados inovadores que o Argon anunciou em setembro de 2018 para o comércio de alto desempenho usando um projeto híbrido de FPGA e Tecnologias x86. Isso combina os caminhos rápidos implementados no FPGA para dar respostas de tick-to-trade de nível de nanosegundo a eventos-chave, juntamente com a configuração de oportunidade, determinação de parâmetros e gerenciamento de sistema em um servidor x86 de alto desempenho.
O melhor hardware de raça compreende um servidor Supermicro Hyper-Speed ​​com processadores Dual Intel Xeon E5 montados e fornecidos pela Bios IT, bem como um interruptor Arista 7124FX com Stratix V FPGA integrado.
A lógica FPGA usa uma série de técnicas de otimização desenvolvidas pelo Argon para maximizar a vantagem de velocidade. Estes incluem análise em linha, antecipação, inferência e arbitragem de gateway. Para alimentar as várias técnicas de inferência, o FPGA inclui lógica complexa para construir e manter cadernos e estatísticas. A análise de FAST / FIX é feita em no máximo 64ns e a compilação de livro de pedidos é completada em 32ns. Para as interfaces de rede de latência mais baixas, o sistema usa Tamba Networks & rsquo; latência terminal 1G MAC.
O parceiro gerente da casa de comércio comentou: "À medida que as trocas se tornam mais deterministas, é importante ter uma plataforma que ofereça vantagem de velocidade, bem como estratégias comerciais inteligentes. O sistema Argon nos deu essa vantagem".
Steve Barlow, CTO of Argon Design, comentou: "A negociação de alto desempenho continua a ser ativa em todos os mercados mundiais. Como provavelmente se tornará mais nicho, a vitória precisará de acesso a tecnologias de alto desempenho e habilidades para selecionar e montar as peças necessárias. Em Argon acreditamos no detalhe de engenharia especializada e ndash, cada cliente é diferente e, portanto, desenvolvemos sistemas personalizados que dão a vantagem vital ".
O Argon Design foi fundado em 2009 e atua no coração do renomeado Cambridge Technology Cluster com acesso aos mercados & rsquo; inteligência principal. No setor de comércio financeiro, o Argon Design auxilia equipes internas, fornecendo habilidades especializadas ou recursos adicionais para projetos, bem como projetos completos completos em áreas como:
Arquitetura heterogênea de sistemas de hardware e software Design e produção de dispositivos Desenvolvimento / programação baseada em FPGA Projeto de hardware e software de processador de vários núcleos usando Tilera, Intel e outros Processamento de rede de desenvolvimento / programação de GPU e OpenCL.

Você melhor conhece sua terminologia de negociação de alta freqüência.
O aumento do interesse dos investidores na negociação de alta freqüência (HFT) é importante para os profissionais da indústria atuarem com a terminologia HFT. Uma série de termos HFT têm suas origens na rede de computadores / indústria de sistemas, o que é de se esperar, uma vez que a HFT é baseada em arquitetura de computador incrivelmente rápida e software de última geração. Nós discutimos brevemente abaixo de 10 termos principais de HFT que acreditamos serem essenciais para obter uma compreensão do assunto.
Colocação.
Localizando computadores pertencentes a empresas HFT e comerciantes proprietários nas mesmas instalações onde os servidores de um computador da troca estão alojados. Isso permite que as empresas HFT acessem os preços das ações uma fração de segundo antes do resto do público investidor. A co-localização tornou-se um negócio lucrativo para as trocas, que cobram às empresas HFT milhões de dólares pelo privilégio de "acesso de baixa latência".
Como Michael Lewis explica em seu livro "Flash Boys", a enorme demanda de co-localização é uma das principais razões pelas quais algumas bolsas de valores expandiram substancialmente seus centros de dados. Enquanto o antigo prédio da Bolsa de Valores de Nova York ocupava 46 mil pés quadrados, o centro de dados NYSE Euronext em Mahwah, Nova Jersey, é quase nove vezes maior, com 398 000 pés quadrados.
Flash Trading.
Um tipo de negociação de HFT em que uma troca irá "piscar" informações sobre compra e venda de pedidos de participantes do mercado para empresas HFT por algumas frações de segundo antes de a informação ser disponibilizada ao público. O comércio instantâneo é controverso porque as empresas da HFT podem usar esta vantagem de informações para negociar antes das ordens pendentes, o que pode ser interpretado como a execução da frente.
O senador dos Estados Unidos, Charles Schumer, havia instado a Comissão de Valores Mobiliários em julho de 2009 a proibir o comércio flash, dizendo que criou um sistema de duas camadas onde um grupo privilegiado recebeu tratamento preferencial, enquanto os investidores de varejo e institucionais foram colocados em desvantagem injusta e privados de um preço justo para suas transações.
O tempo decorrido a partir do momento em que um sinal é enviado para o recibo. Uma vez que a menor latência é igual à velocidade mais rápida, os comerciantes de alta freqüência gastam pesadamente para obter o hardware, o software e as linhas de dados mais rápidos do computador, de modo a executar ordens o mais rápido possível e ganhar uma vantagem competitiva na negociação.
O maior determinante da latência é a distância que o sinal tem para viajar ou o comprimento do cabo físico (geralmente fibra óptica) que transporta dados de um ponto para outro. Uma vez que a luz no vácuo viaja a 186.000 milhas por segundo ou 186 milhas por minuto, uma empresa HFT com seus servidores co-localizados dentro de uma troca teria uma latência muito menor - e, portanto, uma vantagem comercial - do que uma empresa rival localizada a quilômetros de distância .
Curiosamente, os clientes de co-localização de uma troca recebem a mesma quantidade de comprimento do cabo independentemente de onde estão localizados dentro das instalações de troca, de modo a garantir que tenham a mesma latência.
Rebates de liquidez.
A maioria das trocas adotou um "modelo criador de fabricantes" para subsidiar a provisão de liquidez de ações. Neste modelo, os investidores e os comerciantes que colocam ordens limitadas geralmente recebem um pequeno desconto da bolsa após a execução de suas ordens, porque são considerados como tendo contribuído para a liquidez no estoque, ou seja, são "fabricantes" de liquidez.
Por outro lado, aqueles que colocam ordens de mercado são considerados "compradores" de liquidez e são cobrados uma taxa modesta pela troca por suas ordens. Embora os descontos sejam tipicamente frações de um centavo por ação, eles podem somar valores significativos sobre os milhões de ações negociadas diariamente por comerciantes de alta freqüência. Muitas empresas HFT empregam estratégias de negociação especificamente projetadas para capturar o máximo possível de descontos de liquidez.
Motor correspondente.
O algoritmo de software que forma o núcleo do sistema de comércio de uma troca e combina continuamente com ordens de compra e venda, uma função anteriormente realizada por especialistas no setor de comércio. Uma vez que o motor de correspondência corresponde a compradores e vendedores para todas as ações, é de vital importância para assegurar o bom funcionamento de uma troca. O motor correspondente reside nos computadores da troca e é a principal razão pela qual as empresas HFT tentam estar tão perto dos servidores de troca quanto possível.
Refere-se à tática de ingresso em pequenos pedidos comercializáveis ​​- geralmente para 100 ações - para conhecer grandes encomendas ocultas em piscinas ou trocas escuras. Enquanto você consegue pensar em fazer ping como sendo análogo a um navio ou submarino que envia sinais de sonar para detectar obstruções próximas ou vasos inimigos, no contexto HFT, o ping é usado para encontrar "presas" escondidas.
Veja como - as empresas de compra usam sistemas de negociação algorítmica para dividir grandes encomendas em mais pequenos e alimentá-los firmemente no mercado, de modo a reduzir o impacto no mercado de grandes pedidos. Para detectar a presença de grandes encomendas, as empresas HFT colocam ofertas e oferece em lotes de 100 partes para cada estoque listado.
Uma vez que uma empresa obtém um "ping" (ou seja, a pequena ordem do HFT é executada) ou uma série de pings que alertam o HFT para a presença de uma grande ordem de compra, pode se envolver em uma atividade comercial predatória que garanta um risco quase - lucro livre à custa do comprador, que acabará recebendo um preço desfavorável por sua grande ordem. Pinging foi comparado a "baiting" por alguns jogadores influentes do mercado, já que seu único objetivo é atrair instituições com grandes pedidos para revelar sua mão.
Ponto de presença.
O ponto em que os comerciantes se conectam a uma troca. Para reduzir a latência, o objetivo das empresas HFT é chegar o mais próximo possível do ponto de presença. Veja também "Co-localização".
Negociação Predatória.
Práticas de negociação empregadas por alguns comerciantes de alta freqüência para fazer lucros quase sem risco à custa dos investidores. No livro de Lewis, a troca de IEX, que busca combater alguns dos mais astutos HFT, identifica três atividades que constituem comércio predatório:
"Arbitragem de mercado lento" ou "arbitragem de latência", em que um comerciante de alta freqüência arbitra diferenças de preços de ações entre várias trocas. "Electronic front running", que envolve uma corrida da empresa HFT antes de uma grande ordem do cliente em uma troca, acumulando todas as ações oferecidas em várias outras trocas (se é uma ordem de compra) ou acertando todas as licitações (se for uma ordem de venda), e depois virar e vendê-los (ou comprá-los) do cliente e embolsar a diferença. "Rebate arbitrage" envolve a atividade HFT que tenta capturar descontos de liquidez oferecidos pelas trocas sem realmente contribuir para a liquidez. Veja também "Reembolsos de liquidez".
Processador de informações de valores mobiliários.
A tecnologia usada para coletar cotações e trocar dados de diferentes intercâmbios, reunir e consolidar esses dados e divulgar continuamente cotações e negócios de preços em tempo real para todos os estoques. O SIP calcula o National Best Bid and Offer (NBBO) para todas as ações, mas devido ao grande volume de dados que tem para lidar, tem um período de latência finita.
A latência de um SIP no cálculo do NBBO é geralmente superior à das empresas HFT (por causa dos computadores mais rápidos e co-localização), e essa diferença de latência - estimada por Lewis ocasionalmente atingir até 25 milissegundos - isso é no centro da atividade predatória de HFT. Nasdaq OMX Group e NYSE Euronext executam cada um SIP em nome das 11 bolsas nos EUA.
Smart Routers.
Tecnologia que determina a que ordens ou trocas são enviadas. Os roteadores inteligentes podem ser programados para enviar peças de grandes pedidos (depois que eles são quebrados por um algoritmo de negociação) para obter uma execução econômica econômica. Um roteador inteligente como um roteador econômico seqüencial pode direcionar uma ordem para um pool escuro e, em seguida, para uma troca (se não for executada no primeiro), ou para uma troca onde é mais provável que receba um desconto de liquidez.
The Bottom Line.
HFT tem feito ondas e penas ruffling (para usar uma metáfora mista) nos últimos anos. Mas, independentemente da sua opinião sobre o comércio de alta freqüência, familiarizar-se com esses termos HFT deve permitir que você melhore sua compreensão sobre esse tema controverso.