FORTS. Fragen der Durchsetzung - Seite 79

 

Allgemeine Überlegungen zum Umgang mit Prozessen mit geringer Latenzzeit im Handel:

  • bei Werten von 10 ms pro Runde und darunter gibt es fast keine Garantie für die Stabilität der Latenzzeit
  • Wenn Sie eine Reihe von Netzen vor sich haben, ist die Latenzstabilität ein Geschenk, keine Garantie.
  • Sie haben keine Kontrolle über die Netze Ihrer Partner, deren Bandbreite und Latenzzeit
  • Um eine Garantie zu haben, muss man alle Zwischenhändler aus dem Netz entfernen.
  • zu gewährleisten, müssen Sie in Ihre Hardware (Bandbreite, Computer, Router) investieren und den maximalen Pfad kontrollieren
  • Sie müssen ein Streber und Perfektionist sein.


Makler und Systeme, die technikbegeistert sind, arbeiten eindeutig an ihrer technologischen Infrastruktur und investieren in deren Verbesserung. Aber leider tun das nicht alle.

 
Renat Fatkhullin:

Das Terminal zeigt die lokale Zeit der Registrierung/des Empfangs des Signals auf Ihrem Terminal an, nicht die genaue Zeit der einzelnen Ausführungsschritte auf der Gegenseite.

In diesem Fall haben Sie alle Antworten (sowohl die Bestätigung des MT5-Servers als auch die Bestätigung der Auftragserteilung an der Börse) zur gleichen Zeit erhalten 029. Da sich viele Netze zwischen Ihnen befinden, gibt es keine Garantie dafür, dass jedes Paket in der minimalen Ping-Zeit sofort an Sie zugestellt wird. Ein kleiner Stau im Netz oder ein Mangel an Netzbandbreite (z. B. beim Broker) führt dazu, dass sich Pakete ansammeln und dann in Stapeln zugestellt werden.

Aus diesem Grund können Sie die Zeiten der verschiedenen Phasen nicht zählen, wenn es Probleme mit dem Netz gibt. In einem idealen Netz, das sich in der Nähe des Servers des Vermittlers befindet, kann man sich immer noch auf eine gewisse Garantie für minimale Latenzzeiten verlassen und die Zeit der Zwischenschritte zählen.


Die Antwort "Ich habe ein perfektes Netz, ich kann mich nicht beklagen" ist nicht angemessen. Denn es handelt sich um völlig unterschiedliche Zeitabläufe, die sich der menschlichen Wahrnehmung unter normalen Bedingungen entziehen.

D.h. wie hier:

2016.10.10 10:00:05.148 Trades  'xxxxx': buy limit 5.00 RTS-3.17 at 98850
2016.10.10 10:00:05.148 Trades  'xxxxx': sell limit 5.00 RTS-3.17 at 99780
2016.10.10 10:00:05.154 Trades  'xxxxx': accepted buy limit 5.00 RTS-3.17 at 98850
2016.10.10 10:00:05.154 Trades  'xxxxx': accepted sell limit 5.00 RTS-3.17 at 99780
2016.10.10 10:00:05.155 Trades  'xxxxx': buy limit 5.00 RTS-3.17 at 98850 placed for execution in 6.904 ms
2016.10.10 10:00:05.156 Trades  'xxxxx': sell limit 5.00 RTS-3.17 at 99780 placed for execution in 7.850 ms

Warum erstellen Sie nicht ein einfaches Protokoll, wie zum Beispiel

Handelsserver hat einen Auftrag erhalten - Handelsserverzeit

Der Handelsserver hat der Börse einen Auftrag erteilt - Zeit des Handelsservers

Der Handelsserver hat eine Antwort von der Börse erhalten - die Uhrzeit des Handelsservers.

Dann hätten Sie diesen langen Faden ein für alle Mal geschlossen.

Hinzugefügt.

Und senden Sie diese Zeiten (alle drei) anstelle vonakzeptiert undzur Ausführunggestellt

 
Vielleicht werden wir dies in Zukunft tun.
 
Renat Fatkhullin:

Allgemeine Überlegungen zum Umgang mit Prozessen mit geringer Latenzzeit im Handel:

Die Fragen scheinen sich auf Hunderte oder Tausende von Millisekunden zu beziehen.
 
fxsaber:
Die Fragen schienen sich auf Hunderte und Tausende von Millisekunden zu beziehen.

In der Praxis, nachdem wir eine gute Infrastruktur aufgebaut haben und mit sorgfältig zusammengestellten Liquiditätsanbietern 3-4 ms pro Runde erreichen, sind die Leute verblüfft, wenn sie periodische Spitzen von 700-1500 ms sehen, nachdem sie in Produktion gegangen sind. Und die Erbauer perfekter Systeme müssen damit leben und sich anpassen.

Die Realität sieht also so aus: Es gibt keine Garantie für eine stabile Mindestlatenzzeit.

Vor allem in einem Umfeld mit so vielen Zwischenstufen.

 
Renat Fatkhullin:
Möchten Sie es überprüfen?

Forum zum Thema Handel, automatisierte Handelssysteme und Testen von Handelsstrategien

FORTS. Fragen zum Vollzug

fxsaber, 2016.10.10 11:38

Hier ist eine tolle Funktion für die Entwickler, um die Bremsen zu reproduzieren!

Jetzt wird es nicht mehr möglich sein zu sagen: "Wir können die Bremsen nicht sehen".

Die Entwickler sollten damit beginnen, Grenzwertanfragen bei der Eröffnung der Sitzung zu stellen und die Ausführungszeit zu überwachen. Wenn sie eine Langsamkeit feststellen, werden sie sich vor Ort darum kümmern.

Im Moment ist die Situation leider deprimierend.

Zu Ihrer Infrastruktur. Durch die Veröffentlichung von Protokollen der ersten Minuten des offenen Marktes?
 
Renat Fatkhullin:

In der Praxis sind die Leute, die eine gute Infrastruktur aufgebaut haben und 3-4 ms pro Runde mit sorgfältig zusammengestellten Liquiditätsprovider genießen, als ausgereifter Broker verblüfft, wenn sie periodische Spikes von 700-1500 ms sehen, nachdem sie in Produktion gegangen sind. Und die Erbauer perfekter Systeme müssen damit leben und sich anpassen.

Die Realität sieht also so aus: Es gibt keine Garantie für eine stabile Mindestlatenzzeit.

Vor allem in einem Umfeld mit so vielen Zwischenstufen.

Tut mir leid, Renat, aber das kann auf keinen Fall eine Netzwerklatenz sein:

2016.09.21 03:31:10.568 Terminal        Открытие Брокер MetaTrader 5 СР x64 build 1430 started (ОАО '' Брокерский дом '' ОТКРЫТИЕ'')

2016.09.21 17:30:00.156 Trades  'xxxxx': modify order #44620664 buy limit 5.00 ROSN-3.17 at 36438 sl: 0 tp: 0 -> 36470, sl: 0 tp: 0 placed for execution in 19.086 ms
2016.09.21 17:30:00.157 Trades  'xxxxx': buy limit 5.00 BR-12.16 at 47.66 placed for execution in 19.185 ms
2016.09.21 17:30:00.160 Trades  'xxxxx': deal #29616740 buy 5.00 BR-12.16 at 47.66 done (based on order #44620667)
2016.09.21 17:30:01.064 Trades  'xxxxx': exchange sell 5.00 BR-11.16 at market
2016.09.21 17:30:02.004 Trades  'xxxxx': cancel order #44620664 buy limit 5.00 ROSN-3.17 at 36470
2016.09.21 17:30:04.827 Trades  'xxxxx': accepted exchange sell 5.00 BR-11.16 at market
2016.09.21 17:30:04.827 Trades  'xxxxx': exchange sell 5.00 BR-11.16 at market placed for execution in 3764.451 ms
2016.09.21 17:30:04.829 Trades  'xxxxx': deal #29616752 sell 5.00 BR-11.16 at 47.33 done (based on order #44620682)
2016.09.21 17:30:05.799 Trades  'xxxxx': cancel order #44613523 sell limit 1.00 TRNF-3.17 at 149398
2016.09.21 17:30:07.929 Trades  'xxxxx': accepted cancel order #44620664 buy limit 5.00 ROSN-3.17 at 36470
2016.09.21 17:30:07.929 Trades  'xxxxx': cancel order #44620664 buy limit 5.00 ROSN-3.17 at 36470 placed for execution in 5926.927 ms
2016.09.21 17:30:08.738 Trades  'xxxxx': modify order #44620340 buy limit 1.00 TATN-3.17 at 32276 sl: 0 tp: 0 -> 32278, sl: 0 tp: 0
2016.09.21 17:30:08.775 Trades  'xxxxx': accepted cancel order #44613523 sell limit 1.00 TRNF-3.17 at 149398
2016.09.21 17:30:08.776 Trades  'xxxxx': cancel order #44613523 sell limit 1.00 TRNF-3.17 at 149398 placed for execution in 2977.588 ms
2016.09.21 17:30:09.585 Trades  'xxxxx': accepted modify order #44620340 buy limit 1.00 TATN-3.17 at 32276 sl: 0 tp: 0 -> 32278, sl: 0 tp: 0
2016.09.21 17:30:09.590 Trades  'xxxxx': modify order #44620340 buy limit 1.00 TATN-3.17 at 32276 sl: 0 tp: 0 -> 32278, sl: 0 tp: 0 placed for execution in 852.561 ms
2016.09.21 17:30:09.597 Trades  'xxxxx': modify order #44620340 buy limit 1.00 TATN-3.17 at 32278 sl: 0 tp: 0 -> 32312, sl: 0 tp: 0
2016.09.21 17:30:09.637 Trades  'xxxxx': accepted modify order #44620340 buy limit 1.00 TATN-3.17 at 32278 sl: 0 tp: 0 -> 32312, sl: 0 tp: 0
2016.09.21 17:30:09.638 Trades  'xxxxx': modify order #44620340 buy limit 1.00 TATN-3.17 at 32278 sl: 0 tp: 0 -> 32312, sl: 0 tp: 0 placed for execution in 40.658 ms
2016.09.21 17:30:10.053 Trades  'xxxxx': cancel order #44620340 buy limit 1.00 TATN-3.17 at 32312
2016.09.21 17:30:10.075 Trades  'xxxxx': accepted cancel order #44620340 buy limit 1.00 TATN-3.17 at 32312
2016.09.21 17:30:10.079 Trades  'xxxxx': cancel order #44620340 buy limit 1.00 TATN-3.17 at 32312 placed for execution in 25.974 ms
2016.09.21 17:30:44.537 Trades  'xxxxx': sell limit 1.00 BR-12.16 at 48.04
2016.09.21 17:30:44.669 Trades  'xxxxx': accepted sell limit 1.00 BR-12.16 at 48.04
2016.09.21 17:30:44.669 Trades  'xxxxx': sell limit 1.00 BR-12.16 at 48.04 placed for execution in 132.352 ms
2016.09.21 17:30:45.165 Trades  'xxxxx': sell limit 10.00 Si-6.17 at 70449
2016.09.21 17:30:45.179 Trades  'xxxxx': accepted sell limit 10.00 Si-6.17 at 70449
2016.09.21 17:30:45.180 Trades  'xxxxx': sell limit 10.00 Si-6.17 at 70449 placed for execution in 14.720 ms
 
fxsaber:
Können Sie das nicht einfach überprüfen?
auf Ihre Infrastruktur. Durch die Veröffentlichung von Protokollen der ersten Minuten des offenen Marktes?

Was gibt es zu prüfen, wenn wir praktisch keine Kontrolle über irgendetwas haben.

Sie haben bereits bei der Markteröffnung Tests mit Normnachweisen vorgelegt. Aber es ist ein Fall, bei dem eines zum anderen führte.

Ich habe bereits mehrfach darauf hingewiesen, dass es keine Garantie für die Stabilität der Latenzzeiten gibt.


Wären wir ein Makler, sähe die Sache anders aus - wir würden nicht mit der effizientesten Infrastruktur geizen und die maximale Anzahl von Strecken optimieren.

 
prostotrader:

Tut mir leid, Renat, aber das kann auf keinen Fall eine Netzwerklatenz sein:

Sie berücksichtigen NUR die Verzögerungen in Ihrem Netz. Sie machen das sehr gut. Und ein paar Schritte von Ihnen entfernt ist alles in Ordnung.

Das Problem liegt woanders. Lesen Sie bitte alles, was oben steht. Und vielleicht zwischen den Zeilen lesen.

 
prostotrader:

Tut mir leid, Renat, aber das kann auf keinen Fall eine Netzwerklatenz sein:

Scheiße, kann mir jemand sagen, ob auf anderen Plattformen dieser Unsinn mit den sekundenschnellen Auftragseingaben auch passiert?
Grund der Beschwerde: