Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Ich habe jetzt seit zwei Tagen KEINE Verzögerungen oder andere "Probleme" mit dem MT5-Server gesehen
IST SIE WIRKLICH REPARIERT?
Ich habe jetzt seit zwei Tagen KEINE Verzögerungen oder andere "Probleme" mit dem MT5-Server gesehen
WURDE ALLES GEREGELT?
Vielleicht hat die Zentralbank die Bremsen ausgesetzt? ))
Das ist jetzt 2 Jahre und 2 Monate her.
Ich weiß nicht, wer die Schuld trägt, der Makler oder die Software (ich werde es wohl nie herausfinden), aber das ist das Ergebnis.
2018.02.15 10:00:54.309 Trades 'ххххх': cancel order #84312120 sell limit 2.00 MOEX-6.18 at 11557 2018.02.15 10:01:25.698 Trades 'ххххх': accepted cancel order #84312120 sell limit 2.00 MOEX-6.18 at 11557 2018.02.15 10:01:25.711 Trades 'ххххх': cancel order #84312120 sell limit 2.00 MOEX-6.18 at 11557 placed for execution in 31407.470 ms
Das ist jetzt 2 Jahre und 2 Monate her.
Ich weiß nicht, wer die Schuld trägt, der Makler oder die Software (es sieht so aus, als würde man das nie herausfinden), aber das ist das Ergebnis.
Renat hat einmal gesagt, dass man, um das herauszufinden, Daten über den tatsächlichen Ping, und nicht nur den Ping, im Netz vom Computer zum Broker haben muss - das heißt, um die Idee zu überprüfen: "Gibt es irgendwelche Probleme (und solche Probleme sind immer vorhanden und können jederzeit auftreten) zu dieser Zeit im Netz".
Was noch zu klären ist, ist die Frage, wie das Signal vom Computer an den Makler gleichzeitig mit dem Senden eines Handelsauftrags übermittelt werden kann (was ist zu tun, wenn es sich um einen schwebenden Auftrag handelt???).
Renat hat einmal gesagt, dass man, um das herauszufinden, Daten über den tatsächlichen Ping, und nicht nur den Ping, im Netz vom Computer zum Makler haben muss - das heißt, um die Idee zu überprüfen: "Gibt es irgendwelche Probleme (und solche Probleme können immer zu jeder Zeit auftreten) zu dieser Zeit im Netz".
Es bleibt noch zu klären, wie genau die Übermittlung des Signals vom Computer an den Makler zeitgleich mit der Übermittlung eines Handelsauftrags erfolgen soll (und was zu tun ist, wenn es sich um einen schwebenden Auftrag handelt???).
Was wollen Sie mit der "Zeit" anfangen, wenn der vorherige Befehl in 6 ms ausgeführt wurde und der nächste auch!
Renat hat einmal gesagt, dass man, um das herauszufinden, Daten über den tatsächlichen Ping, und nicht nur den Ping, im Netz vom Computer zum Makler haben muss - das heißt, um die Idee zu überprüfen: "Gibt es irgendwelche Probleme (und solche Probleme können immer zu jeder Zeit auftreten) zu dieser Zeit im Netz".
Es bleibt noch zu klären, wie genau die Übermittlung des Signals vom Computer an den Makler zeitgleich mit der Übermittlung eines Handelsauftrags erfolgen soll (und was zu tun ist, wenn es sich um einen schwebenden Auftrag handelt???).
In diesem Fall (31 Sekunden) würde es ausreichen, die Aufrufzeit jeder OnTradeTransaction zu sehen. Ich bin sicher, dass die Bestätigung des Handelsservers, dass der Antrag auf Löschung des Auftrags angenommen wurde, fast sofort erfolgte.
Als Nächstes betrachten Sie die Schlusszeit nach Historie (nicht nach OnTradeTransaction). Der Unterschied zwischen diesen beiden Zeiten beträgt wahrscheinlich 31 Sekunden. Damit wird zu 100 % festgestellt, dass die Verbindung Client<->Terminal nichts mit den Bremsen zu tun hat.
Was wollen Sie mit der "Zeit" anfangen, wenn der vorherige Befehl in 6 ms ausgeführt wurde und der folgende auch!
Ein einfaches Beispiel. Ich surfe im Internet. Plötzlich wird das Internet furchtbar langsam. In einer Minute ist sie wiederhergestellt. Dafür kann es viele Gründe geben: WiFi fällt aus - ein neues Gerät mit inkompatiblem Standard wird angeschlossen (ich habe ein Telefon, das meinen Router beim ersten Mal, wenn ich mich mit dem Heim-WiFi verbinde, abschaltet und ich muss den Router neu starten), oder das Signieren von Routern nach dem Heim-Router...
Ein einfaches Beispiel. Ich surfe im Internet. Plötzlich wird das Internet schrecklich langsam. Nach einer Minute ist es wieder da. Dafür kann es viele Gründe geben: WiFi ist fehlerhaft - ein neues Gerät mit einem inkompatiblen Standard ist angeschlossen (ich persönlich habe ein Telefon, das den Router beim ersten Mal, wenn es sich mit meinem Heim-WiFi verbindet, abschaltet, und ich muss den Router neu starten), oder das Signieren von Routern nach dem Heim-Router...
Sie müssen nicht im Internet surfen, es ist ganz einfach hier
Wenn Aufträge asynchron gesendet werden, ergibt sich folgendes Bild:
Zeigt an, dass der Auftrag vom Terminal an den MT5-Server gesendet wurde.
Zeigt an, dass der MT5-Server einen Auftrag erhalten hat
2018.02.15 10:01:25.711 Trades 'ххххх': cancel order #84312120 sell limit 2.00 MOEX-6.18 at 11557 placed for execution in 31407.470 ms
Bedeutet, dass der Server den Auftrag an die Börse gesendet hat.
Die Antwort von der Börse kommt sofort in OnTradeTransaction und das Terminal selbst gibt KEINE Nachricht aus!
Hinzugefügt
Hier ist die Antwort des SD von vor einem Jahr:
Die asynchrone Methode erwartet oder überwacht nicht das Ergebnis des Vorgangs (Auftragserteilung), sondern nur die Tatsache des Sendens und protokolliert es daher nicht.
Schauen Sie sich noch einmal die vorherigen und nachfolgenden Befehle an
Es ist natürlich möglich, dass es ein Netzwerkproblem ist, aber es ist nicht MEIN Problem, sondern das des Brokers.
Denn es wiederholt sich Tag für Tag, nach der Installation des neuen Build 1755 und genau zu Beginn der morgendlichen Sitzung.
Hinzugefügt
Was das Internet betrifft.
Diese Protokolle wurden vom Terminal aus erstellt, das über OnLime (100 mbps) funktioniert.
Dies sind die Protokolle des Terminals, das über MGTS (200 Mbit/s Glasfaser) funktioniert.
Das Protokollfragment hat die gleiche Zeit wie das andere Terminal, und das Ergebnis ist das gleiche:
Was meinen Sie dazu?
Anfrage an Opener für Serverprotokolle zu Auftrag#84312120
Ich habe diese Protokolle
Aus meinen und Serverprotokollen geht hervor:
Terminal-Berichte:
2018.02.15 10:00:54.309 Trades 'xxxxxx': storniere Order #84312120 Verkaufslimit 2.00 MOEX-6.18 bei 11557
Server:
2018.02.15 10:01:25.239 * 'xxxxxx': Stornierung des Auftrags #84312120 Verkaufslimit 2.00 MOEX-6.18 at 11557 (11002 / 11221 / 11200)
D.h. vom Zeitpunkt der Auftragserteilung durch das TERMINAL bis zur Annahme des Auftrags durch den SERVER sind 31 Sekunden vergangen.
Das Problem könnte also sein:
1. Im Terminal (es wurde gesagt, dass eine Bestellung gesendet wurde, was aber nicht der Fall war), was ich SEHR bezweifle.
2. DieProvidervon OPENoder das interne Netzwerk von OPEN funktionieren nicht richtig.
3. Die Bedienung stellte MEINE Bestellung in die Warteschlange und die Wartezeit betrug 31 Sekunden.
Mein Internet ist aus dem im obigen Beitrag genannten Grund VOLLSTÄNDIG ausgeschlossen.
Ich habe meine Schlussfolgerungen an den Makler geschickt und warte auf eine Antwort...
Das Problem könnte also sein:
1. Im Terminal selbst (es sagte, dass eine Bestellung gesendet wurde, was aber nicht der Fall war), was ich SEHR bezweifle
Nein.
2. DieProvidervon OPENoder das interne Netzwerk von OPEN funktionieren nicht richtig.
Nein.
3. Die Bedienung stellte MEINE Bestellung in die Warteschlange und die Wartezeit betrug 31 Sekunden.
Ja.
Imho hat der Eröffner die Ausführung Ihrer Bestellung nur verzögert, das ist alles... welche technischen Probleme kann es im Zeitalter des entwickelten Sozialismus geben? Lustig :-))
Hochfrequenzhandel? Sendet der Roboter häufig Aufträge an den Server?