Tiki in Echtzeit - Seite 17
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
SIND SIE SICH DA SICHER?
4 Sekunden ???? Das gibt's doch nicht! Glaubst du wirklich, dass der Prozessor 4 Sekunden lang eingefroren ist oder der Speicher 4 Sekunden lang freigegeben wird? Machst du Witze?
Wahrscheinlicher ist, dass es sich um die Schreibwarteschlange auf der Festplatte handelt.
Die Festplatte ist langsamer als der Speicher und der Prozessor.
Und dann flush() , es gibt einen solchen Befehl in der Sprache C, wahrscheinlich wissen Sie, es wird ausgeführt, wenn es bequem und komfortabel ist und kann mit einer gewissen Verzögerung öfter im Zusammenhang mit dem Laden der Festplatte ausgeführt werden.
So wird es genannt, wenn die Puffer auf die Festplatte zurückgesetzt werden müssen.
Nun, ich bin mir da nicht so sicher, da ich es nicht experimentell in MT überprüft habe. Aber es ist eine Art Standard - wozu gibt es in einem Protokoll die Zeit des Schreibens auf die Festplatte, wenn die Zeit des Ereignisses, das dieses Schreiben in ein Protokoll verursacht hat, wichtiger ist, ist das nicht logisch?
Und wenn wir davon ausgehen, dass das Protokoll auf die Festplatte geschrieben wird Schreibzeit, und wenn die Festplatte geladen ist, sowieso haben Sie eine Verzögerung in der physikalischen Aufzeichnung, und die Zeit wird das Senden eines Befehls zum Schreiben in den Schreibpuffer.
d.h. der Flush verändert den Puffer nicht - er setzt ihn nur etwas später zurück, wenn es eine Verzögerung gibt.
wp. zu Recht darauf hingewiesen, dass Sie die Zeit zu schreiben, weil in jedem Fall nur die Zeit, die das Terminal selbst beim Schreiben in das Protokoll bildet, gibt es keinen Sinn in der Orientierung.
Nun, ich bin mir da nicht so sicher, denn ich habe es in MT nicht experimentell überprüft. Aber es ist eine Art von Standard - warum im Protokoll die Zeit der Aufzeichnung auf der Festplatte, wenn wichtiger ist die Zeit des Ereignisses, das diese Aufzeichnung in das Protokoll, logisch verursacht?
Und wenn wir davon ausgehen, dass das Protokoll auf die Festplatte geschrieben wird Schreibzeit, und wenn die Festplatte geladen ist, sowieso haben Sie eine Verzögerung in der physikalischen Aufzeichnung, und die Zeit wird das Senden eines Befehls zum Schreiben in den Schreibpuffer.
d.h. der Flush verändert den Puffer nicht - er setzt ihn nur etwas später zurück, wenn es eine Verzögerung gibt.
s.s. zu Recht darauf hingewiesen, dass Sie die Zeit zu schreiben, weil in jedem Fall nur die Zeit, die das Terminal selbst beim Schreiben in das Protokoll bildet, gibt es keinen Sinn in der Orientierung.
Ich habe angenommen, dass die Zeit kurz vor dem Schreiben auf die Festplatte eingefügt wird, dann passt alles zusammen.
Lassen Sie uns versuchen, das Szenario Schritt für Schritt zu beschreiben - um es klarer zu machen
1-Das Häkchen kam (onTick drücken) - sollte gedruckt werden
2-And OnTick druckt ein Protokoll - es wurde erfolgreich gespeichert
3-Dieses Häkchen kommt auch bei OnTick an - es sollte ebenfalls gedruckt werden.
4 - Und jetzt kommt der Alptraum Windows spuckt in diesem Moment plötzlich 20 Datenströme von verschiedenen Programmen auf die Festplatte und sperrt die Festplatte vorübergehend -
Der Treiber hat seinen Datenmagnetkopf woanders hingelegt -) und schreibt seine eigenen Daten.
5 - Dies ist der Moment, in dem der Metatrader versucht, etwas an den DISK zu senden.
Aber die Festplatte ist furchtbar beschäftigt mit dem Windows-Betriebssystem - Das Betriebssystem sagt dem Metatrader, sorry MQ, ich habe Wichtigeres zu tun - warten Sie
6- 4 Sekunden vergehen.
7- und dann hat Windows nach 4 Sekunden - die Warteschlange zum Laufwerk geleert - und sagt zum MetaTrader - Dear trading terminal - you want to write something to disk? - Ok, schreib es!
8-metatrader schreibt mit einer Verzögerung von 4 Sekunden auf die Festplatte und zeichnet die ZEIT im Protokoll auf, nicht wann er Daten auf die Festplatte schreiben wollte - sondern wann er es tatsächlich getan hat.
Daher kommen auch die 4 Sekunden.
---
Jedes andere Szenario, z. B. wenn das Terminal die Ortszeit in den Puffer schreibt, aber der Schreibvorgang um 4 Sekunden verzögert wird, funktioniert nicht.
sonst wäre der Zeitpunkt übereinstimmend gewesen!
Nun, ich bin mir da nicht so sicher, denn ich habe es in MT nicht experimentell überprüft. Aber es ist eine Art von Standard - warum im Protokoll die Zeit der Aufzeichnung auf der Festplatte, wenn wichtiger ist die Zeit des Ereignisses, das diese Aufzeichnung in das Protokoll verursacht, logisch?
Und wenn wir davon ausgehen, dass das Protokoll auf die Festplatte geschrieben wird Schreibzeit, und wenn die Festplatte geladen ist, sowieso haben Sie eine Verzögerung in der physischen Aufzeichnung, und die Zeit wird das Senden eines Befehls zum Schreiben in den Schreibpuffer.
d.h. der Flush verändert den Puffer nicht - er setzt ihn nur etwas später zurück, wenn es eine Verzögerung gibt.
s.s. zu Recht darauf hingewiesen, dass Sie die Zeit zu schreiben, weil in jedem Fall nur die Zeit, die das Terminal selbst erzeugt, wenn das Schreiben in das Protokoll, gibt es keinen Sinn, sich auf.
Und wenn Sie das nicht überprüfen, dann schimpfen Sie nicht.
Wissen Sie überhaupt, worüber wir in diesem Thema sprechen?
Zeigen Sie mir den Test, oder verschwinden Sie von hier.
Nun, ich bin mir da nicht so sicher, denn ich habe es in MT nicht experimentell überprüft. Aber es ist eine Art von Standard - warum im Protokoll die Zeit der Aufzeichnung auf der Festplatte, wenn wichtiger ist die Zeit des Ereignisses, das diese Aufzeichnung in das Protokoll verursacht, logisch?
Und wenn wir davon ausgehen, dass das Protokoll auf die Festplatte geschrieben wird Schreibzeit, und wenn die Festplatte geladen ist, sowieso haben Sie eine Verzögerung in der physischen Aufzeichnung, und die Zeit wird das Senden eines Befehls zum Schreiben in den Schreibpuffer.
d.h. der Flush verändert den Puffer nicht - er setzt ihn nur etwas später zurück, wenn es eine Verzögerung gibt.
s.s. hat zu Recht angemerkt, dass man die Zeit schreiben muss, weil auf jeden Fall nur die Zeit, die das Terminal selbst beim Schreiben in das Log bildet, keinen Sinn macht.
Nur in unserem Fall bekommen wir die Zeit, um auf die Festplatte zu schreiben!
Aber die Zeit kann in der GetTickDescription-Prozedur eingestellt werden, ich habe dem Autor oben darüber geschrieben.
Und wenn er sie dort platziert hätte, hätten wir nicht in 4 Sekunden über die mögliche Ursache der Verzögerung diskutiert. Im Protokoll wäre höchstwahrscheinlich die Ortszeit für OnBock und OnTick gleich gewesen, aber die Zeit auf der Festplatte wäre um 4 Sekunden unterschiedlich gewesen.
Und wenn Sie es nicht überprüft haben, dann ist es Ihnen auch egal.
Haben Sie eine Ahnung, worum es in diesem Thema geht?
Zeigen Sie mir den Test, oder verpissen Sie sich von hier.
Seien Sie nicht so streng mit mir.
Es ist möglich, dieses Tick-Catching zu verbessern, es für eine oder zwei Wochen einzustellen und vielleicht den Moment zu erwischen, in dem das Datum der Aufzeichnung im Protokoll mit dem Datum des Ereignisses übereinstimmt.
Natürlich ist es möglich, diesen Vorgang zu beschleunigen, indem man regelmäßig einen Datenträger für die Aufnahme lädt.
Eine andere Frage, die wichtigste: Warum sollte man mit dieser Forschung Zeit verschwenden?) Was ist der praktische Nutzen?
---
Zur Zeit ist es klar, dass Ticks zuerst in OnTick kommen und erst dann in OnBuk, das Schöne ist, dass OnBuk nicht nur bei Ticks aufgerufen wird, sondern z.B. bei Volumenänderungen am Markt, d.h. jemand hat eine Order eröffnet, geschlossen oder gelöscht, das Volumen hat sich geändert. Und das ist eine ganz wichtige Information für den Markt.
Und natürlich nach der Logik der Handelsentscheidungen auf dem Markt der Aktien / Futures logisch, genau in OnBuk zu nehmen, und nicht in OnTick.
Und wenn Sie es nicht überprüft haben, dann ist es Ihnen auch egal.
Haben Sie eine Ahnung, worum es in diesem Thema geht?
Zeigen Sie mir den Test, oder verpissen Sie sich von hier.
Du bist derjenige, der kläfft, Dick, 16 Seiten haben nicht daran gedacht, das Ereignis vor dem Druck zu messen und die Geschwindigkeit zu schreiben, die sie messen, Experten, verdammt).
Das, worauf Sie mich so stolz hingewiesen haben, sagen sie, ich habe es nicht überprüft, Sie verstehen nicht einmal wirklich, wovon ich rede, wette ich. Aber es ist unwahrscheinlich, dass Sie es verstehen werden.
Und die Tatsache, dass dieser Zeitpunkt nicht genau der Zeitpunkt der Aufzeichnung auf der Festplatte ist, wird überprüft.
Und wenn Sie es nicht überprüft haben, dann ist es Ihnen auch egal.
Haben Sie eine Ahnung, worum es in diesem Thema geht?
Zeigen Sie mir den Test, oder verpissen Sie sich von hier.
Wie wäre es damit, Klugscheißer, zeige mir wenigstens einen glaubwürdigen Weg, um zu testen, worauf du hinauswillst, und ich werde aussteigen und zugeben, dass ich es nicht verstanden habe, andernfalls gibst du zu, dass du es selbst nicht verstehst, entschuldigst dich oder steigst selbst aus.
Nämlich - mindestens eine 100% zuverlässige Möglichkeit, experimentell zu überprüfen, welche Zeit das Terminal in das Protokoll schreibt, nämlich die Hauptoptionen:
1. die Zeit, zu der das Terminal den Druckbefehl in der Warteschlange erhält.
2. Zeitpunkt des Starts des Druckbefehls.
3. Zeitpunkt der Beendigung des Drucks im Puffer).
Diese Variante kann der genaue Zeitpunkt sein:
4. Zeitpunkt der Druckausführung auf der Festplatte.
Wie wäre es damit, Klugscheißer, du zeigst mir wenigstens einen zuverlässigen Weg, um zu überprüfen, worauf du hinauswillst, und ich werde aussteigen und zugeben, dass ich es nicht verstanden habe, andernfalls gibst du zu, dass du es selbst nicht verstehst, entschuldigst dich, oder steigst selbst aus.
Nämlich - mindestens eine 100% zuverlässige Möglichkeit, experimentell zu überprüfen, welche Zeit das Terminal in das Protokoll schreibt, nämlich die Hauptoptionen:
1. die Zeit, zu der das Terminal den Druckbefehl in der Warteschlange erhält.
2. Zeitpunkt des Starts des Druckbefehls.
3. Zeitpunkt der Beendigung des Drucks im Puffer).
Diese Variante kann der genaue Zeitpunkt sein:
4. die Ausführungszeit des Ausdrucks auf die Festplatte.
Was ist also der Grund?
Ich warte auf deinen Code...
Worum geht es also?
Ich warte auf deinen Code...
Auf welchen Code warten Sie noch? Habe ich Ihnen etwas versprochen? Wie hoch war der Preis noch mal?)
p/s/ Auch Sie haben, wie Ihr Freund, nicht verstanden, wovon ich spreche.Während der Debatte habe ich ein weiteres Experiment durchgeführt.
Ich meine, bei der Initialisierung wird die Zeit um eine Mikrosekunde verkürzt,
und vor jedem Druck bohre ich die Zeit erneut.
Idealerweise sollte es so sein
Aber sehr oft sieht es so aus (Log-Belichtungen):
Die Ortszeit wird also in den Ausdruck geschrieben, wenn der Ausdruck aufgerufen wird.
Aber das passt nicht zu den 4 Sekunden...