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
https://www.mql5.com/ru/forum/341117 ainda é um problema atual
A última vez que verifiquei, este problema foi resolvido no corretor mencionado.
Caros desenvolvedores, por favor, respondam a seguinte pergunta sobre arquitetura. As informações são necessárias para uma aplicação em combate. Sem reivindicações.
Há dois limitadores com o mesmo preço e lotes diferentes. De que depende o pedido deles na seqüência de acionamento?
Tenho várias respostas a esta pergunta.
Se entendi corretamente, então, após modificar o preço de abertura, o Limitador é devidamente incorporado na lista de todos os Limitadores do servidor, ordenado pelo preço de abertura. Então a resposta à pergunta se resume a: ela está embutida no início da lista de pedidos com o mesmo preço ou no final?
A mesma pergunta não é sobre limites, mas sobre fichas. De que depende a ordem de acionamento de tomadas idênticas? É uma posição de identificação ou algo mais?
Deixe-me explicar como isto pode ajudar no combate. Por exemplo, eu tenho dois limitadores (ou tees de posição) no mesmo nível, mas com lotes diferentes. Se a execução do limite (tee) depender da última modificação, então posso aumentar o FillRate simplesmente modificando os limitadores em incrementos de lote ascendente.
Provavelmente, somente alguém que escreveu a implementação da parte correspondente do servidor MT5 sabe a resposta a esta pergunta.
trabalhar em conjunto com um corretor para encontrar o gargalo
Há dois limitadores com o mesmo preço e lotes diferentes. De que depende sua ordem na seqüência de acionamento?
Tenho várias respostas a esta pergunta.
Acho que a variante 4 foi usada na quarta. Ou seja, qualquer modificação moveu o pedido para o final da fila do nível de preço correspondente.
É como, abelhas versus mel?)
neste momento em particular nesta situação particular, é mutuamente benéfico e foi feito. uma rara coincidência.
Os pedidos TP em MT5 são notáveis, pois podemos investigar o FillRate (que parte do pedido é preenchida).
A análise de dezenas de milhares de tais pedidos mostrou que o FillRate depende muito do símbolo. Se um pacote de pedidos TP é acionado simultaneamente, então o FillRate diminui conforme o número do pedido na embalagem aumenta.
Outras nuances específicas também foram reveladas. Mas isto já está sendo discutido com o corretor.
A receita para aumentar o FillRate: combinar todos os mesmos carrapatos e limitadores em um limite MT5 comum.
Entretanto, estes dados são apenas um bônus para este tópico. O problema independente do corretor é que o MT5 está atrasado com carrapatos e conseqüentemente com a aceitação de ordens pendentes (incluindo níveis SL/TP).
E após um redirecionamento, o MT5 espera toda vez que o próximo tick verifique se o preço satisfaz o nível TP (ou limite) ou não. Isto pode levar até segundos. E a verificação deve ser sempre feita imediatamente após o regimento (ou preenchimento parcial).
OnTick é acionado alguns milissegundos depois que o tick é escrito para o servidor comercial.
Resultado.
Foram processados 100 carrapatos. A defasagem de chegada entre o servidor e o terminal do tick varia de um a oito milissegundos. A média é um pouco mais de quatro milissegundos. Isto é igual à defasagem do acionamento da ordem TP, que é onde este ramo começou.
O próprio atraso está dentro do servidor MT5. O canal Server->Terminal não tem nada a ver com isso.
Um grande pedido aos desenvolvedores para eliminar este atraso. Agora com zero pings temos um atraso constante de ticks que chegam não só ao terminal, mas também ao Servidor. Em particular, a ordem aceita.
ZS Para aqueles que despem os corretores de cozinha através de arbitragem, este atraso embutido é como mana do céu. Isto é, os corretores incorrem em riscos adicionais substanciais.
Renat Fatkhullin:
На каком сервере проверяли?
Verificado em muitos servidores. Incluindo MQ-Demo.
Fórum sobre comércio, sistemas automatizados de comércio e testes de estratégia comercial
Aceitação de ordens SL/TP
fxsaber, 2020.11.25 00:47
Resultado da sua execução no MQ-Demo.
O roteiro afirma ter encontrado uma ordem TP e um tique que foi o gatilho para sua criação (destacado em cores no texto). Parece que se o preço atingiu o nível TP de uma posição aberta no servidor comercial (especialmente na demonstração), a ordem TP correspondente deve ser criada (não necessariamente executada) imediatamente. Entretanto, nesta situação não aconteceu imediatamente, mas depois de 357 milissegundos!
Em qual instrumento e em qual gateway/datafeto formaram-se os dados iniciais?
Verifiquei as ferramentas forex, RannForex-Server, AMTS-gateway. Outras configurações precisam ser esclarecidas.
Acredito que o servidor MT5 estava se formando em uma máquina com zero ping. Mas requer esclarecimento para uma garantia de 100%. No entanto, o acima exposto mostrou que mesmo em seu servidor o problema.
Ao investigar a execução de ordens TP, notei que algumas ordens TP foram criadas com um atraso significativo em relação aos carrapatos que as aceitavam.
O debriefing mostrou que esta situação se repete não apenas em corretores diferentes, mas também na situação em que a negociação é feita no Terminal, que está na mesma máquina que o Servidor de Negociação. Isto é, com um ping muito baixo e uma única conta de negociação para o Trading Server.
Eu os encorajo a compartilhar os resultados de suas contas. Ajude a melhorar o MT5!Você "esqueceu" um detalhe muito pequeno - você verificou 58.000 pedidos e encontrou apenas um caso de excesso a 300 ms. E você deveria ter se concentrado claramente nisto (1 em 58.000) durante estas verificações.
Assim como nos anteriores com cheques de milhões de dólares, onde você também procurou por um único outlier e fingiu que era um comportamento normal.
Verificamos os logs do servidor e pudemos ver que nossa virtualização com o servidor MetaQuotes-Demo estava fisicamente doente naqueles segundos (em 2020.09.30 19:07 por 4 segundos), porque havia cerca de 15 milhões de contas e cerca de 2 milhões de posições abertas, e enquanto isso algo estava acontecendo nos servidores virtuais vizinhos e no hipervisor.
Em qualquer caso, vamos investigar mais a fundo, embora haja sempre picos únicos em qualquer sistema.