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

Neuer Kommentar
 
Diese Information sollte an alle MT-Mega-HFTs verschickt werden (nur ein Scherz). Der Preis der Billigkeit ist dieser.
 
fxsaber:

In einem anderen Thread wurde wiederholt darauf hingewiesen, dass selbst das Terminal durch eine Vielzahl von Faktoren verlangsamt wird. Infolgedessen wird ein viel komplexerer Trading Server zwangsläufig noch langsamer werden. Ich hoffe nach wie vor, dass eine algorithmische Optimierung noch möglich ist. Selbst eine Verzögerung von 5 ms ist schon sehr schlecht. Was soll man zu Hunderten von Millisekunden sagen.

Was die Demokonten betrifft, so sind diese nicht sehr interessant (ich kann dort alle Plugins debuggen, neue Hardware testen usw.).

Und ich habe festgestellt, max 17 ms auf Live-Konten (ich sage nicht, es ist nicht lang, es kann nur nicht mit 30 Sekunden verglichen werden).

Daher der Verdacht auf eine kaskadierende Servereinrichtung.

 
Andrey Khatimlianskii:

Das auf Demo ist nicht sehr interessant (Sie können dort alle Plugins debuggen, neue Hardware testen, ...).

Und auf Live-Konten fand ich maximal 17 ms (ich sage nicht, dass das nicht genug ist, es ist nur nicht mit 30 Sekunden zu vergleichen).

Leider haben sie nicht angegeben, wie viele Bestellungen sie überprüft haben.

Forum zum Thema Handel, automatisierte Handelssysteme und Testen von Handelsstrategien

Annahme von SL/TP-Aufträgen

fxsaber, 2020.11.25 01:23

Total Orders (from 2020.11.01 00:00:00) = 21725, calculated = 10465
Calculation time = 00:04:33.609, Performance = 38.0 orders/sec.

Daher der Verdacht auf eine kaskadierende Servereinrichtung.

Der Makler bestätigte das Problem und schaffte es, es zu finden und zu beheben (wird nach dem Wochenende verfügbar sein). Aber es ist schwer zu sagen, ob es an MT5 lag.


Aber Steine in Richtung MT5 zu werfen, kann man in dieser Situation durchaus tun.

Forum zum Thema Handel, automatisierte Handelssysteme und Strategietests

Annahme von SL/TP-Aufträgen

fxsaber, 2020.11.25 00:47

Ich weiß nicht, was ich tun soll, wenn ich auf dem Terminal handele, aber ich habe eine sehr niedrige Auswahl auf dem Trading Server und weiß nicht, was ich tun soll, wenn ich handele. D.h. mit einem sehr niedrigen Ping und einem einzigen Handelskonto für den Handelsserver.



Terminal und Server befinden sich auf demselben Rechner. Nulllast. Ein neuer Ansatz hat einen solchen Alarm erhalten.

Accepted Tick 2020.11.25 16:05:11.522 10.15469 10.15668
Accepted Length = 4 ms.
Order 212 ORDER_TYPE_SELL EURSEK 2020.11.25 16:05:11.526 10.15462 ORDER_REASON_TP ORDER_STATE_FILLED


Server-Protokoll.

2020.11.25 16:05:11.526    '': take profit triggered #168 buy 0.01 EURSEK 10.19022 tp: 10.15462, activation price 10.15469 [#212 sell 0.01 EURSEK at 10.15462][10.15469 / 10.15668]


Accept-Tick auf dem Server.


Vollständige Skriptdaten bestätigen, dass ein Problem vorliegt. Innerhalb des Servers gab es bei Nulllast eine Verzögerung von 4 ms.

 
Andrei Trukhanovich:

ein weiterer Geistesblitz von fxsaber.

Besonders schlimm ist es, wenn man merkt, wie viel Zeit man vergeudet hat. Und dass niemand es für Sie tun wird.
 

Es scheint wirklich ein Problem auf dem Server zu sein. Dies ist ein MT5-Demokonto

 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  Total Orders (from 2020.01 . 01 00 : 00 : 00 ) = 5417 , calculated = 755
 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  Calculation time = 00 : 00 : 14.656 , Performance = 51.0 orders/sec.
 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  
 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  ServerName: RannForex-Server
 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  Last Tick 2020.11 . 23 19 : 59 : 30.634 104.341 104.341
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  Accepted Tick 2020.11 . 23 19 : 58 : 57.044 104.336 104.336
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  Accepted Length = 33592  ms.
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  Order 1747932 ORDER_TYPE_SELL USDJPY 2020.11 . 23 19 : 59 : 30.636 104.336 ORDER_REASON_TP ORDER_STATE_FILLED 2020.11 . 23 19 : 59 : 30.658 , Position 1747924 created 2020.11 . 23 19 : 58 : 35.556 , StopLevel = 0
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  
 2020.11 . 25 16 : 58 : 07.799 OrderCheck (USDJPY,H1)  Orders ( 3 ) before 1747932 with PositionID = 1747924 :
 2020.11 . 25 16 : 58 : 07.799 OrderCheck (USDJPY,H1)  ------------------------
 2020.11 . 25 16 : 58 : 07.799 OrderCheck (USDJPY,H1)  Checked Orders = 0

Bei einem echten Konto beim gleichen Broker liefert das Skript null Ergebnisse. Auf dem Konto befinden sich über 3000 Transaktionen.

 
Enrique Dangeroux:

Bei einem echten Konto beim gleichen Broker liefert das Skript null Ergebnisse. Auf dem Konto befinden sich mehr als 3.000 Transaktionen.

Das ist verdächtig. Ich habe bei meinen Konten nirgendwo eine Verzögerung festgestellt.

 

Ich bin nicht sicher, ob es damit zusammenhängt. Aber ich bekomme eine Menge davon. 

2020.11.25 16:52:52.992 Trades  '92810': failed modify #1758569 sell 0.02 USDJPY sl: 0.000, tp: 104.293 -> sl: 0.000, tp: 0.000 [Unknown error]

Fehler, die ausgelöst werden, wenn die Position geändert wird. Take wird also ausgelöst, weicht ein paar Mal aus, bleibt dann hängen, ich ändere tp auf Null, um zurückzufahren und zusammenzubrechen.


Bevor ich sie ändere, prüfe ich sie

 if ( OrderCloseReason() >= ( int ) ORDER_REASON_SL )

Damit die Position nicht eingefroren wird.

 
fxsaber :

Das ist verdächtig. In meinen Konten habe ich nirgends einen Mangel an Verzögerungen festgestellt.

Das dachte ich auch, aber weitere Nachforschungen ergaben, dass es sich um etwa 100 Schließungen allein durch Take handelt.

Also zu einer kleinen Stichprobengröße.

 

Forum zum Thema Handel, automatische Handelssysteme und Testen von Handelsstrategien

Annahme von SL/TP-Aufträgen

Enrique Dangeroux, 2020.11.25 17:20

Ich bin nicht sicher, ob dies damit zusammenhängt. Aber ich bekomme eine Menge davon. 

2020.11.25 16:52:52.992 Trades  '92810': failed modify #1758569 sell 0.02 USDJPY sl: 0.000, tp: 104.293 -> sl: 0.000, tp: 0.000 [Unknown error]

Ich habe auch mein ganzes Protokoll in solchen Meldungen. Vielleicht wird sich die Situation nach dem Wochenende ändern.

Forum zum Thema Handel, automatische Handelssysteme und Testen von Handelsstrategien

Annahme von SL/TP-Aufträgen

fxsaber, 2020.11.25 16:30

Der Makler bestätigte das Problem und schaffte es, es zu finden und zu beheben (wird nach dem Wochenende verfügbar sein). Aber es ist schwer zu sagen, ob es an MT5 lag.

 

Betrachten wir schematisch einige Algorithmen des Handelsplatzes. Der Einfachheit halber gehen wir davon aus, dass es nur einen LP(Liquiditätsanbieter) gibt.


Limitierter Auftrag.

  1. Der Preis aus dem LP entspricht dem Preis des Parketthandels-Limitauftrags.
  2. Gateway sendet diesen Limitauftrag mit einer kurzen Verfallszeit an den LP.
  3. Wenn Gateway einen Redirect für einen Teil des Limitvolumens erhält, wiederholt Gateway alles ab Punkt 1 für das verbleibende Volumen, falls sich der Tick vom LP während der Zeit der Limitverarbeitung geändert hat.

Ein gutes Gateway (mit dem obigen Algorithmus) ist unabhängig von den Besonderheiten der Handelsplattform, wenn es den Limiter ausführt.

Der Algorithmus ist nahezu schleifenförmig und plattformunabhängig. LP-Spamschutz ist in Punkt 3 enthalten.


TP-Level einer offenen Position.

  1. Eine Zecke kam von LP
  2. Der Preis wird als neuer Tick an MT5 gesendet.
  3. Wenn die Position nicht blockiert ist und der Preis des neuen Ticks das TP-Niveau erreicht, erstellt MT5 eine TP-Order.
  4. Das Gateway sieht, dass ein TP-Auftrag entstanden ist, sperrt die Position und führt P.2 des Algorithmus für Limitaufträge aus.
  5. Wenn er einen Re-Jack empfängt, sendet MT5 den TP-Auftrag mit einem Ablehnungsstatus an die Historie. Die Position ist entriegelt.

Der Algorithmus wird nicht in einer Schleife ausgeführt und ist plattformabhängig. Es bietet Schutz vor Spam-LP.


Dieser Algorithmus hat neben den Kommunikationskosten zwischen Gateway und MT5 zwei Nachteile.

  • In diesem Thread wurde gezeigt, dass die Entstehung einer TP-Order (siehe Punkt 3) im MT5 eine Verzögerung aufweist. Daher ist die Wahrscheinlichkeit, dass ein TP-Auftrag ausgeführt werden kann, geringer, als wenn es keine Verzögerung gäbe.
  • Ein TP-Auftrag im MT5 kann nicht ohne einen neuen Tick erstellt werden. Das bedeutet, dass das Gateway im Falle einer Weiterleitung nichts unternimmt, bis ein neuer Tick im MT5 eingetroffen ist, der den TP-Level erfüllt. Dadurch geht wertvolle Zeit für den Versuch verloren, die TP-Stufe auszuführen. Dadurch verschlechtert sich auch die FillRate.


Verbesserung.

Smart Gateway im TP-Level-Algorithmus einer offenen Position hat S.6:

6. Wenn während der Umleitung ein neuer Tick von LP empfangen wurde, wird sein aktueller Wert erneut als neuer Tick an MT5 gesendet - gehen Sie zu Schritt 2.

Dieser zusätzliche Punkt des Algorithmus enthält immer noch einen Schutz vor LP-Spam, aber er bringt MT5 dazu, Punkt 3 auszuführen, und es geht keine kostbare Zeit durch das Warten auf den neuen Tick verloren.


Die Realität.

Aus diesen beiden Algorithmen (auch im Fall von Punkt 6 des zweiten Algorithmus) folgt dies.

Eine MT5-Limit-Order hat eine höhere FillRate als ihr Gegenstück in Form einer offenen Position auf TP-Niveau. Aus diesem Grund kann es bei einem Rollover auf dem MT5-Hedge häufig zu Situationen kommen, in denen die Limit-Order ausgeführt wird, ihr TP-Gegenstück jedoch nicht. In einem solchen Fall wird CloseBy durchgeführt und die Limit-Order wird mit dem entsprechenden Volumen erneut ausgeführt.


Schlussfolgerung.

Um die FillRate im MT5 zu erhöhen, übertragen Sie die TP-Levels der offenen Positionen in MT5-Limit-Orders.

12345678
Neuer Kommentar