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
Aber wenn ich mir das Protokoll ansehe, zeigt es denselben Tick mit einem Unterschied von 4 Sekunden.
p.s.
Ich hasse die Phrase "das kann nicht sein", ich habe mich an den Gedanken gewöhnt, dass alles möglich ist.
Übrigens, vielleicht ist es weit von dem Thema, aber einmal auf die Behauptung, dass die Erde rund ist, sagte auch etwas wie dieses - "es kann nicht sein.
Im Allgemeinen bin ich immer im Zweifel, bis ich es überprüfe und dann noch einmal überprüfe, und vorzugsweise jemand anderes überprüft es ein paar Mal.
Sind Sie sicher, dass Sie den Code, der das Protokoll generiert und die Daten verarbeitet, nicht vermasseln? Der Unterschied liegt bei 4 Sekunden.
Die Ticks befinden sich bereits im Terminal, d. h. sie wurden bereits über das Netz gesendet.
Den Code der Öffentlichkeit zugänglich machen
Und sehen Sie selbst.
Die Tics befinden sich bereits im Terminal, d.h. sie wurden bereits über das Netz übertragen.
Fügen Sie den Open-Access-Code ein
Und sehen Sie selbst.
Danke, ich werde es ausprobieren, ich verfolge das Thema schon lange, ich bin eher als Forscher interessiert.
dieser Code 4 Sekunden lang verzögert?
Das scheint nicht der Fall zu sein.
ich sehe OnTick nicht im Code
Offenbar handelte es sich um den folgenden Code
Ich habe dem Code meine Zeit hinzugefügt.
Ich erinnere mich an die Zeit, als OnTick() ausgelöst wurde(t_time = GetMicrosecondCount();)
Dann nehme ich mir Zeit, wenn jede Funktion ausgeführt wird
Das Ergebnis ist
D.h. die Laufzeit der einzelnen Funktionen beträgt weniger als 50 Mikrosekunden!
Woher können 4 Sekunden kommen?
Ich glaube, es liefen zwei EAs in einem Terminal und das Terminal hat einfach keine Zeit, um
Es hat einfach keine Zeit, alle Informationen in einem Protokoll "zusammenzuführen", also stellt es die Ortszeit so ein, wie es sie für notwendig hält.
Beim Handel verwende ich persönlich asynchrone Aufträge.
Die Sache ist die (wenn Sie ernsthaft an der Börse handeln), müssen Sie alle Änderungen auf dem Aktienmarkt,
und je früher dieses Ereignis eintritt, desto besser.
Ich für meinen Teil sehe keine Alternative zu OnBook
Prinzipiell ist es möglich, den direkten Aufruf von Handelsoperationen aus OnBook herauszulösen. Alles, was Sie in OnBook tun müssen, ist ein Flag zu bilden, um die Operation auszuführen und das Flag selbst an anderer Stelle zu verarbeiten. Das heißt, die Operation selbst sollte in einer anderen Prozedur durch die Flagge gebildet, die ein Ereignis zu schaffen, aber nach dem Verlassen der Prozedur HeBook, und dann den Code OnBook selbst wird frei von schweren Operationen gestartet werden. Wenn die Aufträge jedoch asynchron geöffnet werden und die Verarbeitung der Bedingungen nicht wahnsinnig umfangreich ist, ist es unwahrscheinlich, dass es zu erheblichen Verzögerungen kommt.
Ich habe dem Code meine Zeit hinzugefügt.
Ich erinnere mich an die Zeit, als OnTick() ausgelöst wurde(t_time = GetMicrosecondCount();)
Dann nehme ich mir Zeit, wenn jede Funktion ausgeführt wird
Das Ergebnis ist
D.h. die Laufzeit der einzelnen Funktionen beträgt weniger als 50 Mikrosekunden!
Woher können 4 Sekunden kommen?
Ich glaube, es liefen zwei EAs in einem Terminal und das Terminal hat einfach keine Zeit, um
Das Terminal hat einfach keine Zeit, alle Informationen in eine Protokolldatei zu "dumpen", und deshalb stellt es die Ortszeit so ein, wie es sie für notwendig hält.
Ich schätze, es stimmt, dass eine solch wilde Verzögerung nicht realistisch ist.
1 - FLUSH hat funktioniert, wenn MQ es selbst entschieden hat!
2 - Technische Verzögerung beim Schreiben auf die Festplatte aufgrund von intensiver Arbeit auf der Festplatte
Es ist möglich, dass sich auf Ihrem lokalen Rechner bereits eine Warteschlange für Schreibvorgänge gebildet hat - was durchaus möglich ist, da ich die Erfahrung gemacht habe, dass mehrere Terabytes an Backups auf die Festplatte geflossen sind
Ich kann nur Folgendes vermuten:
Ich habe schon mehrere Terabytes an Backups auf die Festplatte geholt, z. B. wenn ich Microsoft Office ausgeführt, mein Windows aktualisiert und Filme aus dem Internet aufgenommen habe, oder wenn ich gleichzeitig mit MS SQL auf dem lokalen Rechner gearbeitet habe,
ein paar Backups machen, ein Dutzend 4 Torrents und zwei oder drei Dutzend Programme, die intensiv auf die Festplatte schreiben.
D.h. ich meine, wenn intensiv mit der Festplatte gearbeitet wurde - es ist möglich und es gab eine Verzögerung beim Schreiben des Protokolls auf die Festplatte.
Wahrscheinlich stimmt das, aber bei einer so großen Verzögerung ist das nicht realistisch.
1 - FLUSH funktionierte, als MQ dies von sich aus entschied!
2 - Technische Verzögerung beim Schreiben auf die Festplatte, verursacht durch intensive Arbeit auf der Festplatte.
Es ist möglich, dass sich Ihr lokaler Rechner bereits in einer Schreibwarteschlange befindet, was durchaus möglich ist. Ich habe die Erfahrung gemacht, dass mehrere Terabytes an Sicherungsdaten auf die Festplatte geschüttet wurden.
Ich kann nur Folgendes vermuten:
Ich habe schon mehrere Terabytes an Backups auf die Festplatte geholt, z.B. wenn ich Mac irosoft office laufen ließ, mein Windows aktualisierte und Filme aus dem Internet aufnahm, oder wenn ich gleichzeitig mit MS SQL auf dem lokalen Rechner arbeitete,
ein paar Backups machen, ein Dutzend 4 Torrents und zwei oder drei Dutzend Programme, die intensiv auf die Festplatte schreiben.
Ich meine, wenn intensiv mit der Festplatte gearbeitet wurde, ist es durchaus möglich, dass es eine Verzögerung bei der Protokollierung auf der Festplatte gab.
Ich habe dem Code meine Zeit hinzugefügt.
Ich erinnere mich an die Zeit, als OnTick() ausgelöst wurde(t_time = GetMicrosecondCount();)
Dann nehme ich mir Zeit, wenn jede Funktion ausgeführt wird
Das Ergebnis ist
D.h. die Laufzeit der einzelnen Funktionen beträgt weniger als 50 Mikrosekunden!
Woher können 4 Sekunden kommen?
Ich denke, dass zwei EAs in einem Terminal liefen und das Terminal einfach keine Zeit hat, um
"Daher stellt sie die Ortszeit so ein, wie sie es für notwendig hält.
Übrigens - damit Sie sich nicht in der Protokollierungszeit verheddern - können Sie die Ortszeit zu dem Array hinzufügen, das Sie im folgenden Code bilden
Dann gibt es im Protokoll einen deutlichen Unterschied zwischen dem Zeitpunkt, an dem das Terminal das Protokoll auf die Festplatte zurückgesetzt hat, und dem Zeitpunkt, an dem der Tick oder das Ereignis von OnBook lokal eingetroffen ist.
Und das ist vom Standpunkt der Forschung aus gesehen richtiger.
MT ist kaum mit der Festplatte verbunden und setzt die Zeit bereits beim Schreiben des Protokolls in seinen Cache. Das ist, was ich dachte, das Terminal im Allgemeinen für 4 Sekunden kann auf die gesamte Systemlast, sondern RAM und CPU bezogen werden.
SIND SIE SICH DA SICHER?
4 Sekunden ????, auf keinen Fall! Glauben Sie wirklich, dass der Prozessor 4 Sekunden lang eingefroren oder der Speicher 4 Sekunden lang freigegeben wurde?
Es ist wahrscheinlicher, dass es an der Schreibwarteschlange auf der Festplatte liegt.
Die Festplatte ist langsamer als der Speicher und der Prozessor.
Der flush()-Befehl ist ein C-Befehl, den Sie wahrscheinlich kennen und der ausgeführt wird, wenn es sich bequem anfühlt und der durch das Booten der Festplatte öfters verzögert werden kann.
So nennt man es, wenn man die Puffer auf die Festplatte auslagern will.