Acceptation des ordres SL/TP - page 8

[fxsaber]

Andrey Khatimlianskii #:

Au fait, oui, c'est intéressant. Si un petit limiteur est au même niveau que le TP d'une position énorme, et que ce TP est redirigé parce qu'il est gros, le limiteur n'aura même pas la chance d'être rempli ?

Mauvaise supposition. La file d'attente des tees expire lorsque tous les tees sont envoyés. En d'autres termes, les limiteurs attendent que tous les tekes soient envoyés, et non les résultats de cet envoi.

Ce n'est pas la grande quantité de limiteurs qui peut ralentir l'envoi d'autres limiteurs, mais la grande quantité de limiteurs au niveau de prix du limiteur. Par exemple avec un lot minimum.

[Andrey Khatimlianskii]

fxsaber #:

Mauvaise supposition. La file d'attente des jetons expire lorsque tous les jetons ont été envoyés. En d'autres termes, les limiteurs attendent que tous les tkes soient envoyés, et non les résultats de cet envoi.

Ce n'est pas la grande quantité de limiteurs qui peut ralentir l'envoi d'autres limiteurs mais la grande quantité de limiteurs au niveau de prix du limiteur. Par exemple avec le lot minimum.

Au moins de cette façon. C'est mieux que d'exécuter systématiquement tous les TP et les limites.

Mais vous devez réparer la file d'attente, bien sûr. Le TP devrait être une limite régulière.

[fxsaber]

Andrey Khatimlianskii #:

Au moins, c'est comme ça. C'est mieux que d'avoir tous les TA et les limites appliquées de façon constante.

Mais il est bien sûr nécessaire de réparer la file d'attente. Le TA devrait être un limiteur régulier.

Vous trouverez beaucoup plus de détails sur le sujetici. Avec des exemples.

[fxsaber]

fxsaber #:

Vous trouverez beaucoup plus de détails sur le sujetici. Avec des exemples.

Il semblerait que le tick d'activation de l'ordre TP soit né après la naissance de l'ordre TP ! C'est-à-dire que l'ordre TP est né en premier, et seulement ensuite le tick qui a provoqué la naissance de l'ordre TP. Cela semble délirant. Examinons donc la photo en détail.

Le scénario n'a pas fait d'erreur, c'est vrai ! Cela signifie que la base de données des ticks est remplie avec un énorme décalage. Et le temps de tic est défini comme le temps d'enregistrement. C'est-à-dire un temps de tic erroné.

Unbug architecturalde MT5 a donc été découvert.

La reproduction de ce bug dans MQ-Demo dès la première fois.

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

Après avoir fermé une position, nous regardons l'heure du tick déclenché et l'heure du tick qui aurait dû déclencher la vérification.

Nous constatons que le tick s'est déclenché 61 ms avant l'apparition du tick qui est censé l'avoir activé.

Le bug n'est pas seulement reproduit dans MQ-Demo : il est même présent dans les comptes réels. Mais il peut être reproduit immédiatement sur MQ-Demo, comme indiqué ci-dessus.

La base de données des tick sur le serveur de commerce est malheureusement déformée.

Chaîne de recherche:Oshibka 042.