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.
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.1010:00:05.148 Trades 'xxxxx': buy limit 5.00 RTS-3.17 at 988502016.10.1010:00:05.148 Trades 'xxxxx': sell limit 5.00 RTS-3.17 at 997802016.10.1010:00:05.154 Trades 'xxxxx': accepted buy limit 5.00 RTS-3.17 at 988502016.10.1010:00:05.154 Trades 'xxxxx': accepted sell limit 5.00 RTS-3.17 at 997802016.10.1010:00:05.155 Trades 'xxxxx': buy limit 5.00 RTS-3.17 at 98850 placed for execution in6.904 ms
2016.10.1010:00:05.156 Trades 'xxxxx': sell limit 5.00 RTS-3.17 at 99780 placed for execution in7.850 ms
Warum erstellen Sie nicht ein einfaches Protokoll, wie zum Beispiel
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.
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?
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.2103:31:10.568 Terminal Открытие Брокер MetaTrader 5 СР x64 build 1430 started (ОАО '' Брокерский дом '' ОТКРЫТИЕ'')
2016.09.2117: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 in19.086 ms
2016.09.2117:30:00.157 Trades 'xxxxx': buy limit 5.00 BR-12.16 at 47.66 placed for execution in19.185 ms
2016.09.2117:30:00.160 Trades 'xxxxx': deal #29616740 buy 5.00 BR-12.16 at 47.66 done (based on order #44620667)
2016.09.2117:30:01.064 Trades 'xxxxx': exchange sell 5.00 BR-11.16 at market
2016.09.2117:30:02.004 Trades 'xxxxx': cancel order #44620664 buy limit 5.00 ROSN-3.17 at 364702016.09.2117:30:04.827 Trades 'xxxxx': accepted exchange sell 5.00 BR-11.16 at market
2016.09.2117:30:04.827 Trades 'xxxxx': exchange sell 5.00 BR-11.16 at market placed for execution in3764.451 ms
2016.09.2117:30:04.829 Trades 'xxxxx': deal #29616752 sell 5.00 BR-11.16 at 47.33 done (based on order #44620682)
2016.09.2117:30:05.799 Trades 'xxxxx': cancel order #44613523 sell limit 1.00 TRNF-3.17 at 1493982016.09.2117:30:07.929 Trades 'xxxxx': accepted cancel order #44620664 buy limit 5.00 ROSN-3.17 at 364702016.09.2117:30:07.929 Trades 'xxxxx': cancel order #44620664 buy limit 5.00 ROSN-3.17 at 36470 placed for execution in5926.927 ms
2016.09.2117: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: 02016.09.2117:30:08.775 Trades 'xxxxx': accepted cancel order #44613523 sell limit 1.00 TRNF-3.17 at 1493982016.09.2117:30:08.776 Trades 'xxxxx': cancel order #44613523 sell limit 1.00 TRNF-3.17 at 149398 placed for execution in2977.588 ms
2016.09.2117: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: 02016.09.2117: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 in852.561 ms
2016.09.2117: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: 02016.09.2117: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: 02016.09.2117: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 in40.658 ms
2016.09.2117:30:10.053 Trades 'xxxxx': cancel order #44620340 buy limit 1.00 TATN-3.17 at 323122016.09.2117:30:10.075 Trades 'xxxxx': accepted cancel order #44620340 buy limit 1.00 TATN-3.17 at 323122016.09.2117:30:10.079 Trades 'xxxxx': cancel order #44620340 buy limit 1.00 TATN-3.17 at 32312 placed for execution in25.974 ms
2016.09.2117:30:44.537 Trades 'xxxxx': sell limit 1.00 BR-12.16 at 48.042016.09.2117:30:44.669 Trades 'xxxxx': accepted sell limit 1.00 BR-12.16 at 48.042016.09.2117:30:44.669 Trades 'xxxxx': sell limit 1.00 BR-12.16 at 48.04 placed for execution in132.352 ms
2016.09.2117:30:45.165 Trades 'xxxxx': sell limit 10.00 Si-6.17 at 704492016.09.2117:30:45.179 Trades 'xxxxx': accepted sell limit 10.00 Si-6.17 at 704492016.09.2117:30:45.180 Trades 'xxxxx': sell limit 10.00 Si-6.17 at 70449 placed for execution in14.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.
Allgemeine Überlegungen zum Umgang mit Prozessen mit geringer Latenzzeit im Handel:
Makler und Systeme, die technikbegeistert sind, arbeiten eindeutig an ihrer technologischen Infrastruktur und investieren in deren Verbesserung. Aber leider tun das nicht alle.
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:
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
Allgemeine Überlegungen zum Umgang mit Prozessen mit geringer Latenzzeit im Handel:
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.
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.
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:
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.
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.
Tut mir leid, Renat, aber das kann auf keinen Fall eine Netzwerklatenz sein: