Acceptance of SL/TP orders - page 8

[fxsaber]

Andrey Khatimlianskii #:

By the way, yes, it is interesting. If a small limiter is on the same level as the TP of a huge position, and that TP is redirected because it's big, the limiter won't even have a chance to be filled?

Wrong assumption. The queue of tees expires when all the tees are sent out. That is, the limiters are waiting for all the tekes to be sent, not for the results of that sending.

It is not the large amount of limiters that can slow down the sending of the limiters but the large amount of limiters at the price level of the limiter. For example with a min. lot.

[Andrey Khatimlianskii]

fxsaber #:

Wrong assumption. The queue for tokens expires when all tokens have been sent. That is, limiters wait for all the tekes to be sent, not for the results of that sending.

It is not the large amount of limiters that can slow down the sending of other limiters but the large amount of limiters at the price level of the limiter. For example with the min. lot.

Well, at least this way. It's better than consistently executing all TPs and Limits.

But you should fix the queue, of course. The TP should be a regular limit.

[fxsaber]

Andrey Khatimlianskii #:

Well, at least that's the way it is. It's better than having all the TAs and limits consistently enforced.

But fixing the queue, of course, is necessary. The TA should be a regular limiter.

There is much more detail on the subjecthere. With examples.

[fxsaber]

fxsaber #:

There is much more detail on the subjecthere. With examples.

Allegedly the TP order activating tick was born after the TP order was born! That is, the TP order was born first, and only then the tick that caused the TP order to be born. This sounds delusional. So let's take a detailed look at the picture.

The script didn't make a mistake, it's true! It means that the database of ticks is filled with a huge lag. And the tick time is set as the recording time. I.e. erroneous tick time.

So an architecturalbug of MT5 has been found.

The reproduction of this bug in MQ-Demo from the first time.

#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);
}

After closing a position, we look at the time of the triggered tick and at the time of the tick that should have triggered the check.

We see that the tick trigger ed 61 ms before the tick that supposedly activated it appeared.

The bug is not only reproduced in MQ-Demo: it is even present in real accounts. But it can be reproduced immediately on MQ-Demo, as shown above.

The tick database on the trade server is distorted, unfortunately.

Search string:Oshibka 042.