Annahme von SL/TP-Aufträgen - Seite 8

Neuer Kommentar
 
Andrey Khatimlianskii #:

Übrigens, ja, es ist interessant. Wenn ein kleiner Begrenzer auf derselben Ebene wie der TP einer großen Position liegt und dieser TP umgeleitet wird, weil er groß ist, hat der Begrenzer nicht einmal eine Chance, gefüllt zu werden?

Falsche Annahme. Die Warteschlange der Abschläge läuft ab, wenn alle Abschläge verschickt wurden. Das heißt, die Begrenzer warten darauf, dass alle Tekes gesendet werden, und nicht auf die Ergebnisse dieser Sendung.

Es ist nicht die große Anzahl von Limitern, die das Senden von anderen Limitern verlangsamen kann, sondern die große Anzahl von Limitern auf dem Preisniveau des Limiters. Zum Beispiel mit einer Mindestmenge.

 
fxsaber #:

Falsche Annahme. Die Warteschlange für Token läuft ab, wenn alle Token gesendet wurden. Das heißt, die Begrenzer warten darauf, dass alle Tekes gesendet werden, und nicht auf die Ergebnisse dieser Sendung.

Es ist nicht die große Anzahl von Limitern, die das Senden von anderen Limitern verlangsamen kann, sondern die große Anzahl von Limitern auf dem Preisniveau des Limiters. Zum Beispiel mit der Mindestmenge.

Nun, zumindest auf diese Weise. Das ist besser, als konsequent alle TPs und Limits auszuführen.

Aber Sie sollten natürlich die Warteschlange reparieren. Der TP sollte ein regelmäßiger Grenzwert sein.

 
Andrey Khatimlianskii #:

Nun, zumindest ist es so. Das ist besser als die konsequente Durchsetzung aller TAs und Grenzwerte.

Aber es ist natürlich notwendig, die Warteschlange zu reparieren. Der TA sollte ein regulärer Begrenzer sein.

Hier finden Sie weitere Einzelheiten zu diesem Thema. Mit Beispielen.

Длительность исполнения торговых приказов
Длительность исполнения торговых приказов
  • www.mql5.com
Величина различия в мат. ожиданиях одной и той же торговой стратегии в Тестере и на реальном счете зависит не только от компетенции автора робота, но и от качества исполнения торговых приказов
 
fxsaber #:

Hier finden Sie weitere Einzelheiten zu diesem Thema. Mit Beispielen.

Angeblich wurde der Tick, der den TP-Auftrag aktiviert, erst nach der Geburt des TP-Auftrags geboren! Das heißt, der TP-Auftrag wurde zuerst geboren, und erst dann der Tick, der den TP-Auftrag verursacht hat. Das klingt wahnhaft. Schauen wir uns das Bild also einmal genauer an.

Das Drehbuch hat keinen Fehler gemacht, es ist wahr! Das bedeutet, dass die Datenbank der Ticks mit einer großen Verzögerung gefüllt wird. Und die Tick-Zeit wird als Aufnahmezeit eingestellt. D.h. fehlerhafte Tickzeit.


Es wurde also einArchitekturfehler von MT5 gefunden.

Die Reproduktion dieses Fehlers in MQ-Demo vom ersten Mal.

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


Nach dem Schließen einer Position sehen wir uns den Zeitpunkt des ausgelösten Ticks und den Zeitpunkt des Ticks an, der die Prüfung hätte auslösen sollen.

Wir sehen, dass der Tick 61 ms vor dem Tick, der ihn angeblich aktiviert hat, ausgelöst wurde.


Der Fehler tritt nicht nur in MQ-Demo auf, sondern auch in echten Konten. Sie kann aber, wie oben gezeigt, sofort auf MQ-Demo reproduziert werden.


Die Tickdatenbank auf dem Handelsserver ist leider gestört.

Suchbegriff:Oshibka 042.

12345678
Neuer Kommentar