MT5 und Geschwindigkeit in Aktion - Seite 69
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
Wie stellen Sie sich das vor - parallele Verarbeitung in einem Thread?
Eine Ereignisschleife.
Und im Allgemeinen ist es ein Problem des Entwicklers, warum alles in einem Thread ausgeführt wird.
Es stellt sich heraus, dass die Marktübersicht asynchron und die Handler in den Anwenderprogrammen synchron verarbeitet werden.
Es ist einfach chicardous, es gibt keine Worte.
Vielen Dank für das Feedback zu den Statistiken! Die OnTick/OnBook-Verzögerungen scheinen für alle da zu sein. Sleep(1) beträgt entweder 1 ms oder 15 ms. Es ist nicht klar, warum das so ist.
Alle scheinen OnTick/OnBook-Verzögerungen zu haben.
Ich denke, Sie wissen, dass OnTimer() nicht öfter als 10-16 Millisekunden aufgerufen werden kann. Es ist logisch anzunehmen, dass auch andere OnXXX-Funktionen nicht öfter aufgerufen werden. Vielleicht ist das der Grund für Ihre Verzögerungen?
Ich denke, Sie wissen, dass OnTimer() nicht öfter als 10-16 Millisekunden aufgerufen werden kann. Es ist logisch anzunehmen, dass auch andere OnXXX-Funktionen nicht öfter aufgerufen werden. Vielleicht ist das der Grund für Ihre Verzögerungen?
Nicht logisch, die Handler sind nicht an die GetTickCount-Zeitgeberfrequenz/Auflösung gebunden. Ereignisse werden sofort in dem Moment ausgelöst, in dem sie eintreten.
OnTimer ist auch nicht an einen 16ms-Fehler gebunden. In den allermeisten Fällen ist es einfach, einen 1 ms-Timer zu erhalten, es sei denn, der Computer ist tot und zu 100 % ausgelastet.
Das Problem mit fast allen Tests von fxsaber ist, dass er versucht, die Ausreißer einzelner Aufrufe zu messen, anstatt den Durchschnitt der Menge zu bilden, und dass er die Realität des Thread-Dispatchers nicht verstehen will.
Das hat er:
Methoden des Kampfes, um der Wiederholungszeit näher zu kommen:
Auf einem normalen VPS werden die Terminals (wie auch alle anderen Programme) daher immer unter unerwarteten Verzögerungen leiden. Je mehr billige/überverkaufte VPS, desto mehr Probleme.
Fragen Sie sich auf Ihrem VPS, ob SR-IOV aktiviert ist und ob es irgendwelche aktuellen (nur manuell installierten) speziellen Netzwerktreiber dafür gibt. In 99 % der Fälle nicht, da dies die Migration von Virtualisierungen über den Hardware-Zoo unterbricht. Und ohne sie sind zusätzliche Verzögerungen garantiert, einfach wegen der doppelten Übertragung/Verarbeitung von Netzwerkpaketen (auf dem Host und virtuell) und der erhöhten Anzahl von Unterbrechungen.
Unser VPS-Service ist dafür viel weniger anfällig, sowohl in Bezug auf die Architektur als auch auf die leichtgewichtigen Terminals ohne GUI.
Nicht logisch, Handler sind nicht an die GetTickCount-Zeitgeberfrequenz/-auflösung gebunden. Ereignisse werden sofort zum Zeitpunkt ihres Auftretens ausgelöst.
OnTimer ist auch nicht an den 16ms-Fehler gebunden. In den allermeisten Fällen ist es einfach, einen 1ms-Timer zu erhalten, es sei denn, der Computer ist tot und zu 100% ausgelastet.
Das Problem mit fast allen Tests von fxsaber ist, dass er versucht, die Ausreißer einzelner Aufrufe zu messen, anstatt den Durchschnitt der Menge zu bilden, und dass er die Realität des Thread-Dispatchers nicht verstehen will.
Das hat er:
Methoden des Kampfes, um der Wiederholungszeit näher zu kommen:
Auf einem normalen VPS werden die Terminals (wie auch alle anderen Programme) daher immer unter unerwarteten Verzögerungen leiden. Je mehr billige/überverkaufte VPS, desto mehr Probleme.
Fragen Sie sich auf Ihrem VPS, ob SR-IOV aktiviert ist und ob es irgendwelche aktuellen (nur manuell installierten) speziellen Netzwerktreiber dafür gibt. In 99 % der Fälle nicht, da dies die Migration von Virtualisierungen über den Hardware-Zoo unterbricht. Und ohne sie sind zusätzliche Verzögerungen garantiert, einfach wegen der doppelten Übertragung/Verarbeitung von Netzwerkpaketen (auf dem Host und virtuell) und der erhöhten Anzahl von Unterbrechungen.
Unser VPS-Service unterliegt ihm um Größenordnungen weniger, sowohl in Bezug auf die Architektur als auch auf die leichtgewichtigen Terminals ohne GUI.
Und nun stellen Sie sich vor, wie viel langsamer die Leistung von Benutzerprogrammen auf einer solchen optimierten Maschine wäre, wenn die Handler in Programmen asynchron ausgeführt würden.
Ich verstehe den Sinn eines Super-Upgrades und einer Super-Optimierung der Maschinenhardware nicht, wenn die Handler im Benutzerprogramm a priori synchron ausgeführt werden.
Für das Terminal selbst und sein Innenleben ist die oben beschriebene Optimierung vielleicht sinnvoll. Für Benutzer-Kampfprogramme bezweifle ich das.
Denn die aufeinanderfolgende Ausführung von Handlern im Benutzerprogramm reduziert das gesamte Potenzial einer superoptimierten Maschine.
Das Problem liegt nicht in der Hardware, sondern in der Architektur der internen Arbeit des Terminals.
Und nun stellen Sie sich vor, wie viel schneller die Programme des Benutzers auf einer solchen optimierten Maschine laufen werden, wenn die Handler in den Programmen asynchron ausgeführt werden.
Ich verstehe den Sinn eines Super-Upgrades und einer Super-Optimierung der Maschinenhardware nicht, wenn die Handler im Benutzerprogramm a priori synchron ausgeführt werden.
Für das Terminal selbst und sein Innenleben ist die oben beschriebene Optimierung vielleicht sinnvoll. Für Benutzer-Kampfprogramme bezweifle ich das.
Weil die aufeinanderfolgende Ausführung von Handlern im Benutzerprogramm das gesamte Potenzial einer super-optimierten Maschine reduziert.
Das Problem liegt nicht in der Hardware, sondern in der Architektur des internen Betriebs des Terminals.
Es wird keine Beschleunigung geben. Bitte reichen Sie Ihre Berechnungen, zumindest in ungefähren Zahlen, zum Nachweis einer mehrfachen Beschleunigung ein.
Ein Wettlauf um Ressourcen? Unkontrollierte Erstellung von neuen Threads? Konflikte wegen nichts?
Wollen Sie unerklärliche Verlangsamungen?
Bei dem ereignisbasierten Modell sind alle Ereignisse immer in Formation aufgetreten, eines nach dem anderen. Zerkaut - zerkaut.
Unser VPS-Service ist dafür viel weniger anfällig, sowohl in Bezug auf die Architektur als auch auf leichtgewichtige Terminals ohne GUI.
Wenn es bei Ihrem VPS-Service zu Verzögerungen kommt, werden Sie das ernst nehmen?
Wer VPS von MQ nutzt, möge bitte die Ergebnisse der folgenden Programme dort mitteilen.
Wenn es bei Ihrem VPS-Service zu Verzögerungen kommt - werden Sie das ernst nehmen?
Ich frage mich, wie oft ich Ihnen noch sagen muss, dass es bei so vielen (tausenden) Threads pro begrenzter Anzahl von Kernen unsinnig ist, überhaupt über die Stabilität der Zeitquantenzuweisung pro Thread zu sprechen.
Bei zufälligen Einzelproben beliebiger Befehle, einschließlich der einfachsten Assembler-Befehle wie inc eax, kommt es garantiert immer zu Fehlern . Dies ist architektonisch und physikalisch bedingt durch die "ehrliche Zuweisung von Zeitquanten von Tausenden von Threads an eine kleine Anzahl von Kernen".
Seien Sie nicht dumm und fangen Sie weiterhin einzelne Bursts pro Million Anfragen ab.
Hören Sie auf, dumm zu sein und fangen Sie weiterhin einzelne Ausreißer pro Million Abfragen.
Ich verstehe jetzt, was es mit den einzelnen Spikes auf sich hat, danke für die ausführliche Erklärung. Im Moment geht es nicht um SymbolInfoTick, sondern um eine andere Art von Verzögerung, die bei fast jedem Tick auftritt.