Serviço MQL5 VPS lançado em São Paulo!
Latência menor que 1ms pras corretoras? SHOW !!!!!
Até o momento o melhor que eu vinha conseguindo era 8ms na Amazon!
Ainda não dá pra "HFT" mas já vai dar pra fazer um "MFT", kkk!
A partir de agora não vai adiantar diminuir mais a latência, pois o gargalo passou a ser o delay na execução dos eventos MQL5: eles só são verificados a intervalos de no mínimo 15.6 ms e aparentemente não adianta alterar a configuração na API do Windows que diminui esse período - vejam aqui. Esse intervalo mínimo de verificação ainda é um grande obstáculo pra se negociar em alta frequência no MT5. Há alguma intenção da Metaquotes de rever isso em versões futuras?
Latência menor que 1ms pras corretoras? SHOW !!!!!
Até o momento o melhor que eu vinha conseguindo era 8ms na Amazon!
Ainda não dá pra "HFT" mas já vai dar pra fazer um "MFT", kkk!
A partir de agora não vai adiantar diminuir mais a latência, pois o gargalo passou a ser o delay na execução dos eventos MQL5: eles só são verificados a intervalos de no mínimo 15.6 ms e aparentemente não adianta alterar a configuração na API do Windows que diminui esse período - vejam aqui. Esse intervalo mínimo de verificação ainda é um grande obstáculo pra se negociar em alta frequência no MT5. Há alguma intenção da Metaquotes de rever isso em versões futuras?
Olá
Trader_Patinhas, obrigado por
compartilhar, nos testes que fiz esse é um valor de referência, acredito que em média o valor ficará maior, embora provavelmente abaixo de
5ms.
Concordo com você em termos de gargalo, e no meu entender um dos pontos fortes dessa solução de VPS da MetaQuotes é que o servidor é muito rápido,
provavelmente por ser compartilhado e administrado por uma aplicação centralizada, que faz a gestão de várias plataformas. No meu caso
específico, com algoritmos mais "pesados", a performance e relação custo benefício é excelente. Entretanto, o ponto mais crítico
dessa solução me parece a perda de controle, principalmente em situações de exceção.
Vamos acompanhar para ver como se comporta no mercado brasileiro, e a ideia dessa thread é justamente ajudar nesse processo.
Sds.,
Rogério
Figurelli
Olá
Trader_Patinhas, obrigado por
compartilhar, nos testes que fiz esse é um valor de referência, acredito que em média o valor ficará maior, embora provavelmente abaixo
de 5ms.
Concordo com você em termos de gargalo, e no meu entender um dos pontos fortes dessa solução de VPS da MetaQuotes é que o servidor é muito rápido,
provavelmente por ser compartilhado e administrado por uma aplicação centralizada, que faz a gestão de várias plataformas. No meu
caso específico, com algoritmos mais "pesados", a performance e relação custo benefício é excelente. Entretanto, o ponto mais
crítico dessa solução me parece a perda de controle, principalmente em situações de exceção.
Vamos acompanhar para ver como se comporta no mercado brasileiro, e a ideia dessa thread é justamente ajudar nesse processo.
Sds.,
Rogério
Figurelli
@Rogerio Figurelli, fiquei intrigado: o que você quer dizer com " a perda de controle, principalmente em situações de exceção" ?
Olá
Trader_Patinhas, estou me referindo
ao fato de que, na prática, a solução da MetaQuotes é fechada, ou seja, o usuário não tem acesso direto ao VPS, ou seja, é diferente
de você contratar um VPS aberto e fazer todo serviço de instalação e configuração do MT5.
No caso temos um serviço remoto, onde todo o espelhamento do EA, indicadores, sinais, setup, etc., é feito pelo sistema contratado,
provavelmente de forma automatizada. É uma ideia inovadora, até onde eu saiba, mas ao mesmo tempo tudo que o cliente tem do seu lado são botões
para habilitar e desabilitar seus recursos, o que, no meu entender, diminui o controle que você tem, se comparado com um VPS aberto.
Em outras palavras, é o mesmo que optar entre pilotagem manual ou automática, com vantagens e desvantagens similares. Se você está
operando com baixa exposição, essa perda de controle pode não ser tão impactante, mas se estiver com alta exposição, e algo der errado (as
exceções), a adrenalina vai ser alta, e nesses casos um VPS aberto oferece um controle manual nas mãos do cliente, a ponto de até mesmo ter
controle para remover o EA, fechar a plataforma ou até encerrar a instância de VPS, em último caso.
Note que não é uma crítica ao sistema proposto e existente, apenas uma análise comparativa, pois existe uma vantagem dessa falta de controle
que é o serviço ser executado de forma padronizada e automatizada, o que, no médio e longo prazo, em tese, deve minimizar o impacto ou eliminar
as situações de exceção, deixando todo o sistema mais robusto.
Espero ter sido mais claro agora, senão é só perguntar de novo.
Sds.,
Rogério Figurelli
Olá
Trader_Patinhas, estou me
referindo ao fato de que, na prática, a solução da MetaQuotes é fechada, ou seja, o usuário não tem acesso direto ao VPS, ou seja, é
diferente de você contratar um VPS aberto e fazer todo serviço de instalação e configuração do MT5.
No caso temos um serviço remoto, onde todo o espelhamento do EA, indicadores, sinais, setup, etc., é feito pelo sistema contratado,
provavelmente de forma automatizada. É uma ideia inovadora, até onde eu saiba, mas ao mesmo tempo tudo que o cliente tem do seu lado são
botões para habilitar e desabilitar seus recursos, o que, no meu entender, diminui o controle que você tem, se comparado com um VPS
aberto.
Em outras palavras, é o mesmo que optar entre pilotagem manual ou automática, com vantagens e desvantagens similares. Se você está
operando com baixa exposição, essa perda de controle pode não ser tão impactante, mas se estiver com alta exposição, e algo der errado
(as exceções), a adrenalina vai ser alta, e nesses casos um VPS aberto oferece um controle manual nas mãos do cliente, a ponto de até mesmo
ter controle para remover o EA, fechar a plataforma ou até encerrar a instância de VPS, em último caso.
Note que não é uma crítica ao sistema proposto e existente, apenas uma análise comparativa, pois existe uma vantagem dessa falta de
controle que é o serviço ser executado de forma padronizada e automatizada, o que, no médio e longo prazo, em tese, deve minimizar o
impacto ou eliminar as situações de exceção, deixando todo o sistema mais robusto.
Espero ter sido mais claro agora, senão é só perguntar de novo.
Sds.,
Rogério Figurelli
Muito obrigado pela resposta. Vc foi claríssimo.
Atualmente eu uso servidor da Amazon e, de fato, tenho um nível de controle bem mais robusto. Se o robô travar, posso fechar a plataforma. Se a plataforma travar, posso dar kill no processo pelo task manager do Windows e, em último caso, se o Windows também travar, posso forçar shutdown na instância.
No caso do VPS, nessas situações ficamos na dependência da interface da Metaquotes, né?
Nesses casos é sempre bom ter a mão um cliente MT5 instalado na máquina local e um scriptzinho que cancela todas as ordens pendentes e zera todas as posições abertas. É o meu "botão de pânico"!
Enfim, quando fazemos algotrading, já estamos nos expondo a riscos naturais de mercado que são bem maiores que esses riscos de natureza "tecnológica". Por exemplo, se rolar um "Brumadinho" num momento em que vc estiver com a mão cheia de contratos futuros de índice, não haverá stop-loss que segure o prejuízo! Então tudo é uma questão de dosar a exposição e gerenciar risco.
Muito obrigado pela resposta. Vc foi claríssimo.
Atualmente eu uso servidor da Amazon e, de fato, tenho um nível de controle bem mais robusto. Se o robô travar, posso fechar a plataforma. Se a plataforma travar, posso dar kill no processo pelo task manager do Windows e, em último caso, se o Windows também travar, posso forçar shutdown na instância.
No caso do VPS, nessas situações ficamos na dependência da interface da Metaquotes, né?
Nesses casos é sempre bom ter a mão um cliente MT5 instalado na máquina local e um scriptzinho que cancela todas as ordens pendentes e zera todas as posições abertas. É o meu "botão de pânico"!
Enfim, quando fazemos algotrading, já estamos nos expondo a riscos naturais de mercado que são bem maiores que esses riscos de natureza "tecnológica". Por exemplo, se rolar um "Brumadinho" num momento em que vc estiver com a mão cheia de contratos futuros de índice, não haverá stop-loss que segure o prejuízo! Então tudo é uma questão de dosar a exposição e gerenciar risco.
Perfeito
Trader_Patinhas, talvez o melhor termo
para essa solução não seja VPS e sim VPM ou Virtual Private Metatrader!
Seja como for, vejo como vantagens competitivas do VPS Metatrader:
- capacidade da máquina disponibilizada (ver o gráfico de CPU remoto para maiores detalhes, sendo que para a máquina de São Paulo que testei tinha 32 núcleos, algo que seria um valor bem superior a 10$ (USD) mensal em qualquer outra solução);
- simplicidade e segurança para levantar várias soluções em paralelo, por exemplo no caso de uma basket com dezenas de contas e robôs rodando em paralelo;
- capacidade de rapidamente colocar um robô próximo a qualquer broker MT5, e portanto operando com baixa latência, em todo mundo, o que permite até mesmo criar sistemas distribuídos e inteligentes para vários tipos de análise e arbitragem, e com custos muito competitivos.
Ou seja, é uma solução que apesar de perder na parte de controle, ganha em vários outros pontos que considero muito relevantes.
Sds.,
Rogério Figurelli
Perfeito Trader_Patinhas, talvez o melhor termo para essa solução não seja VPS e sim VPM ou Virtual Private Metatrader!
Seja como for, vejo como vantagens competitivas do VPS Metatrader:
- capacidade da máquina disponibilizada (ver o gráfico de CPU remoto para maiores detalhes, sendo que para a máquina de São Paulo que testei tinha 32 núcleos, algo que seria um valor bem superior a 10$ (USD) mensal em qualquer outra solução);
- simplicidade e segurança para levantar várias soluções em paralelo, por exemplo no caso de uma basket com dezenas de contas e robôs rodando em paralelo;
- capacidade de rapidamente colocar um robô próximo a qualquer broker MT5, e portanto operando com baixa latência, em todo mundo, o que permite até mesmo criar sistemas distribuídos e inteligentes para vários tipos de análise e arbitragem, e com custos muito competitivos.
Ou seja, é uma solução que apesar de perder na parte de controle, ganha em vários outros pontos que considero muito relevantes.
Sds.,
Rogério Figurelli
Concordo. As vantagens são notáveis, pois no VPS, o consumo de cpu e de memória com sistema operacional, device-drivers dos demais artefatos de infraestrutura de software pode ser bastante reduzido, pois, além de só precisar existir e ficar habilitada a infraestrutura mínima imprescindível para um cliente MT5 funcionar, o consumo dessa infraestrutura reduzida ainda pode ser diluído entre um grande número de instâncias de cliente MT5, sendo que a divisão dos recursos entre as instâncias pode ser bastante eficiente, na medida em que, a cada momento, instâncias que demandarem mais recursos poderão usar os recursos ociosos daquelas que estiverem "em repouso", possibilitando um aproveitamento otimizado dos 32 núcleos (na prática N instâncias concorrentes conseguirão usar muito mais que apenas 1/N dos recursos).
Aproveito para expor uma outra dúvida que me preocupa ao pensar em migrar meus robôs para o VPS:
Além de ler arquivos, meus robôs também GRAVAM arquivos. Os maiores desses arquivos são logs diários contendo informação necessária para depurar todos os detalhes das análises e das tomadas de decisão, e também para servir de massa de treinamento para atualizar os modelos preditivos periodicamente com dados mais recentes. Eu gravo esses arquivos em um formato binário, para economizar espaço, mas mesmo assim alguns deles chegam a dezenas de MB, pois as análises e tomadas de decisão são feitas a cada 125 ms.
No VPS o único tipo de saída de dados seria o log da interface? Esse log suporta saída em formato binário? Posso alterar pra gravar em formato texto, mas nesse caso o tamanho dos arquivos diários deverá ir pra casa das centenas de MB. Enviar arquivos desse porte por web service também seria meio complicado (deve haver algum limite de uso de rede no VPS, não?)
Concordo. As vantagens são notáveis, pois no VPS, o consumo de cpu e de memória com sistema operacional, device-drivers dos demais artefatos de infraestrutura de software pode ser bastante reduzido, pois, além de só precisar existir e ficar habilitada a infraestrutura mínima imprescindível para um cliente MT5 funcionar, o consumo dessa infraestrutura reduzida ainda pode ser diluído entre um grande número de instâncias de cliente MT5, sendo que a divisão dos recursos entre as instâncias pode ser bastante eficiente, na medida em que, a cada momento, instâncias que demandarem mais recursos poderão usar os recursos ociosos daquelas que estiverem "em repouso", possibilitando um aproveitamento otimizado dos 32 núcleos (na prática N instâncias concorrentes conseguirão usar muito mais que apenas 1/N dos recursos).
Aproveito para expor uma outra dúvida que me preocupa ao pensar em migrar meus robôs para o VPS:
Além de ler arquivos, meus robôs também GRAVAM arquivos. Os maiores desses arquivos são logs diários contendo informação necessária para depurar todos os detalhes das análises e das tomadas de decisão, e também para servir de massa de treinamento para atualizar os modelos preditivos periodicamente com dados mais recentes. Eu gravo esses arquivos em um formato binário, para economizar espaço, mas mesmo assim alguns deles chegam a dezenas de MB, pois as análises e tomadas de decisão são feitas a cada 125 ms.
No VPS o único tipo de saída de dados seria o log da interface? Esse log suporta saída em formato binário? Posso alterar pra gravar em formato texto, mas nesse caso o tamanho dos arquivos diários deverá ir pra casa das centenas de MB. Enviar arquivos desse porte por web service também seria meio complicado (deve haver algum limite de uso de rede no VPS, não?)
Olá Trader_Patinhas, solução: ter um outro VPS padrão para espelhar os logs por socket ;-)
Falando sério agora, sem dúvida isso não faria lógica, e realmente até onde eu também saiba, o acesso é apenas através dos logs do terminal e expert.
Entretanto esse seu problema me parece similar ao de qualquer empresa com sistemas mais pesados, rodando em servidor blade e com alta performance e nesse caso me parece o mais apropriado os seus robôs fazerem tudo de forma autônoma, e você utilizar o socket apenas para gerar alarmes e os logs (também por socket) apenas para exibir resultados específicos ou relacionados.
Tenho alguns cases de clientes e alguns sistemas bem pesados na cloud processando bigdata e utilizando vários módulos e arquiteturas, como por exemplo baseadas em hadoop, com vários robôs analisando dados em tempo real e cruzando informações em paralelo, onde faço justamente isso, mantendo eles com autonomia em 100% das análises e operações, e onde as pessoas fazem apenas o reconhecimento de alarmes e análise de logs específicos, requisitados por socket.
Note que essa arquitetura também é muito usada para RPA Cognitivo, principalmente quando envolve análise de dados não estruturados como imagens ou até mesmo streaming, o que é bem mais pesado, pelo menos em termos de performance de redes neurais artificiais, que a "simplicidade" de analisar "apenas" preços, volumes, fitas, books, etc., com dados estruturados e limitados.
Na prática, acredito que essa é a tendência, ou seja, as máquinas fazendo tudo cada vez mais com o mínimo de supervisão (como processar logs em tempo real), mas com o máximo de visibilidade, também em tempo real, apenas sobre alarmes e não conformidades.
Mas essa é minha visão e respeito qualquer outra arquitetura, principalmente se gerar roi alpha, que ao fim e ao cabo é o objetivo principal de investir em uma estrutura assim.
Sds.,
Rogério Figurelli
Olá Trader_Patinhas, solução: ter um outro VPS padrão para espelhar os logs por socket ;-)
Falando sério agora, sem dúvida isso não faria lógica, e realmente até onde eu também saiba, o acesso é apenas através dos logs do terminal e expert.
Entretanto esse seu problema me parece similar ao de qualquer empresa com sistemas mais pesados, rodando em servidor blade e com alta performance e nesse caso me parece o mais apropriado os seus robôs fazerem tudo de forma autônoma, e você utilizar o socket apenas para gerar alarmes e os logs (também por socket) apenas para exibir resultados específicos ou relacionados.
Tenho alguns cases de clientes e alguns sistemas bem pesados na cloud processando bigdata e utilizando vários módulos e arquiteturas, como por exemplo baseadas em hadoop, com vários robôs analisando dados em tempo real e cruzando informações em paralelo, onde faço justamente isso, mantendo eles com autonomia em 100% das análises e operações, e onde as pessoas fazem apenas o reconhecimento de alarmes e análise de logs específicos, requisitados por socket.
Note que essa arquitetura também é muito usada para RPA Cognitivo, principalmente quando envolve análise de dados não estruturados como imagens ou até mesmo streaming, o que é bem mais pesado, pelo menos em termos de performance de redes neurais artificiais, que a "simplicidade" de analisar "apenas" preços, volumes, fitas, books, etc., com dados estruturados e limitados.
Na prática, acredito que essa é a tendência, ou seja, as máquinas fazendo tudo cada vez mais com o mínimo de supervisão (como processar logs em tempo real), mas com o máximo de visibilidade, também em tempo real, apenas sobre alarmes e não conformidades.
Mas essa é minha visão e respeito qualquer outra arquitetura, principalmente se gerar roi alpha, que ao fim e ao cabo é o objetivo principal de investir em uma estrutura assim.
Sds.,
Rogério Figurelli
Concordo que a arquitetura final (ambiente de produção) pode (e deve!) ser assim como vc falou: as grandes massas de dados sendo processadas internamente e somente informações curtas e resumidas sendo enviadas para fora.
É que no momento estou em fase de desenvolvimento e testes e nessa fase há uma necessidade de depuração detalhada que não dá pra ser automatizada (até porque nada está confiável ainda). Como se tratam de operações de "micro-scalping" muito rápidas e curtas, fatores como latência, liquidez e filas no book, slippage, etc. são decisivos para um resultado positivo e somente testes em conta real são confiáveis (se os resultados de conta demo fossem reais eu já estaria bilionário! rsrs). Por exemplo, se eu tenho um modelo preditivo treinado que está apresentando excelente acurácia fora da amostra numa validação "walk-forward" e o robô que se baseia nele tem ótimos resultados na conta demo, mas toma prejuízo na conta real, eu preciso ter um log de tudo o que aconteceu (ticks + book) para poder compreender os fatores que levam ele a ter prejuízo mesmo entrando e saindo num timing que estava teoricamente correto na grande maioria das vezes, para daí tentar aprimorar o modelo preditivo e/ou o algoritmo de trading com base nessa nova compreensão.
Minha conclusão dessa nossa discussão é que precisarei manter o ambiente de desenvolvimento em um servidor convencional, mas provavelmente será vantajoso implantar o ambiente de produção num VPS da Metaquotes, pelas vantagens de latência e de desempenho versus custo.
Ainda me ocorreu mais uma pergunta: eu posso, dentro do VPS, gravar arquivos extensos no diretório /File, para depois, em horário de mercado fechado e algotrading desativado, enviar o conteúdo do arquivo para um web service externo? Em caso positivo, quais são os limites de armazenamento de arquivos e de consumo de rede? (não encontrei isso na documentação)
Minha conclusão dessa nossa discussão é que precisarei manter o ambiente de desenvolvimento em um servidor convencional, mas provavelmente será vantajoso implantar o ambiente de produção num VPS da Metaquotes, pelas vantagens de latência e de desempenho versus custo.
Olá Trader_Patinhas, ótima discussão por sinal, e espero que mais colegas participem e tragam suas experiências práticas utilizando o servidor em SP, o que certamente irá ajudar na melhoria para todos.
Quanto à conclusão, concordo totalmente, ainda mais nesse caso, e a vantagem competitiva está no uso como ambiente de produção. Em ambiente de desenvolvimento, quanto maior controle, melhor.
Ainda me ocorreu mais uma pergunta: eu posso, dentro do VPS, gravar arquivos extensos no diretório /File, para depois, em horário de mercado fechado e algotrading desativado, enviar o conteúdo do arquivo para um web service externo? Em caso positivo, quais são os limites de armazenamento de arquivos e de consumo de rede? (não encontrei isso na documentação)
Também não tenho essa resposta, e vou tentar descobrir, pois certamente deve existir alguma solução como um container, tipo docker, que limita para cada terminal o espaço em disco para evitar riscos de competir com o sistema.
Seja como for, recomendo manter um algoritmo de limpeza permanente, para não correr o risco de descobrir o limite no meio de uma posição de alta exposição.
Sds.,
Rogério Figurelli
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Você concorda com a política do site e com os termos de uso
Fórum de negociação, sistemas de negociação automatizados e testes de estratégias de negociação
MQL5 VPS service launched in Brazil São Paulo!
Rogerio Figurelli, 2019.07.26 08:29
Dear Aytugan Khafizov, congratulations for the initiative, I am translating below and will post in the forum in Portuguese.
"Serviço MQL5 VPS lançado em São Paulo!
Prezados Clientes,
Seguindo seus pedidos, lançamos o serviço de VPS em São Paulo, Brasil.
Nossos servidores VPS estão localizados no datacenter Equinix SP3, próximo aos servidores da BM&F/Bovespa (B3) e corretoras da bolsa brasileira.
Agora você pode hospedar seus robôs no VPS com latência menor que 1 milissegundo até sua corretora.
Consulte a página https://www.mql5.com/pt/vps para obter maiores detalhes.
Moderadores, por favor traduzam minha mensagem para o português."