Mein Ansatz. Der Kern ist der Motor. - Seite 147

 

Im Allgemeinen ist das Problem fast gelöst.

  1. Jede Kopie des EA muss zwei eigene Ressourcen erstellen - eine, um Nachrichten an die Engine zu schreiben, die andere, um Nachrichten von der Engine zu lesen.
  2. Die Engine muss eine Schleife durch die Ressourcen ziehen, um festzustellen, wie viele Kopien des EA auf verschiedenen Paaren laufen.
  3. Die Engine erstellt eine dynamische Liste der laufenden EAs, durch die der Benutzer die Verbindungen wechseln kann.
  4. Als nächstes wird die Engine die Namen der Ressourcen für die Nachrichtenübermittlung und den Empfang von Nachrichten von EAs aufzeichnen.

  1. Jeder EA wird normal ausgeführt und schreibt seine Nachrichten auf die übliche Weise an die Engine. Die Engine liest diese Nachrichten nur, wenn sie mit diesem EA verbunden ist.
  2. Die Engine sendet bei einem Verbindungsereignis einen Befehl an den EA, und dieser schreibt einen individuellen Parameterkern in die Ressource.
  3. Die Engine wird diesen Kernel laden. Anschließend werden die Elemente der grafischen Benutzeroberfläche in einer Schleife neu gezeichnet, damit sie aktuelle Informationen enthalten.
  4. Danach schreibt die Engine ihre Nachrichten an den EA in ihrer Ressource, um Nachrichten zu empfangen.

Zurzeit greifen alle EAs über eine gemeinsame Ressource auf die Engine zu. Ziel ist es, dass jeder Berater über eine eigene Ressource für die Kommunikation mit dem Motor verfügt. Und die Engine wäre in der Lage, Ressourcen für verschiedene EAs neu zu verbinden.
 
Mich verwirrt die Tatsache, dass z. B. fünf Berater das volle Volumen an Arbeitspaketen übermitteln, wenn der Motor mit einem sechsten Berater läuft. Den anderen fünf sollte die Übermittlung von Arbeitsinformationen bis auf Weiteres untersagt werden. Sollen sie doch einfach "den Äther abhören".
 
Oleg Papkov:
Mich verwirrt die Tatsache, dass, sagen wir mal, 5 EAs die volle Menge an Arbeitspaketen übertragen, wenn der Motor mit einem sechsten läuft. Den anderen fünf sollte die Übermittlung von Arbeitsinformationen bis auf Weiteres untersagt werden. Sollen sie doch einfach "den Äther abhören".

Ich stimme zu. Das macht Sinn.

Sie funktionieren also normal, aber sie schreiben keine Nachrichten in die Ressource. Nur für eine Kopie des Parameterkerns. Wenn die Verbindung hergestellt ist, wird der Parameterkern in die Ressource geschrieben, und die Engine wird ihn laden. Sobald die Verbindung hergestellt ist, beginnt der Expert Advisor, Nachrichten für die Engine in die Nachrichtenressource zu schreiben.

 

Die Frage ist die nach dem Zusammenhang.

Die Engine stellt allen EAs eine kleine String-Adresse zur Verfügung. Der Kernel im EA mit der gleichen Erkennungsadresse wird abgerufen, und der normale Motoradministrationsvorgang beginnt automatisch. Wenn die Engine auf einen anderen EA umschaltet, schaltet sie den Kernel des EA, mit dem sie gerade gearbeitet hat, in den Zustand des Wartens auf Adressen um, genau wie die anderen EAs in diesem Moment. Zu diesem Zeitpunkt sind alle EAs getrennt und der Motor wartet auf die andere Adresse der EA, die der Motor benötigt.

Der Kernel des neuen EA antwortet und geht in den Zustand des Standardbetriebs über. Beim nächsten Mal fährt der Motor fort, die Ziellinie zu senden, und der Zustand des Wartens wird nicht geändert. Zusätzlich zum Standardaustausch muss der Expert Advisor eine Bewegung analysieren, um zu prüfen, ob das Ende der Arbeitslinie darin erscheint. Am Anfang von Austauschpaketen muss eine Zeichenkette stehen, die angibt, an wen ein Paket von der Engine adressiert ist. Dieser Kernel empfängt das Kontrollpaket und beginnt, Pakete seines Zustands mit einer bestimmten Frequenz zu senden.

Die anderen warten darauf, dass sie durch eine eindeutige Identifizierungszeichenfolge für jeden EA angesprochen werden. Beim Umschalten sendet der Motor dem aktuellen EA einen End-of-Life-String. Der EA hört auf, etwas zu senden und geht in den Zustand der Erkennung seiner eigenen Erkennungszeichenfolge über, was gleichzeitig der Beginn der Standardarbeit des Austauschs mit dem Motor ist.

 
Oleg Papkov:

Die Frage ist die nach dem Zusammenhang.

Die Engine stellt allen EAs eine kleine String-Adresse zur Verfügung. Der Kernel im EA mit der gleichen Erkennungsadresse wird abgerufen, und der normale Motoradvisorbetrieb wird automatisch gestartet. Wenn die Engine auf einen anderen EA umschaltet, schaltet sie den Kernel des EA, mit dem sie gerade gearbeitet hat, in den Zustand des Wartens auf Adressen um, genau wie die anderen EAs in diesem Moment. Zu diesem Zeitpunkt sind alle EAs getrennt und der Motor wartet auf die andere Adresse des EAs, den der Motor benötigt.

Der Kernel des neuen EA antwortet und geht in den Zustand des Standardbetriebs über. Beim nächsten Mal fährt der Motor fort, die Ziellinie zu senden, und der Zustand des Wartens wird nicht geändert. Zusätzlich zum Standardaustausch muss der Expert Advisor eine Bewegung analysieren, um zu prüfen, ob das Ende der Arbeitslinie darin erscheint. Am Anfang von Austauschpaketen muss eine Zeichenkette stehen, die angibt, an wen ein Paket von der Engine adressiert ist. Dieser Kernel empfängt das Kontrollpaket und beginnt, Pakete seines Zustands mit einer bestimmten Frequenz zu senden.

Die anderen warten darauf, dass sie durch eine eindeutige Identifizierungszeichenfolge für jeden EA angesprochen werden. Beim Umschalten sendet der Motor dem aktuellen EA einen End-of-Life-String. Der EA hört auf, etwas zu senden und geht in den Zustand der Erkennung seiner eigenen Erkennungszeichenfolge über, was gleichzeitig der Beginn der Standardarbeit des Austauschs mit dem Motor ist.

Die Ressourcen sind etwas einfacher. Sie brauchen keine Adresse, nur einen Ressourcennamen. Sie haben ein komplizierteres Modell. Das ist einfacher.

Der Kern ist einfach ein Array von Werten. Jeder Expert Advisor schreibt darin die Werte der Parameter seiner GUI-Elemente. Bei Bedarf speichern die EAs eine Kopie der Kernel-Parameter in der Ressource, und die Engine liest sie aus und zeichnet die grafische Benutzeroberfläche neu.

Im Prinzip ist dies eine einfache Aufgabe, aber es gibt viele kleine Nuancen. Zum Beispiel Meldungen über das Starten und Beenden der Kommunikation mit dem EA. Wir müssen nur an das Format denken.


Übrigens ist es mir gelungen, die Kommunikation zu beschleunigen und die Langsamkeit zu verringern. Allerdings habe ich den Grund dafür noch nicht verstanden. Es tritt während des Neuzeichnens auf, aber das Seltsame ist, dass das Neuzeichnen selbst keine Bremsung ist. Aber das erneute Zeichnen bei der Kommunikation mit der Ressource verlangsamt sich. Der Grund dafür ist noch nicht klar.

 

Führen Sie eine Art Zeit-Kosten-Überwachung ein. Sie können also sehen, wo es sich verlangsamt. Und wie man sie umgehen kann.

Vielleicht habe ich es ein wenig kompliziert gemacht. Ich weiß nicht, wie es in Ihrem Motor organisiert ist. Ich habe nur die Logik benutzt.

 
Oleg Papkov:

Führen Sie eine Art Zeit-Kosten-Überwachung ein. Sie können also sehen, wo es sich verlangsamt. Und wie man sie umgehen kann.

Vielleicht habe ich es ein wenig kompliziert gemacht. Ich weiß nicht, wie es in Ihrem Motor organisiert ist. Ich habe nur die Logik benutzt.

Die Logik hat Sie näher an den Punkt gebracht, und im Allgemeinen verstehen Sie es richtig.

Heute werde ich versuchen, den Ursachen des Bremsens auf den Grund zu gehen. Es ist klar, dass sich das Umzeichnen selbst nicht verlangsamt. Auch das Schreiben und Lesen der Ressource ist nicht langsam. Aber gemeinsam erreichen wir Langsamkeit.

 
Es wird überwacht, welcher Vorgang wie lange dauert? Sie müssen nacheinander durchgeführt werden. In der EA werden die Daten mit einer Frequenz von z. B. 30 ms erfasst und an den Motor gesendet. Wenn ein Thread an die Engine gesendet wird, ist er dann bereit zum Empfang? Oder was macht sie?
 
Oleg Papkov:
Es wird überwacht, welcher Vorgang wie lange dauert? Sie sollten nacheinander durchgeführt werden. Der Expert Advisor führt sie aus, erfasst Daten und sendet sie in einer Frequenz von z. B. 30 ms an die Engine. Wenn ein Thread an die Engine gesendet wird, ist er dann bereit zum Empfang? Oder was macht sie?

Ich überprüfe jetzt alles.

Die Engine liest alle 30 ms die Nachrichtenressourcen von der EA, und die EA liest im gleichen Rhythmus die Nachrichtenressourcen von der Engine. Beide schreiben sich auf der gleichen Frequenz ihre Nachrichten (wenn es etwas zu schreiben gibt). All dies führt nicht zu einer Verlangsamung. Auch das Neuzeichnen selbst führt nicht zum Abbremsen.

Die Verlangsamung tritt jedoch auf, wenn eine Kombination aus Neuzeichnen und Schreiben/Lesen der Ressource auf der Engine-Seite stattfindet. Die Ursache dafür ist noch nicht klar. Es herauszufinden.

 
Реter Konow:

Ich überprüfe jetzt alles.

Die Engine liest alle 30 ms die Nachrichtenressourcen von der EA, und die EA liest im gleichen Rhythmus die Nachrichtenressourcen von der Engine. Beide schreiben sich auf der gleichen Frequenz ihre Nachrichten (wenn es etwas zu schreiben gibt). All dies führt nicht zu einer Verlangsamung. Auch das Neuzeichnen selbst führt nicht zum Abbremsen.

Die Verlangsamung tritt jedoch auf, wenn eine Kombination aus Neuzeichnen und Schreiben/Lesen der Ressource auf der Engine-Seite stattfindet. Die Ursache dafür ist noch nicht klar. Ich schaue es mir an.

Möglicherweise eine Fehlanpassung: EA und Motor, 1 - beide senden zueinander, 2 - beide empfangen, ihre OnTimer-Zyklen sind nicht synchronisiert. Warten auf den Moment der versehentlichen Synchronisierung, um normal zu arbeiten. Könnte das der Grund sein?