INVESTOX-Forum

Hi,

gegeben sind die Instanzen A, B und C. In jeder Instanz ist genau ein BT definiert. Sagen wir mal BT.A, BT.B und BT.C.

In C trage ich den Pfad von A ein (Ordner zum Lesen von Berechnungstiteln) und bekomme die Fehlermeldung, dass BT.C nicht mehr gefunden wird. Meinethalben schlüssig.

Aber wie kann ich nun BT.A in C verwenden. Außer der obigen Fehlermeldung erscheint kein BT.A, was ich erwartet hätte.

Versuche ich in C einen neuen BT anzulegen bekomme ich nur die Auswahl BT.C und BT.A will ich ja gerade nicht neu anlegen, sondern als Import aus A verarbeiten!

Gruß

Alexander

Achso? Moment...

Jetzt habe ich die Situation, dass BT.A in C angezeigt wird (ohne Aktualisierung in C) und BT.C nach wie vor nicht mehr gefunden wird:

Modul: Import/Export
Prozedur: Datenimport
Titel: BT.C
Meldung: Die angegebene Datei existiert nicht. Ursache dafür kann sein, dass die mit dem Titel verknüpfte Datei (Textdatei, Berechnungstitel...) inzwischen gelöscht bzw. noch nicht aktualisiert wurde

Der Aufwand beim doppelten Anlegen der BTs ist enorm.

Muss ich jetzt BT.C noch in A anlegen? Das wäre ja ein Irrsinn...

nicht auf den Ordner Berechnungen.

Also z.B. statt
C:\Investox\Projekte\A\Berechnungen

schreibt man besser:
C:\Investox\Projekte\A

Dann funktioniert es ohne das BT.C in A angelegt werden müsste.
Jedoch natürlich wie oben geschrieben BT.A in C.

Vom Arbeitsablauf:

• Master HS anlegen
  
• alle benötigten BTs anlegen
  
• Instanzen vererben
  
• Pfad(e) legen
  

Danke für Deine Hilfe Kalli!

Alexander

PS: Vielleicht war der Fasching gestern und vorgestern doch ein bisschen doll (Ja tatsächlich, sowas gibt's im Norden nach Aschermittwoch)...

Nach meiner eigenen Anleitung habe ich das hier gemacht:

Zitat

Master HS anlegen
alle benötigten BTs anlegen
Instanzen vererben
Pfad(e) legen

Jetzt - dachte ich - sei es wundersam möglich von einer Instanz E durch referenzieren auf BTs der Vorgängerinstanzen (E liest BT von D, D von C, C von B, B von A) sämtliche BT.A, BT.B, BT.C, BT.D in E lesen und an den Markt bringen zu können. Geht aber nicht.

Was (wahrscheinlich) wirklich passiert:
BT.A wird in A berechnet, kann aber bestenfalls nach B weiter gereicht werden.
BT.B wird in B berechnet, kann aber bestenfalls nach C weiter gereicht werden.
BT.C wird in C berechnet, kann aber bestenfalls nach D weiter gereicht werden.
BT.D wird in D berechnet, kann aber bestenfalls nach E weiter gereicht werden.
Das heißt in E habe ich nur BT.D zur Verfügung (oder wahlweise EINEN der anderen BTs).

Das hilft nicht die Rechenzeit zu reduzieren!

Versuche ich die BT Ergebnisse instanzübergreifend weiterzugeben, kommen anscheinend nur 5 Felder im BT in Betracht: Close, Open, High, Low, Volume.
Die sind schnell voll.

Gibt es eine Möglichkeit in E die BTErgebnisse aus allen anderen Prozessorkernen abzurufen? Wenn ja, welche?

Gruß

Alexander

Offenbar geht es so, dass BT.A einmalig in Instanz A gerechnet wird.
In allen weiteren Instanzen B, C, D, E wird der Berechnungstitel nur noch als BT.A referenziert, also z.B. per Close("BT.A"), Open("BT.A")
Auf diese Weise scheint E richtig zu rechnen.

Jetzt habe ich nur noch ein grauer Balken Problem, das hoffentlich ein Synchronisationsproblem und keinen Zukunftsblick darstellt.

EUR/USD Master Handelssystem
In diesem sind folgende Berechnungstitel angelegt:
BT.A, BT.B, BT.C, BT.D, BT.E
Keiner dieser Titel wird im Master verwendet, sie sind nur deshalb angelegt, um sie auf die Instanzen A, B, C, D, E vererben zu können.

Die Ein- und Ausstiegsbedingungen sehen so aus:

global calc p1: p1();
global calc p2: p2();
global calc p3: p3();
global calc p4: p4();
global calc p5: p5();
global calc p6: p6();

global calc PEL: Ref(p1 and p2>0 and p3>0 and p4=-1 and p5>0 and p6>0, -1);
global calc PES: Ref(p1 and p2<0 and p3<0 and p4=1 and p5>0 and p6<0, -1);
global calc PXL: Ref(p1 and p2<0 and p3<0 and p5<0, -1);
global calc PXS: Ref(p1 and p2>0 and p3>0 and p5<0, -1);

global calc EL: Schalter(0, PEL, 1, PXL or PES, 0);
global calc ES: Schalter(0, PES, 1, PXS or PEL, 0);
global calc XL: Schalter(0, PXL or PES, 1, Not(PXL or PES), 0);
global calc XS: Schalter(0, PXS or PEL, 1, Not(PXS or PEL), 0);

Ergebnis:



Wie man sieht, beginnt der "graue Balken" erst in der Gegenwart, so wie es sein soll.


Jetzt die leicht veränderte Variante. Motivation: schnellere Berechnung.

Die Instanzen A, B, C, D und E wurden aus dem Master abgeleitet und angepasst:
1. unter Einstellungen / Daten wurde wie oben beschrieben die Vorinstanz referenziert. E referenziert D, D C, ...
2. pro Instanz ist nur ein BT aktivert und wird in der darauffolgenden Instanz z.B. als Close("BT.B"), Open("BT.B") referenziert
3. In Abwandlung zum blauen Teil oben werden statt der Indikatoren die BTs eingesetzt:

global calc p1: Ref(Close("BT.C"), -1);
global calc p2: Ref(Open("BT.C"), -1);
global calc p3: Ref(Close("BT.D"), -1);
global calc p4: Ref(Open("BT.D"), -1);
global calc p5: Ref(Close("BT.E"), -1);
global calc p6: Ref(Open("BT.E"), -1);

Ergebnis:



Es entsteht hier der graue Balken, der offenbar ein Synchronisationsproblem als Ursache hat.
Alle beteiligte BTs sind vorher bis mindestens 21.00 Uhr 3. Mai durchgerechnet worden.
Der Bereich bis zu dem alles O.K. ist geht aber nur bis ungefähr Tagesschluss gegen 22.00 Uhr des Vortages!

Hat jemand eine Idee, wo ich weiter forschen könnte, um das zu beheben?
Oder versuche ich etwas, was so nicht vorgesehen ist?

Gruß

Alexander

Hallo Bernd,

Danke erstmal für Deine Antwort.

Ja, habe ich getestet, leider noch keine Verbesserung.

Der Fehler liegt irgendwo zwischen Instanz B und C. In C wird der Indikator richtig, der BT nur mit einem Tag Verzögerung berechnet.

Werde im Erfolgsfall berichten.

Gruß

Alexander

Geht.

Habe das System komplett neu aufgebaut. Meine Instanzen und Berechnungstitel hatten vorher wohl einen "merkwürdigen, nicht reproduzierbaren" Zustand.

Jetzt muss ich zur Sicherheit noch die ersten Livedaten in der nächsten Woche abwarten.

Endlich ist mir klar, was Master/Slave bedeutet, was das bringt und wie man's macht.

Gruß

Alexander

Hallo Vuego,

Vielen Dank für Deine kritische Betrachtung.

Ja, unter Master/Slave verstehe ich die Berechnung von rechenintensiven BTs verteilt auf mehrere Instanzen und damit Prozessoren. Am Ende der Kette steht der "EndSlave", der die Signale in den Markt gibt. Eigentlich ist der kein Sklave, sondern so eine Art Projektmanager, da er alle Ergebnisse der anderen Sklaven lediglich zusammen fasst. Der Master heißt deshalb so, weil es nur einen gibt. Das Mastersystem enthält die gesammelten Berechnungstitel für alle weiteren Instanzen.

Die Parallelisierung kann in der Tat nur dann gut klappen, wenn das System unempfindlich gegen kleine Abweichungen in der Tickreihenfolge ist und/oder Synchronität herbeigeführt werden kann. Dies ist der Teil, wo ich noch unsicher bin und live Daten abwarte. In jedem Fall kann ich alles auf 1min synchronisieren und wäre dann immer noch um etwa Faktor drei schneller, als dies vorher möglich war.

Nach meinem jetzigen "Verständnis" kann man sehr wohl deutlich mehr als nur die 6 Felder des Titels "befüllem", wobei es nach früheren Tests wohl Einschränkungen gibt, was die Nutzbarkeit von Volume und OpenInt für Forexdaten mit 5 Nachkommastellen betrifft. Die Anzahl der BTs, die Du pro Instanz anlegen und referenzieren kannst sind meines Wissens nach nicht begrenzt.

Gruß

Alexander

Guten Morgen Vuego,

O.K., dann habe ich etwas anderes als Master/Slave entwickelt. Ist mir egal. Die Ergebnisse waren schneller da und es wurde richtig errechnet, das war mein Ziel.

Time to Market. Vorher in nur einer Instanz hat es bis zu drei Minuten gedauert, bis das Signal am Markt war.
In der neuen Konstellation hängt im ungünstigsten Fall alles von der am längsten dauernden Berechnung ab. Diese dauert bis zu 40 Sekunden.
Von 1-3 Sekunden träume ich.

Ich habe mir das gerade mit ungekochten Nudeln klargemacht, Y-Achse Parametername, X-Achse Zeit

Serielle Berechnung in einem Projekt einer Instanz:
Das Signal kommt in den Markt, wenn der letzte Berechnungsschritt abgeschlossen ist.
Nach Parameter p3 also.



Parallele Berechnung in mehreren Instanzen:
Das Signal kommt in den Markt, wenn erstmalig alle notwendigen Berechnungen abgeschlossen sind.
Eigentlich erst nach p1.



Parallele Berechnung in mehreren Instanzen bei Aktualisierung in diskreten z.B. 1 Minuten Abständen:
Das Signal kommt in den Markt, wenn erstmalig alle notwendigen Berechnungen abgeschlossen sind, frühestens jedoch zum Zeitpunkt der Aktualisierung des HS. Eigentlich kann in der Folgeinstanz nur der Wert der Vorperiode verwendet werden. Nach p1 mit gewisser Pufferzeit.



Parallele Berechnung in mehreren Instanzen bei Aktualisierung in diskreten zeitlichen Abständen, die pro Instanz auf die typische Rechenzeit eingestellt wird:
Das Signal kommt in den Markt, wenn erstmalig alle notwendigen Berechnungen abgeschlossen sind, frühestens jedoch zum Zeitpunkt der Aktualisierung des HS. In der Folgeinstanz wird der Wert der Vorperiode verwendet. Das ganze Gebilde wird Interferenzen zeigen. Hier kommt die Robustheit gegen kleine Abweichungen in der Tickreihenfolge ins Spiel.
Umgehend, sobald die handelnde Instanz fertig gerechnet hat.



Zufällig sind es oben nur 6 Parameter, aber wie Du siehst müsste man locker deutlich mehr Parameter übergeben können, da die Anzahl der BTs fast beliebig erhöht werden kann. Ich habe ja nur Open und Close verwendet, weitere Felder (wie High, Low z.B.) wurden noch nicht benötigt.

Das Zusammenwirken muss meiner Ansicht nach live ausprobiert werden.

Gruß

Alexander

Hallo Vuego,

Genau, FX. 40 Sekunden sind eindeutig zu viel.

Deine Bemerkung zur Softwarebeschleunigung hat geholfen. Faktor 10 konnte ich für den am längsten rechnenden Indi schon herausholen, da waren überflüssige Mehrfachberechnungen enthalten, die TimetoMarket, nun ja, etwas verzögerten... Die Lifetests zeigen, dass sich die Berechnungsweise in nur einer Instanz deutlich beschleunigen läßt, wenn man es vernünftig entwirft. Ich arbeite zunächst weiter in dieser Richtung.

Danke und Gruß

Alexander