Merkmale der Sprache mql5, Feinheiten und Techniken - Seite 92

 
Slawa:
Wie groß ist die Wahrscheinlichkeit, dass sich die lokale Computerzeit zwischen zwei Aufrufen von GetMicrosecondsCount zur Messung der Zeit in Mikrosekunden ändert?

Nicht Null.

 
TheXpert:
Sehr konstruktive Diskussion )

Nur noch ein paar Kritzeleien dauerhaft entfernen und das war's.

Wir werden nicht länger diejenigen tolerieren, die sich auf das Embargo stürzen und versuchen, die Realität der WinAPI-Funktionen als Fehler zu bezeichnen und uns die Schuld zu geben. Es wird eindeutig mehr Konstruktives geben.

 
fxsaber:

Nicht Null.

Wie hoch ist die Wahrscheinlichkeit eines Zeitverlusts beim Client/Server-Austausch in Millisekunden? Wahrscheinlich mehr als die Wahrscheinlichkeit, dass sich die Ortszeit ändert.

 
Renat Fatkhullin:

Löschen Sie einfach ein paar weitere Schreiberlinge dauerhaft und das war's.

Wir dulden nicht länger diejenigen, die sich auf das Embargo stürzen und versuchen, die Realität als Fehler zu bezeichnen und uns die Schuld zu geben. Es werden eindeutig mehr sein.

leicht rechts vom Thema, in Richtung von OnTimer() )))

Ich weiß nicht mehr, wo ich gelesen habe, aber ein Vertreter von MQ schrieb, dass es möglich ist (für diejenigen, die einen starken Juckreiz haben ), das System auf eine Verzögerung von 1 ms umzustellen, und dann, wenn Sie EventSetMillisecondTimer(...) verwenden, wird OnTimer() auch mit einem Fehler von etwa 1 ms, aber nicht 16 ms funktionieren

Wenn ich richtig verstanden habe, arbeitet OnTimer() mit der Systemverzögerung, richtig?


ps. habe gestern eine Anfrage an servcie-desk geschicktUnprocessed,Started: 2018.07.30 12:52,#2117844, könntest du helfen sie zu bearbeiten, sie hängt seit gestern ))
 

OnTimer arbeitet mit dem Fehler des System-WinAPI-Timers, gesteuert durch die WinAPI-Funktion GetTickCount. Dies ist eine sehr schnelle und kostengünstige Art der Zeitmessung, die nur minimale Auswirkungen auf den zu messenden Prozess hat. Das bedeutet, dass er das Endergebnis nicht wesentlich beeinflusst.

Die Genauigkeit dieses Zeitgebers kann für das gesamte Betriebssystem verbessert werden, allerdings um den Preis eines erhöhten CPU-Verbrauchs und der zufälligen und massiven Auswirkungen der Masse der Programme, die zu starten beginnen

  • die Zeit genauer messen
  • weniger Zeit in Zetteln verbringen
  • einige Zeitüberschreitungen, die bei gewöhnlichen Fehlern funktionieren, entarten zu regelrechtem Fehlverhalten
  • Und einige weitere coole Glitches

Das Problem mit dem Windows-Systemtimer ist über 20 Jahre alt. Aber es ist gefährlich, das Verhalten und die Genauigkeit des Oldtimers zu verändern.

Deshalb werden seit langem neue, genauere Zeitmessmethoden eingeführt. Aber sie sind ressourcenintensiv und nicht als vollständiger Ersatz für den Oldtimer geeignet.

Unser Timer mit höherer Genauigkeit ist mit GetMicrosecondCount implementiert. Sie sollte bewusst und in dem Bewusstsein eingesetzt werden, dass sie mehr kostet als GetTickCount. Auch die Kosten für die Aufrufe von GetMicrosecondCount sollten bei einer genauen Zählung ausdrücklich berücksichtigt werden.

Es ist sehr einfach, sich selbst und andere zu täuschen, indem man den Timer falsch benutzt und den Benchmark nicht sauber hält.

 
Renat Fatkhullin:

Wir dulden nicht mehr, dass diejenigen, die sich in den Hinterhalt stürzen und versuchen, die Realität der WinAPI-Funktionen als Fehler zu bezeichnen und uns die Schuld zu geben. Es wird eindeutig mehr Konstruktives geben.

Sie können einfach in die Hilfe schreiben, dass GetMicrosecondsCount von der lokalen Computerzeit abhängt und unzureichend funktionieren kann, wenn es geändert wird. GetTickCount tut dies nicht.

Wenn Sie das Problem also auf unserer und auf Ihrer Ebene lösen müssen, sollten Sie es wahrscheinlich auf unserer Ebene tun.

Warum sollten Sie ein Verbot aussprechen?

 
Renat Fatkhullin:

OnTimer arbeitet mit dem Fehler des System-WinAPI-Timers, der über die WinAPI-Funktion GetTickCount gesteuert wird. Dies ist eine sehr schnelle und kostengünstige Art der Zeitmessung, die nur minimale Auswirkungen auf den zu messenden Prozess hat. Das bedeutet, dass er das Endergebnis nicht wesentlich beeinflusst.

Die Genauigkeit dieses Zeitgebers kann für das gesamte Betriebssystem verbessert werden, allerdings um den Preis eines erhöhten CPU-Verbrauchs und der zufälligen und massiven Auswirkungen der Masse der Programme, die zu starten beginnen

  • die Zeit genauer messen
  • weniger Zeit auf den Zetteln verbringen
  • einige Zeitüberschreitungen, die für normale Zeitüberschreitungen funktionieren, entarten zu regelrechtem Fehlverhalten
  • und einige coolere Pannen.

Das Problem mit dem Windows-Systemtimer ist über 20 Jahre alt. Aber es ist gefährlich, das Verhalten und die Genauigkeit des Oldtimers zu verändern.

Aus diesem Grund werden seit langem neue, genauere Zeitmessverfahren eingeführt. Aber sie sind ressourcenintensiv und nicht als vollständiger Ersatz für den Oldtimer geeignet.

Unser Timer mit höherer Genauigkeit ist mit GetMicrosecondsCount implementiert. Sie sollte bewusst und in dem Bewusstsein eingesetzt werden, dass sie mehr kostet als GetTickCount. Darüber hinaus sollten die Kosten für die Aufrufe von GetMicrosecondsCount bei genauer Zählung ausdrücklich berücksichtigt werden.

Es ist sehr einfach, sich selbst und andere zu täuschen, indem man den Timer falsch benutzt und den Benchmark nicht sauber hält.

Ups, das habe ich auch gedacht, nachdem der MQ-Vertreter über die Verringerung der System-Timer-Zeit geschrieben hat ))

Ich stimme also zu, dass es nicht notwendig ist, etwas in dieser Richtung zu ändern.

Übrigens, ich würde gerne wissen, ob irgendwelche Entwicklungen in RichtungReflexion wie in C# oder zumindest wie in Boost gemacht werden? zum Beispiel Serialisierung / Deserialisierung wäre bequemer zu implementieren

 
TheXpert:

Sie können einfach in die Hilfe schreiben, dass GetMicrosecondsCount von der lokalen Computerzeit abhängt und möglicherweise nicht ordnungsgemäß funktioniert, wenn es geändert wird. Und GetTickCount hängt nicht davon ab.

In der Hilfe steht: Die Funktion GetMicrosecondCount() gibt die Anzahl der Mikrosekunden zurück, die seit dem Start des MQL5-Programms verstrichen sind.

Das habe ich deutlich gesagt: die Anzahl der Mikrosekunden zu messen.

Das Problem der Messung im Mikrosekundenbereich kann ebenfalls gelöst werden, wenn auch auf eine etwas umständliche Weise.

Warum sollten wir sie verbieten?

Wir müssen sie verbieten.

Zunächst einmal gibt es kein Problem mit der Zeitmessung des Mikrosekunden-Timers. Zweitens: Manche Leute suchen nach einer Ausrede, um sich aufzuregen, und halten dann bis zum Schluss daran fest.

Noch einmal: Die Regeln haben sich geändert.

Es werden keine Beleidigungen oder "Du musst" mehr akzeptiert. Wir werden ohne Vorwarnung eine Razzia durchführen.

 
Renat Fatkhullin:

So steht es in der Hilfe: Die Funktion GetMicrosecondCount() gibt die Anzahl der seit dem Start des MQL5-Programms verstrichenen Mikrosekunden zurück.

Und es wird für die Funktion GetTickCount geschrieben:

Die Funktion GetTickCount() gibt die Anzahl der Millisekunden zurück, die seit dem Start des Systems vergangen sind.

Die Sätze sind fast identisch, aber eine Funktion hängt von der Ortszeit ab, die andere nicht. Wie soll man das erraten?

 
TheXpert:

Und es wird für die Funktion GetTickCount geschrieben:

Die Phrasen sind fast identisch, aber eine Funktion hängt von der Ortszeit ab, die andere nicht.

Dies ist die WinAPI.

Eine Erinnerung an die Verwendung von expliziten oder impliziten "sollte"-Sätzen. Die Verwendung von "metaquotes must" anstelle von "please consider" ist jetzt inakzeptabel.

Grund der Beschwerde: