Fehler, Irrtümer, Fragen - Seite 2963

[Nikolai Semko]

fxsaber:

Indikator1 und Indikator2 müssen dann auf irgendeine Weise synchronisiert werden, damit beide Zahlen in dieselbe gemeinsame Zeile geschrieben werden können.

Dies ist eine sehr komplexe Lösung.

Warum sollten sie synchronisiert werden müssen? user32.dll erledigt das für sie.
Die Hauptsache ist, dass sie richtig nummeriert werden, so dass jede Nummer eine eindeutige Nummer hat und diese Nummer ein Index des Datenfeldes ist.
Dies kann als letzter Ausweg auch manuell erfolgen. Oder Sie können es automatisch tun. Übrigens habe ich kürzlich etwas Ähnliches in KB(Indicator Cases) veröffentlicht.
Was gibt es an Ressourcen nicht zu mögen? Ich denke, dass es innerhalb der Grenzen eines Terminals optimal ist. Bei der von mir vorgeschlagenen Variante über user32.dll (ich habe diese Variante vor etwa 10 Jahren implementiert, als ich noch jung war und mich mit Arbitrage beschäftigte) beträgt die Zugriffs- und Analysezeit etwa 50 Mikrosekunden (ich denke, sie kann um das 1,5- bis 2-fache beschleunigt werden). Ist es mit den Ressourcen langsamer?

[fxsaber]

Nikolai Semko:

Warum sollten sie synchronisieren müssen? user32.dll wird das für sie tun.

Versuchen Sie es zu schreiben. Vielleicht verstehen Sie die Aufgabe nicht ganz.

Warum mögen Sie die Ressourcen nicht? Ich denke, dass es innerhalb der Grenzen eines einzigen Terminals optimal ist. Die von mir vorgeschlagene Variante mit user32.dll (ich habe diese Variante vor etwa 10 Jahren implementiert, als ich mich in jungen Jahren mit Arbitrage beschäftigte) hat eine Zugriffs- und Parsingzeit von etwa 50 Mikrosekunden (ich denke, sie kann um das 1,5-2fache beschleunigt werden). Ist es mit den Ressourcen langsamer?

Unter idealen Bedingungen dauert das Auslesen auf einem Heimcomputer 100 Mikrosekunden. Ein Expert Advisor auf einem einzigen Tick kann hundertfaches Lesen verursachen. Es ist langsam.

Unter idealen Bedingungen wird GlobalVariableGet in 10 Mikrosekunden ausgeführt. Aber das ist kein Indikator, denn unter für mich neuen Kampfbedingungen ist sie eine schreckliche Bremse.

[Andrey Khatimlianskii]

fxsaber:

Dies ist HistoryTicks - das Auffangen aller Ticks für EAs. Daher ist EventChartCustom nicht geeignet, es hat seine eigene Warteschlange. Das Gleiche gilt für den Puffer.

Ich habe es auf EventChartCustom arbeiten. 99,8 % der Ticks werden innerhalb von 0,15 ms empfangen.

Forum zum Thema Handel, automatisierte Handelssysteme und Strategietests

EventChartCustom => Indikator ist zu langsam

Andrey Khatimlianskii, 2019.12.12 09:27

Hier sind die Statistiken für 9 Stunden Arbeit mit 5 Symbolen:

Windows 8.1 (build 9600) x64, IE 11, UAC, Intel Core i5-3570  @ 3.40 GHz, Memory: 6979 / 16346 Mb, Disk: 341 / 499 Gb, GMT+2

[USDCHF]: 22784 of 22833 (99.8 %) ticks were processed (0.14 ms delay in average), 49 (0.2 %) ticks were skipped (103.4 ms delay in average)
[EURUSD]: 22944 of 22974 (99.9 %) ticks were processed (0.16 ms delay in average), 30 (0.1 %) ticks were skipped (115.6 ms delay in average)
[USDCAD]: 15331 of 15347 (99.9 %) ticks were processed (0.13 ms delay in average), 16 (0.1 %) ticks were skipped (104.6 ms delay in average)
[EURCHF]: 22516 of 22571 (99.8 %) ticks were processed (0.13 ms delay in average), 55 (0.2 %) ticks were skipped (127.8 ms delay in average)
[EURAUD]: 66842 of 66924 (99.9 %) ticks were processed (0.13 ms delay in average), 82 (0.1 %) ticks were skipped (117.8 ms delay in average)
[GBPUSD]: 41393 of 41393 (100.0 %) ticks were processed (0.00 ms delay in average)
Total trade requests time: 4.280 sec

Der Expert Advisor bezog sich auf GBPUSD, so dass der native OnTick für ihn funktionierte.

Kein Fehler "Indikator ist zu langsam".

Im Gegensatz dazu ist der Prozentsatz der verpassten Ticks und die durchschnittliche Latenzzeit auf dem VPS von MQ viel höher (ich werde die Statistiken später veröffentlichen).
Und es gibt eine Menge "Indikator ist zu langsam"-Fehler.

Ich verstehe die Ursache für den Überlauf der Warteschlange nicht, denn der Expert Advisor verarbeitet die aufgelaufenen Ereignisse sofort (er kehrt einfach zurück).
Verarbeitet sie noch jemand?

[fxsaber]

Andrey Khatimlianskii:

Ich habe es aufEventChartCustom arbeiten. 99,8 % der Ticks werden innerhalb von 0,15 ms empfangen.

Ich sende Ticks aus dem Indikator über diese: sparam enthält MqlTick, lparam - Tick-Nummer.

Der Expert Advisor in OnChartEvent fängt diese Ticks auf. Und sie muss wissen, ob der aktuelle Tick der aktuellste ist oder nicht? Das heißt, gibt es eine Warteschlange mit Zecken oder ist sie leer?

Dazu liest er die Nummer (die Aufgabe besteht darin, diese Nummer zu lesen) des letzten vom Indikator gesendeten Ticks. Wenn das Häkchen die gleiche Nummer hat, ist die Warteschlange leer, und es kann mit den Häkchen gearbeitet werden.

Und während der Operation von OnTick, nach OrderSend ist es notwendig zu prüfen, ob der Indikator mehr Ticks gesendet hat. Dazu müssen wir wieder die Zahl aus dem Indikator ablesen. Und es kann mehr als hundert solcher Überprüfungen während eines OnTicks geben. Deshalb müssen wir schnell lesen.

[traveller00]

Innerhalb von 1 Terminal wird die schnellste winapi Speicherzuweisung (global innerhalb eines Prozesses) und verriegelte Funktionen wie https://docs.microsoft.com/ru-ru/windows/win32/api/winnt/nf-winnt-interlockedexchange sein.

Diese sind nicht blockierend, atomar und werden im Wesentlichen in einigen wenigen asm-Befehlen ausgeführt.

[fxsaber]

traveller00:

Innerhalb von 1 Terminal wird die schnellste winapi Speicherzuweisung (global innerhalb eines Prozesses) und verriegelte Funktionen wie https://docs.microsoft.com/ru-ru/windows/win32/api/winnt/nf-winnt-interlockedexchange sein.

Diese sind nicht blockierend, atomar und werden im Wesentlichen in einigen wenigen asm-Befehlen ausgeführt.

Nicht ohne ein Beispiel.

[traveller00]

fxsaber:

Dazu liest er die Nummer (die Aufgabe besteht darin, diese Nummer zu lesen) des zuletzt vom Indikator gesendeten Ticks. Wenn das empfangene Häkchen die gleiche Nummer hat, ist die Warteschlange leer, und Sie können mit einem Paket von Häkchen arbeiten.

Und während der Operation von OnTick, nach OrderSend ist es notwendig zu prüfen, ob der Indikator mehr Ticks gesendet hat. Dazu müssen wir wieder die Zahl aus dem Indikator ablesen. Und es kann mehr als hundert solcher Überprüfungen während eines OnTicks geben. Deshalb müssen wir sie schnell lesen.

Initialisierung.

1. Weisen Sie im ersten Thread (höchstwahrscheinlich dem schreibenden Thread) auf irgendeine Weise Speicher für die Variable mit der gewünschten Größe zu.

2. Senden Sie in den gewünschten Threads (Lese-Threads) die Adresse dieses Speichers.

Grundlegende Arbeit.

3. Der schreibende Thread initiiert InterlockedExchange oder InterlockedExchange64, je nach Größe der Variablen, um sie zu beschreiben.

4. Lesender Thread zieht z.B. InterlockedCompareExchange zum Lesen.

Fertigstellung.

5. Geben Sie den zugewiesenen Speicher frei, vorzugsweise in demselben Thread, der ihn zugewiesen hat.

Bei Bedarf kann dieser Vorgang für die Erstellung mehrerer Zähler wiederholt werden. Der Nachteil ist, dass Sie die WinAPI-Verbindung benötigen. Von den Merkmalen der zugewiesenen Speicheradresse sollte ausgerichtet sein, aber standardmäßig ist es in der Regel.

Die Arbeit erfolgt innerhalb eines Prozesses, der Speicher wird für die Threads eines Prozesses gemeinsam genutzt. Bei Bedarf gibt es weitere verriegelte Funktionen wie InterlockedDecrement, InterlockedAdd, usw.

Funktionen sind nicht blockierend, warten nicht auf irgendetwas, Automaten, sie werden in wenigen asm-Anweisungen ausgeführt.

P.S. Soweit ich mich erinnere, sind reguläre Lese- und Schreiboperationen über mov in Assembler ohnehin atomar. Und wenn der Compiler kein Chaos anrichtet (was er theoretisch nicht sollte), können wir versuchen, die Variable im zugewiesenen Speicher zu lesen und zu schreiben, und es wird atomar sein.

Wenn es für die Aufgabe geeignet ist, ist es unwahrscheinlich, dass es innerhalb eines Prozesses schneller sein wird. Für Interprozess wird der Schnellste ähnlich sein, aber mit gemeinsamem Speicher, in diesem Fall können Sie nicht ohne WinAPI tun.

[Roman]

fxsaber:

Dieses System scheint nicht zu funktionieren. Zeigen Sie bitte ein einfaches Beispiel.

Warum nicht praktikabel? Genau so sehe ich das auch. Das Getter-Setter-Prinzip.
Den Wert einer versteckten Variablen über eine Funktion ermitteln.
Wenn Sie die MqlTick-Struktur übergeben, definieren Sie Ihre Struktur mit den Feldern wie MqlTick, und fügen Sie Ihr Zählerfeld zur Struktur hinzu.
Und geben Sie diese Struktur von der Exportfunktion zurück.
Ein elementares Beispiel für den Indikator. Achten Sie nicht auf das Beispiel im Skript.

struct myMqlTick 
{ 
   datetime     time;          // Время последнего обновления цен 
   double       bid;           // Текущая цена Bid 
   double       ask;           // Текущая цена Ask 
   double       last;          // Текущая цена последней сделки (Last) 
   ulong        volume;        // Объем для текущей цены Last 
   ulong        count;  //Свой счётчик
   
}myStruct;

//--------------------------------------------------
myMqlTick GetTickStruct() export
{
   
   return(myStruct);
}

//+------------------------------------------------------------------+
//| Script program start function                                    |
//+------------------------------------------------------------------+
void OnStart()
{
   myStruct.time   = 0.0;
   myStruct.bid    = 0.0;
   myStruct.ask    = 0.0;
   myStruct.last   = 0.0;
   myStruct.volume = 0;
   myStruct.count  = 1;  //свой счётчик  
  
}
//+------------------------------------------------------------------+

Im Expert Advisor rufen Sie GetTickStruct auf und erhalten die gesamte Struktur mit Ihrem Zähler.

[fxsaber]

Roman:

Wenn Sie in Expert Advisor GetTickStruct aufrufen, erhalten Sie die gesamte Struktur mit ihrem Zähler.

Bitte schreiben Sie einen elementaren Zahlentransfer von Indikator zu EA.

[Roman]

fxsaber:

Eine elementare Zahlenübertragung von Indikator zu EA, bitte schreiben.

Ersetzen Sie die Struktur durch eine Variable ))