Metodologia de teste de qualidade de dados - página 6
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Olá Rogério e Rodrigo.
A diferença de 30-40% entre os nossos testes e indicação de plataforma Tick volume de me chama também. As conclusões eu desenhar, em conexão com o meu post anterior :
Eu li seus posts anteriores onde você fala sobre o problema com o envio de cerca de negociação, mas, infelizmente, eu não entendo. Então eu não posso dar a minha opinião. Especialmente esta passagem :
Outro ponto muito relevante, fazendo uma associação do erro de ticks ao erro de leitura de lote de uma posição após uma ordem, é que se esse problema acontece com os ticks, será que na leitura do volume atual da posição após uma ordem executada não acontecem erros também?
Porque se existem atrasos na leitura da posição de volume de uma posição atual, como acontece com os preços (ainda mais com perda próxima a 40%), e sabe-se que a única forma de fechar um trade no MT5 é comprando uma operação contrária no mesmo volume, o risco de erro e perda de sincronismo será crítico pois a ordem contrária tem que ser precisamente o volume atual para haver um fechamento de posição.
O EA atual não testa a latência de execução das ordens e a correspondente latência de leitura atualizada do volume da posição atual, mas talvez essa seja mais uma coleta a ser feita futuramente nesse tópico para contribuir na medição e controle de qualidade dos dados do MT5 na BM&FBovespa.
P.S : Eu usei a conta Figurelli para testes, esta é uma conta demo, você também deve verificar se Ticks recebido em uma conta real são idênticos.
Olá Rogério e Rodrigo.
A diferença de 30-40% entre os nossos testes e indicação de plataforma Tick volume de me chama também. As conclusões eu desenhar, em conexão com o meu post anterior :
Eu li seus posts anteriores onde você fala sobre o problema com o envio de cerca de negociação, mas, infelizmente, eu não entendo. Então eu não posso dar a minha opinião. Especialmente esta passagem :
P.S : Eu usei a conta Figurelli para testes, esta é uma conta demo, você também deve verificar se Ticks recebido em uma conta real são idênticos.
Alain, vou tentar explicar novamente meu ponto de vista relacionado à negociação para maior entendimento (com uma versão em português e outra em inglês, para facilitar teu entendimento), pois considero ele muito relevante para toda a operação do MT5 na BM&FBovespa.
Em português: se detectamos perdas de ticks, provavelmente pela latência e/ou outros problemas relacionados à comunicação cliente/servidor (como você disse, não sabemos a razão real e talvez apenas a Corretora/MQ podem confirmar ou negar), não podemos também ter o mesmo problema para identificar o verdadeiro lote atual de qualquer posição aberta, uma vez que depois de enviar uma ordem, devemos confiar e esperar a resposta do servidor? Se assim for, o que acontece se precisamos fechar uma posição e não sabemos exatamente o tamanho do lote real da posição no servidor neste momento? Na minha opinião, temos um grande risco de perda de controle e aumento indesejável de posição, uma vez que a única maneira (até onde eu saiba) para um EA fechar uma posição no MT5 é enviar uma ordem contrária e com tamanho de lote preciso ao servidor.
In english: if we have tick loss, probably by latency and or any other client/server problems (as you said, we don't know the really reason, maybe just Broker/MQ can confirm or deny), can't we have also the same problems to identify the real lot of any open position, since after you send an order you must trust and wait the server answer? If so, what happens if we need to close a position and don't know exactly the real lot size in the server at this moment? In my opinion, we have a big risk of control loss and unwanted lot position increase, since the only way (as far as I know) to an EA close a position in MT5 is order send the right lot size to the server.
Bem, vou continuar em português, mas se não estiver claro por favor me avise que faço uma versão também.
Resumo da ópera: para mim, e acredito que para você e o Malacarne também, a perda de ticks é totalmente indesejável pois inviabiliza as estratégias automáticas, principalmente as que utilizam menor timeframe, e portanto deve ser resolvida. Mas ainda muito pior que isso, para não dizer mais catastrófico, é se a posição lida do servidor em relação ao lote real de uma posição sofrer também latência ou perda de informação como estamos vendo com os ticks, pois nesse caso o prejuízo financeiro pode ser sem limites e já não depende mais da estratégia.
figurelli : ...
In english: if we have tick loss, probably by latency and or any other client/server problems (as you said, we don't know the really reason, maybe just Broker/MQ can confirm or deny), can't we have also the same problems to identify the real lot of any open position, since after you send an order you must trust and wait the server answer? If so, what happens if we need to close a position and don't know exactly the real lot size in the server at this moment? In my opinion, we have a big risk of control loss and unwanted lot position increase, since the only way (as far as I know) to an EA close a position in MT5 is order send the right lot size to the server.
...É muito claro agora.Thank you for your time.
No entanto, não vejo qualquer ligação entre este problema Ticks e conhecimento do volume de uma posição. Você envia uma ordem (por exemplo, comprar 1,0 lote) depois que você receber um "recibo" e você sempre pode verificar o status da posição. Se há um problema nesse processo deve investigar para encontrar a fonte. Pode ser um problema de comunicação entre o cliente eo servidor, ou qualquer erro, mas nada até agora nenhuma evidência de ligação destes problemas. Pelo menos da minha parte não vejo nenhuma lógica.
É muito claro agora.Thank you for your time.
No entanto, não vejo qualquer ligação entre este problema Ticks e conhecimento do volume de uma posição. Você envia uma ordem (por exemplo, comprar 1,0 lote) depois que você receber um "recibo" e você sempre pode verificar o status da posição. Se há um problema nesse processo deve investigar para encontrar a fonte. Pode ser um problema de comunicação entre o cliente eo servidor, ou qualquer erro, mas nada até agora nenhuma evidência de ligação destes problemas. Pelo menos da minha parte não vejo nenhuma lógica.
Alain, antes de mais nada respeito tua posição, embora não concorde com ela.
Note que, sem dúvida são problemas independentes, não vejo qualquer relacionamento nos efeitos, apenas nas causas.
Ora, se temos problemas de comunicação entre cliente/servidor para Ticks (isso acredito que não restam dúvidas), não é lógico imaginar que possam acontecer problemas de comunicação cliente/servidor, principalmente em momentos críticos do mercado, justamente no momento de leitura do volume de uma posição atual após o envio de uma ordem de fechamento de posição?
E se essa premissa é verdadeira, e temos no MT5 funções internas que fazem o gerenciamento do fechamento de ordens de forma automática, da minha parte existe bastante lógica em estarmos atentos a esse problema.
Alain, antes de mais nada respeito tua posição, embora não concorde com ela.
Note que, sem dúvida são problemas independentes, não vejo qualquer relacionamento nos efeitos, apenas nas causas.
Ora, se temos problemas de comunicação entre cliente/servidor para Ticks (isso acredito que não restam dúvidas), não é lógico imaginar que possam acontecer problemas de comunicação cliente/servidor, principalmente em momentos críticos do mercado, justamente no momento de leitura do volume de uma posição atual após o envio de uma ordem de fechamento de posição?
E se essa premissa é verdadeira, e temos no MT5 funções internas que fazem o gerenciamento do fechamento de ordens de forma automática, da minha parte existe bastante lógica em estarmos atentos a esse problema.
A pergunta é aberta, vamos ver quando chegarmos respostas, eu espero.
Acabei de ver que alguns dados deste broker (conta demo) agora estão perdidos!
Plataforma de negociação MetaTrader Imagens
PETR4, H1, 2013/12/17
XP Investimentos CCTVM S / A, MetaTrader 5, Demo
temp_file_screenshot_3477.png
Acabei de ver que alguns dados deste broker (conta demo) agora estão perdidos!
É verdade, bem observado, e parece que está acontecendo só no PETR4 (no WINZ13 parece OK, ver meus gráficos abaixo).
WINZ13 (aparentemente OK)
https://www.mql5.com/en/charts/1187610/winz13-h1-xp-investimentos-cctvm-temp-file-screenshot-51886-png
PETR4 (sem os dados de ontem mas com os de hoje, 17/12, e 13/12)
https://www.mql5.com/en/charts/1187624/petr4-h1-xp-investimentos-cctvm-temp-file-screenshot-59155-png
É verdade, bem observado, e parece que está acontecendo só no PETR4 (no WINZ13 parece OK, ver meus gráficos abaixo).
WINZ13 (aparentemente OK)
https://www.mql5.com/en/charts/1187610/winz13-h1-xp-investimentos-cctvm-temp-file-screenshot-51886-png
PETR4 (sem os dados de ontem mas com os de hoje, 17/12, e 13/12)
https://www.mql5.com/en/charts/1187624/petr4-h1-xp-investimentos-cctvm-temp-file-screenshot-59155-png
Confirmo, o problema é apenas com PETR4.
Uma outra pergunta sobre nossos testes. Recebemos 28992 "oficial" ticks para PETR4 (seguindo Tick indicação Volume em MT5). Mas isso vem de um mercado centralizado não? Não é possível verificar quantos citação ter sido criado oficialmente para PETR4 (16.12.2013)?
Confirmo, o problema é apenas com PETR4.
Uma outra pergunta sobre nossos testes. Recebemos 28992 "oficial" ticks para PETR4 (seguindo Tick indicação Volume em MT5). Mas isso vem de um mercado centralizado não? Não é possível verificar quantos citação ter sido criado oficialmente para PETR4 (16.12.2013)?
http://www.bmfbovespa.com.br/download/BOLETINSDIARIOS/bdi_06_20131216.pdf
28.913 negócios (horário regular).
Fonte: Boletim Diário de Informações (BDI) - BM&F Bovespa (página B8)
http://www.bmfbovespa.com.br/download/BOLETINSDIARIOS/bdi_06_20131216.pdf
28,913 businesses (regular time).
Source: Daily Information Bulletin (BDI) - BM & F Bovespa (page B8)