INVESTOX-Forum

lieber 250MB als 80% core auslastung.

nunja.... ich möchte mich da udo anschliessen. auch sehr potente rechner werden doch sehr stark durch die beschränkung auf ein core ausgebremst.
ich leide immer wieder darunter, und habe unter jetzigen voraussetzungen vermutlich in die falsche hardware investiert und verliere viel zeit durch warten und andere flaschenhalsprobleme wie die begrenzung des imports
auf 25 000 000 ticks, die zu berechnungstitel- oder kombitel workarounds zwingt... kaum auszudenken, was eine gut funktionierende multicoreunterstützung und verbesserte datenimportfähigkeit (z.b. durch kompressions temp zwischenspeicher) bringen würde: komplexe indikatoren realtime flüssig in charts darstellen, dick zeit bei optimierungen sparen, keine probleme mehr beim backtesten langer tickhistorien etc...

die software ist klasse, aber es steht ausser zweifel, dass man bei den heute verfügbaren datenmengen rasch an die grenzen der derzeit unterstützten infrastruktur gerät und das ist schade, denn so kann man die reichhaltigen möglichkeiten nur unvollständig und unter zeitraubenden umwegen ausnutzen.

Hallo
ich glaube kaum dass wir so schnell ein Core fähiges INV bekommen werden.
Aber es wäre schon ein großer Vorteil wenn das ORM ausgelagert einen zweiten Core nutzen könnte und generell Stops o. Exits im ORM programmierbar wären.

Vor allem würde der Zugriff im ORM auf den aktuellen Bar/Brick eventuell mit veränderbarer komp. ein schnelleres und besser an den Markt angepasstes Stop/Exit- Management ermöglichen.

Gruss Gabi

hallo vuego,

was die hardware anbetrifft, denke ich eine hochgetaktete core2duo plattform ist sicherlich eine gute lösung, da es auf die geschwindigkeit des einzelnen cores ankommt. ich habe 4 cores, die allerdings individuell nur mittelschnell sind. und von denen momentan oft eins oder 2 brachliegen und der rechner trotzdem duch die überlastung des einen IV cores nicht mehr flüssig läuft (bildaufbau, da immer auf IV gewartet werden muss etc.)

der datenimport mit 25M klappt halt meistens nicht auf anhieb sondern du musst mit 10M anfangen und dann mangsam hochschrauben.

was den sinn der MC unterstützung anbetrifft, fällt mir ein konkretes beispiel ein:

ich habe ein menge auto-ÜLs erstellt, die ich gerne in einem schnellen chart
zum disk. traden verwenden würde (über zusätzliches manuelles einzeichnen von tradelinien). das ist momentan nicht möglich, denn die auto Üls pumpen soviel leistung, dass IV fast unbedienbar wird. so kann man manuell nicht arbeiten. klar, vielleicht würde es was bringen, die auto ÜLs extern über DLL errechnen zu lassen, aber um das herauszubekommen, müsste ich erst viel zeit in das erlernen von VB stecken, was ich mir gerne sparen würde, das es in dem fall ausser einem evtl geschwindigkeitszuwachs für mich keinen mehrwert bringen würde.
wenn es also ohne weiteren aufwand flüssig berechnet würde, wäre das in dem fall super für mich. oder stell dir mal vor, was du beim optimieren für einen geschwindigkeitsgewinn erreichen könntest, wenn 4 oder mehr cores angesprochen würden...

hi udo,

die funktionsweise der kombititel habe ich ja nun dank frieder auch begriffen.

was ich noch nicht hinbekommen habe, ist, an den anfang des KT einen realtimetitel für life zu setzen. das hat bis jetzt bei mir immer error messages hervorgerufen. vielleicht war aber die eingestellte tickzahl des RT titels zu gross, das muss ich nochmal checken...

was die Üls anbetrifft, geht leider unter einer gewissen mindestzahl and bars für die neuberechnung wenig, da einige (je nach eingestellter periodenzahl im indikator) mitunter recht weit zurückreichende
daten brauchen. sonst musst du alle paar minuten F5 drücken und
dann ist das programm auch eingefroren. wenn du stärker komprimierte charts nimmst, siehst du wieder weniger mini congestions etc.
ich würde gerne mit einem 1SP chart für den DAX arbeiten können, aber da müssten die indikatoren eine recht hohe periodenzahl verwenden und würden damit dann INV völlig blockieren. aber du magst schon recht haben, dass man mit optimierungen sicher einiges gewinnen könnte.

z.b. würde es für meine ÜLs reichen, wenn sie nur alle x-bars neuberechnet würden. vielleicht könnte man auch daran denken, dass die indis zyklisch neuberechnet werden. d.h. neues bar1 indi1, neuers bar2 indi2, neues bar3 indi3 und dann wieder neues bar1 indi1. es muss ja nicht alles bei jedem neuen bar neuberechnet werden. insbesondere fürs diskretionäre traden könnte man updatezyklen in den indis einstellen und so sicher viel CPU zeit sparen.

was mir aufgefallen ist, ist dass mitunter INV auch ohne offenes chart
eine recht ansehnliche CPU auslastung nur duch die updatefunktion (grünes lämpchen) erzeugt. da frage ich mich, woher das wohl kommt, denn wenn nichts offen ist wird ja auch nichts geupdated?

Moin Udo,

habe mal den ersten Cafe des Tages zum Anlass genommen, die "Bremsen" zu überdenken:

ich komme auf 21 "Rädchen" innerhalb von Investox, an denen man schrauben kann, um die Geschwindigkeit zu erhöhen, und DU???

Außerhalb von Investox kommen dann sicherlich nochmal 10-15 Faktoren dazu....

Wahrlich keine einfache Aufgabe für einen Trading-Anfänger....

Hallo Udo,

die Bereiche NNs, Berechnungstitel und Histogramme hatte ich ausgelassen, sodaß ich, wenn ich diese von dir erwähnten 22 "Schräubchen" noch dazu addiere, in meiner Liste ebenfalls auf ca. 43 Stellräder innerhalb von Investox komme..... schon gigantisch...

Vielleicht wäre mal eine separates Tool: "Opti-Speed-für IV" angesagt?

Aber dennoch, Spaß beiseite: ich kann mich über die Geschwindigkeit von Investox überhaupt nicht beklagen, man muß halt wissen, wie und wo man was reduziert,zusätzlich:

- die Optimierungen auf separate Rechner auslagern (Compi 1),
- die Daten per Datenserver sammeln (Compi 2),
- den Datentransfer im eigenen Netz per GB-LAN einrichten und
- das ORM- Trading auf separaten Rechnern durchführen (Compi 3+4+.....),
- genauso wie das diskretionäre Trading (Compi 5).

Hat man das mal alles stehen und fehlerfrei laufen, dann macht man täglich ein Acronis -Image jedes Rechners, synchronisiert die relevanten Rechner per Syncback und spiegelt ein komplettes Image auf eine externe Festplatte. Voila, fertig ist die (fast) perfekte IV-Umgebung.

Dann kann eigentlich nicht mehr viel passieren ( außer das, was Moneymaker passiert ist ), da sei die USV mein Schutz....

Mit der oben beschriebenen Umgebung kann man locker an einem Entwicklungsrechner (Compi 6) arbeiten, während an einem zweiten die zeitaufwendigen Optimierungen laufen.

Das ORM-Trading läuft vollautomatisch auf einem an den Datenserver angebundene 3. Rechner mit bis zu 20 Handelssystemen vollautomatisch und völlig störungsfrei.

Der Datenserver ist Dank Tenfore-Datenfeed seit >4 Wochen ebenfalls völlig störungsfrei durchgelaufen und sichert Dank Snycback stündlich die aufgezeichneten Daten auf einen anderen Rechner im Netz.

Das diskretionäre Trading läuft auf einer separaten IV-Version auf einem weiteren Rechner mit und kann durch akustische Limit-Setzung relevanter Supp.+Resist.-Level "nebenbei" durchgeführt werden.

Über Speed-Probleme kann ich mich bei dieser Gesamt-Konfiguration eigentlich nicht beklagen, allenfalls diejenigen meiner "centralen CPU", die wg. zeitweiser präseniler Demenz mit den umfangreichen Infos , die von allen Monitoren auf mich niederprasseln, nicht mehr mithalten kann.

Ob da nun eine externe Optimierung 3 Stunden oder 3 Tage dauert ist wirklich sekundär, weil es ja nicht mich beschäftigt, sondern nur die Hardware.

Ich habe mir mal die Produktspezifikationen der Blade-Server näher angesehen und denke nicht, dass diese IBM-Technik heute schon "locker im Bereich des Geldbeutels" des durchschnittlichen IV-Users liegt, wohl eher in dem der Exil-Räto-Germanen...

Dennoch würde ich natürlich auch meine Hardware im Falle einer Multiprozessor-Unterstützung von Investox überdenken und alle Hardware-Möglichkeiten des Marktes neu überprüfen.

Fazit: IV sollte nicht "neu erfunden" werden, sondern kontinuierlich weiter optimiert werden, so wie ich es in den letzten 7 Jahren immer aufs Neue erfahren habe.

Dabei sollten Tools wie die lang ersehnte Walk-Forward-Optimierung, umfangreicher Fehlercheck von erstellten Handelssystemen, statistische Auswertungen der ORM-Tätigkeit etc. Vorrang haben vor High-Tech-Gimmicks...