Serviço MQL5 VPS lançado em São Paulo!

Para adicionar comentários, por favor Faça o login ou registrar
Rogerio Figurelli
Moderador
58472
Rogerio Figurelli  

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."


Trader_Patinhas
1117
Trader_Patinhas  
Rogerio Figurelli:

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?

Rogerio Figurelli
Moderador
58472
Rogerio Figurelli  
Trader_Patinhas:

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

Trader_Patinhas
1117
Trader_Patinhas  
Rogerio 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" ? 
Rogerio Figurelli
Moderador
58472
Rogerio Figurelli  
Trader_Patinhas:
@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

Trader_Patinhas
1117
Trader_Patinhas  
Rogerio 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

Olá @Rogerio 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.

Rogerio Figurelli
Moderador
58472
Rogerio Figurelli  
Trader_Patinhas:

Olá @Rogerio 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.

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

Trader_Patinhas
1117
Trader_Patinhas  
Rogerio 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?)

Rogerio Figurelli
Moderador
58472
Rogerio Figurelli  
Trader_Patinhas:

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

Trader_Patinhas
1117
Trader_Patinhas  
Rogerio 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)

 

Rogerio Figurelli
Moderador
58472
Rogerio Figurelli  
Trader_Patinhas:

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

12
Para adicionar comentários, por favor Faça o login ou registrar