MT5 und Geschwindigkeit in Aktion - Seite 45
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
Nein, ich habe Virtualisierer, die auf CentOS laufen. Aber ich bin nicht befugt, diesen Dialog fortzusetzen.
Es ist sowieso eine doppelte Virtualisierung.
CentOS -> VirtualBox -> Windows 7
Auch das Reduzieren auf 2 Kerne, wenn die CPU 8 Kerne hat, verändert das Verhalten und die zugewiesenen Ressourcen des Threadhedulers drastisch.
Diese 2 Kerne müssen den unvermeidlichen 1000 Threads zugewiesen werden, selbst bei einem verkürzten Windows 7. Das Terminal hat also garantiert eine höhere Latenzzeit.
Sie sind ein Meister darin, Stresstests durchzuführen, ohne auf Korrelation und Angemessenheit zu achten.
Natürlich erfordert die Mikrosekundenmessung Ressourcen, um Lücken von 1000 Mal weniger als einer Millisekunde messen zu können.
Wenn Sie gelegentlich Intervalle sehr genau messen müssen, dann verwenden Sie Mikrosekunden. Und es kostet Sie 0 Mikrosekunden.
Wie kann man Mikrosekunden nutzen, wenn sie einen ausbremsen?! Hier gibt es insgesamt 20 Anrufe. Eine Viertelmillisekunde für eine so lächerliche Anzahl von Aufrufen für verschiedene praktische Aufgaben.
Auf einem unterdrückten VPS ist die Übertaktung des Systemtimers über timeBeginPeriod mit Gefahren verbunden. Sie erhöhen lediglich den CPU-Overhead:
Andernfalls hätten Sie GetTickCount/GetTickCount64 schon längst im Betriebssystem genau gemacht und sich über die kostenlose Genauigkeit gefreut. Aber nein, Sie müssen für die Genauigkeit dieses Zeitmessers bezahlen.
GetTickCount ist in seiner Geschwindigkeit in keiner Weise unterlegen. Ich bin dazu übergegangen, es auf einem langsamen VPS anstelle von GetMicrosecondsCount zu verwenden. Die Belastung ist von 50 % auf 2 % bei einem echten Handel gesunken.
Wie kann man Mikrosekunden verwenden, wenn es die sind, die sich verlangsamen?! Hier sind nur 20 Anrufe. Eine Viertelmillisekunde für eine so lächerliche Anzahl von Aufrufen für verschiedene praktische Aufgaben.
Und ich habe diese 20 Anrufe:
GetTickCount ist in seiner Geschwindigkeit in keiner Weise unterlegen. Ich bin dazu übergegangen, es auf einem langsamen VPS anstelle von GetMicrosecondsCount zu verwenden. Die Belastung ist von 50 % auf 2 % bei einem echten Handel gesunken.
Ich glaube nicht, dass das Ersetzen von GetMicrosecondsCount -> GetTickCount in einem echten Programm ergeben wird. Sowohl theoretisch als auch praktisch gibt es keine Beweise.
Bei einem Stresstest für diese beiden Funktionen kann man leicht zu einem solchen Ergebnis kommen. Schließen Sie selbst darauf, dass 48 % der CPU-Last in Mikrosekunden gemessen wurden? Und das ist kein Stresstest? Natürlich ist sie das.
Was die Multimedia-Timer-Beschleunigung betrifft, so handelt es sich dabei wieder um Stresstests, ohne dass die Gesamtleistungseinbußen berücksichtigt werden. Die Übertaktung des Task-Shufflers erhöht den System-Overhead des Betriebssystems.
Immer noch duale Virtualisierung.
CentOS -> VirtualBox -> Windows 7
Auch die Reduzierung auf 2 Kerne bei einer CPU mit 8 Kernen verändert das Verhalten und die zugewiesenen Ressourcen des Threadshedulers drastisch.
Diese 2 Kerne müssen den unvermeidlichen 1000 Threads zugewiesen werden, selbst bei einem verkürzten Windows 7. Das Terminal hat also garantiert eine höhere Latenzzeit.
Zu diesem Schluss bin ich auch gekommen, danke für die Bestätigung.VirtualBox ist böse.
Und vor allem hüten Sie sich vor vps, auf einer solchen Bereitstellung, es gibt viele von ihnen.
Nur reine Betriebssystem auf Hardware, und vorzugsweise Linux.
Obwohl durch Wein, gleiche Virtualisierung, aber GUI des Terminals nur fliegt ohne eine einzige Verzögerung.
Und GetMicrosecondsCount läuft ohne jede Verzögerung.
Und ich habe diese 20 Anrufe:
Nun, für mich sind das auch null Mikrosekunden! Nur auf meinem Heimcomputer.
Ich glaube nicht, dass das Ersetzen von GetMicrosecondsCount -> GetTickCount in einem echten Programm ausreicht. Sowohl theoretisch als auch praktisch gibt es keinen Beweis.
Im Stresstest können Sie solche Fehler mit diesen beiden Funktionen leicht zeichnen. Schließen Sie selbst darauf, dass 48 % der CPU-Last in Mikrosekunden gemessen wurden? Und das ist kein Stresstest? Natürlich ist sie das.
Dieser Thread hat mich dazu veranlasst, eine Benchmark-Bibliothek zu schreiben, so dass ich einfach eine Laufzeitprüfung in den Quellcode einfügen kann. Und das hat sie ausgiebig genutzt, indem sie viel Schlechtes aufgedeckt und beseitigt hat.
Ein so geschriebener Expert Advisor (genauer gesagt 20 Expert Advisors parallel) belastet einen Heimcomputer um 1,5 %. Aber die VPS ist 50+%. Als ich anfing zu recherchieren, sah ich, dass der Mikrosekunden-Timer langsamer wird. Dementsprechend schlägt der VPS fehl, wenn auf den Heimcomputern keine Alarme generiert wurden.
Aber selbst das war nicht genug. Dank dieses Zweigs wurde ein Schnappschuss-Mechanismus entwickelt, der auf folgendem beruht.
Dies ist die Grundlage für alle Schnappschüsse: Wenn seit dem letzten Schnappschuss weniger als die angegebene Zeit vergangen ist, wird nichts unternommen. Mit diesem Ansatz können Sie erheblich Ressourcen einsparen.
Natürlich ist die Aktualisierungszeit kurz - standardmäßig beträgt sie eine Millisekunde. Aus diesem Grund wird ein Mikrosekunden-Timer verwendet.
Die Langsamkeit dieses Zeitgebers führte dazu, dass der Schnappschuss-Mechanismus zusammenbrach, da ein vollwertiger Schnappschuss etwa doppelt so oft benötigt wurde wie auf einem vollwertigen Rechner.
Das sind die Tücken der Mikrosekunden-Timer-Bremsen. Aber als ich auf Millisekunden-Timer (anstelle von 16ms) umgestellt habe, fing alles an zu fliegen, sogar auf einem langsamen VPS.
Was die Multimedia-Timer-Beschleunigung betrifft, so handelt es sich wieder um Stresstests ohne Rücksicht auf die Gesamtleistung. Die Übertaktung des Taskmasters erhöht den System-Overhead des Betriebssystems.
Wer kümmert sich schon um diese Theorien, wenn die Gewinne in der Praxis kolossal sind. Vielleicht sind einige Spiele davon betroffen. Aber auf VPS war es ein rettender Strohhalm.
Nun, für mich sind es auch null Mikrosekunden! Nur auf meinem Heimcomputer.
Dieser Thread hat mich dazu veranlasst, eine Benchmark-Bibliothek zu schreiben, so dass ich einfach eine Laufzeitprüfung in den Quellcode einfügen kann. Und das hat sie ausgiebig genutzt, indem sie viel Schlechtes aufgedeckt und beseitigt hat.
Ein so geschriebener Expert Advisor (genauer gesagt 20 Expert Advisors parallel) belastet einen Heimcomputer um 1,5 %. Aber die VPS ist 50+%. Als ich anfing zu recherchieren, sah ich, dass der Mikrosekunden-Timer langsamer wird. Dementsprechend schlägt der VPS fehl, wenn auf den Heimcomputern keine Alarme generiert wurden.
Aber selbst das war nicht genug. Dank dieses Zweigs wurde ein Schnappschuss-Mechanismus entwickelt, der auf folgendem beruht.
Dies ist die Grundlage für alle Schnappschüsse: Wenn seit dem letzten Schnappschuss weniger als die angegebene Zeit vergangen ist, wird nichts unternommen. Mit diesem Ansatz können Sie erheblich Ressourcen einsparen.
Natürlich ist die Aktualisierungszeit kurz - standardmäßig beträgt sie eine Millisekunde. Aus diesem Grund wird ein Mikrosekunden-Timer verwendet.
Aufgrund der Langsamkeit dieses Zeitgebers stürzte der Snapshot-Mechanismus ab, da der vollwertige Snapshot viel häufiger erstellt wurde als auf einem vollwertigen Rechner.
Das sind die Tücken der Bremsen des Mikrosekunden-Timers. Aber als ich auf Millisekunden-Timer (statt 16ms) umstellte, begann alles zu fliegen, sogar auf langsamen VPS.
Diese Theorien sind mir egal, solange der praktische Nutzen enorm ist. Vielleicht sind einige Spiele davon betroffen. Aber auf VPS war es ein rettender Strohhalm.
Sehen Sie, wie schön das gesagt wurde:
Ich bin dazu übergegangen, es auf einem langsamen VPS anstelle von GetMicrosecondsCount zu verwenden. Die Belastung sank von 50 % auf 2 % im realen Handel.
Die Schlussfolgerung war unausweichlich: "Alles wegen der Mikrosekunden-Dosierbremsen, das ist es, was die Beschleunigung ausmacht".
Und plötzlich stellt sich heraus: "Ich selbst habe aufgrund eines logischen Fehlers Berechnungen um eine Größenordnung größer angestellt". Und GetMicrosecondsCount war nur ein Auslöser für diesen Fehler.
Die Überarbeitung von GetTickCount ist ein Fix/Crack für diesen Fehler und der Code des Fixes wurde nicht gezeigt. Weil es nicht nur ein Ersatz von GetMicrosecondsCount -> GetTickCount ist?
Warum konnte das nicht gleich gesagt werden?
Die Logik scheint durch das offensichtliche Bootstrapping der Buchführung (Sprung von Mikrosekunden auf Millisekunden) und die mehrfache Reduzierung der Erstellung von Schnappschüssen beschleunigt worden zu sein.
Dies ist auf einer Maschine, die 20 EAs mit 1,5% CPU mahlt. Der LatencyMon zeigt, dass alles in Ordnung ist.
Irgendetwas in der MT5-Architektur verursacht diese Verzögerungen bei allen laufenden EAs zur gleichen Zeit. Und keine für mich.
Die Umwandlung in GetTickCount ist ein Fix/Crack für diesen Fehler, und der Fix-Code wurde nicht gezeigt. Weil es nicht nur ein Ersatz von GetMicrosecondsCount -> GetTickCount ist?
Warum konnte das nicht gleich gesagt werden?
Diskussionen mit mir zeichnen sich jedoch durch die Präsenz des Gezeigten aus. Nichts wird versteckt, im Gegenteil, es wird offen veröffentlicht.
Es gibt sicherlich einen Stresstest. Es gab keine andere Möglichkeit, es visuell darzustellen.
Stellen Sie sich eine Funktion in Form einer Matrjoschka-Puppe vor. Die äußere Matrjoschka wird ausgemessen. Gleichzeitig werden auch die internen Schachtelpuppen vermessen. Infolgedessen zeigen die externen verschachtelten Puppen aufgrund der Mikrosekunden-Bremsung wilde Zahlen bei ihren Ausführungszeiten, was zu einer Flut von Ein-Typ-Warnungen führt. Offensichtlich sind 10 Mikrosekunden für einen Aufruf von GetMicrosecondsCount furchtbar teuer. Also habe ich die Benachrichtigungen übereilt.
Der freie, grobe Millisekunden-Timer begann entweder 0µs, 1000µs oder 2000µs auszugeben. Dadurch wurde die Anzahl der Warnmeldungen und die Bremswirkung bei Aufrufen von Zeitgeberfunktionen erheblich reduziert.
Und mit Schnappschüssen ist es großartig. Das Loadout ist im Vergleich zum Heimcomputer (dort in Mikrosekunden) nicht großartig. Aber wenn man es mit dem vergleicht, was auf VPS war, ist es wie Himmel und Erde.
SZZ sprechen wir jetzt über die Möglichkeit, in MQL Millisekunden-Timer zu haben, die es leider nicht gibt. Sie können keinen Snapshot auf VPS ohne ihn erstellen.
Ich denke immer noch über den SymbolInfoTick-Snapshot nach, um diese Art von Dingen zu vermeiden.
Dies ist auf einer Maschine, die 20 EAs mit 1,5% CPU mahlt. Der LatencyMon zeigt, dass alles in Ordnung ist.
Irgendetwas in der MT5-Architektur verursacht diese Verzögerungen bei allen laufenden EAs zur gleichen Zeit. Und keine für mich.
Hier ist mein Code und stabile Reaktionszeit: keine Hunderte oder Tausende von Mikrosekunden auf 20 Charts parallel
Wie viele Kerne haben Sie und welche Art von Prozessor? i7-2600?
Ein weiterer versteckter Stresstest mit Millionen von parallelen Anfragen?
Mehr Transparenz. Nur weil Sie ein paar einfache _B-Aufrufe gepostet haben, ist das kein Beweis für Ihre anderen Behauptungen. Sie vergessen plötzlich den Code und die eigentliche Beschreibung der Bedingungen, sobald Sie haarsträubende Behauptungen aufstellen.
Sie müssen sich nichts einbilden - erzählen und zeigen Sie, was Sie tatsächlich aufrufen und testen. Es handelt sich nicht um ein herausgerissenes Ergebnis, das besagt: "Ich habe einen unbekannten Stresstest durchgeführt und warte auf eine Meldung, um die Welt zu informieren", sondern um den vollständigen Code des Tests.
Es gibt auch Fragen zur Messbibliothek selbst. Es gibt viel Unnötiges, auch Gemeinkosten.
Wir sprechen jetzt über die Nützlichkeit eines Millisekunden-Timers in MQL, den es leider nicht gibt. Ohne sie kann man bei UPU keinen Schnappschuss machen.
Es gibt schon lange einen Millisekunden-Timer: EventSetMillisecondTimer()