Aceitação de ordens SL/TP - página 8

[fxsaber]

Andrey Khatimlianskii #:

A propósito, sim, é interessante. Se um limitador pequeno estiver no mesmo nível que o TP de uma posição enorme, e esse TP for redirecionado porque é grande, o limitador não terá sequer uma chance de ser preenchido?

Suposição errada. A fila de tees expira quando todos os tees são enviados. Ou seja, os limitadores estão esperando que todos os tekes sejam enviados, não pelos resultados desse envio.

Não é a grande quantidade de limitadores que pode retardar o envio de outros limitadores, mas a grande quantidade de limitadores ao nível do preço do limitador. Por exemplo, com um lote mínimo.

[Andrey Khatimlianskii]

fxsaber #:

Suposição errada. A fila de fichas expira quando todas as fichas tiverem sido enviadas. Ou seja, os limitadores aguardam o envio de todos os tipos de tecelagem, e não os resultados desse envio.

Não é a grande quantidade de limitadores que pode retardar o envio de outros limitadores, mas a grande quantidade de limitadores ao nível do preço do limitador. Por exemplo, com o lote min.

Bem, pelo menos assim. É melhor do que executar consistentemente todos os TPs e Limites.

Mas você deve consertar a fila, é claro. O TP deve ser um limite regular.

[fxsaber]

Andrey Khatimlianskii #:

Bem, pelo menos é assim que as coisas são. É melhor do que ter todos os TAs e limites coerentemente aplicados.

Mas a fixação da fila, é claro, é necessária. O TA deve ser um limitador regular.

Há muito mais detalhes sobre o assuntoaqui. Com exemplos.

[fxsaber]

fxsaber #:

Há muito mais detalhes sobre o assuntoaqui. Com exemplos.

Alegadamente a ordem de ativação TP nasceu após o nascimento da ordem TP! Ou seja, a ordem TP nasceu primeiro, e só depois o tique que fez nascer a ordem TP. Isto soa a ilusão. Portanto, vamos dar uma olhada detalhada na foto.

O roteiro não cometeu um erro, é verdade! Isso significa que o banco de dados de carrapatos é preenchido com um enorme atraso. E o tempo de registro é definido como o tempo de gravação. Isto é, tempo de carrapato errado.

Assim, foi encontrado umbug arquitetônicodo MT5.

A reprodução deste erro no MQ-Demo desde a primeira vez.

#include <MT4Orders.mqh> // https://www.mql5.com/ru/code/16006

#define  Bid SymbolInfoDouble(_Symbol, SYMBOL_BID)
#define  Ask SymbolInfoDouble(_Symbol, SYMBOL_ASK)

input int inTP = 10;

// Выставляет противоположные позиции с фиксированным тейком.
void OnStart()
{
  OrderSend(_Symbol, OP_BUY, 0.1, Ask, 0, 0, Ask + inTP * _Point);

  OrderSend(_Symbol, OP_SELL, 0.1, Bid, 0, 0, Bid - inTP * _Point);
}

Após fechar uma posição, olhamos para a hora do tique acionado e para a hora do tique que deveria ter acionado a verificação.

Vemos que o tique disparou 61 ms antes do tique que supostamente o ativou aparecer.

O bug não é reproduzido apenas no MQ-Demo: ele está presente até mesmo em contas reais. Mas pode ser reproduzido imediatamente no MQ-Demo, como mostrado acima.

O banco de dados de carrapatos no servidor comercial está distorcido, infelizmente.

Cadeia de busca:Oshibka 042.