INVESTOX-Forum

Hallo zusammen

Ich habe seit ca. 3 Wochen Investox RTT für IB am Laufen (aktuell V.2.6.2 mit TWSStart V.2.3.7.2661 als Monitor, TWS hat Build 858.6 vom 1.5.06).

Investox RTT kam heute in die Situation, sich nicht mehr mit der TWS verstehen zu wollen. Es brachte, ich schätze über eine Stunde, die Meldung "unexplained zero bytes" (siehe Bild).

Ich habe es dann abgebrochen und neu gestartet. Schwupps hat es sich neu verbunden ohne weitere Probleme.

Dies ist das zweite Mal, dass es zu diesem Problem kam.

Ich bin noch in der Vorproduktionsphase und werde nicht mit IB als Datenfeed life gehen (ich plane, in ca. 14 Tagen Tenfore zu testen mit IB nur als alternativem Datenfeed).

Aufgrund der Symptome (problemlose Verbindung nach Neustart Investox RTT für IB) sehe ich es nicht als Problem mit dem IB Datenfeed, sondern als RTT Problem. Hat jemand ähnliche Erfahrungen gemacht, gibt es eine Lösung, Erklärung, Workaround etc.?

Danke und Gruss
Bernd

Hallo

Heute komme ich um 19 Uhr heim und sehe als erstes nach, was Investox so für mich getan hat. Leider stelle ich fest: den ganzen Tag nichts. RTT produzierte wahrscheinlich um 9:06:18 Uhr den Fehler, dessen Abbild ich angefügt habe.

Die TWS aber ist sauber an den Market Daten dran ...

Das kann's ja wohl nich sein, das ist der dritte Abbruch von RTT in drei Wochen.

Meine Fragen sind:
* lässt irgendjemand Investox alleine Handeln? (ich bin noch in der Vorproduktionsphase und habe das Gefühl, es wäre einfach nicht stabil genug)
* gibt es zu diesen Investox RTT Problemen eine Developer-Trace Datei, die man auswerten kann um dem Problem auf die Spur zu kommen
* kann man Trace-Level setzen, um mehr Informationen zu bekommen, oder
* ist das ein Fall für's Debugging durch Herrn Knöpfel?
* und dann: warum gibtg es ein Pop-Up verd***t nochmal, warum startet sich RTT nicht einfach neu wenn ihm was nicht passt? Solche Mechanismen stehen doch auch unter Windows heute zur Verfügung, unter allen anderen Betriebssystemen die ich kenne geht das doch auch (das sind zOS und so ziemlich alle Unixe)

Danke und Gruss
Bernd

PS: gerade gebe ich OK und was sehe ich wieder: unexplained zero bytes

Hi oko

Danke für Deine Antwort. Ist schon angenehm, wenn einem jemand hört, nachdem man grad gefrustet ist

Naja, das mit den Stops sehe ich auch so, aber in diesem Fall hätte ich den ganzen Handelstag verloren. Stop hin oder her.

Nächste Woche ist Herr Knöpfel soweit ich weis aus dem Urlaub zurück und vielleicht kann er sagen, warum Investox RTT ein Popup schickt. Denn solange Investox RTT nicht komplett abgeschmiert ist (wie nach einem Minidump), hat es noch die Kontrolle. Also man könnte statt einen Popup, das Stunden lang herumsteht, das im Programm tun:

* das interne Memory ab-cleanen, "historische" Daten ab dem Problemzeitpunkt nachladen und von vorne anfangen, oder wenn man sein Memory und seine Register nicht im Griff hat könnte man

* sich einmalig neu einplanen für eine Minute später im "geplante Tasks" Mechanismus von Windoof und dann RTT sofort beenden

* Wenn man dann sein Programm immer noch nicht im Griff hat, muss man halt ein übergeordnetes Kontrollprogramm schreiben

Wenn ich noch eine Weile nachdenke, fallen mir sicher noch weitere Vorschläge ein; jedenfalls muss doch das Ziel sein, die Herzstücke abzusichern.

(Das mit dem "wenn man sein Programm/Register/Memory nicht im Griff hat, ist überhaupt nicht abwertend gemeint, um Missverständnissen vorzubeugen. Ich schätze Investox sehr, vielen Dank Herr Knöpfel! Aber man muss immer vom Worst Case ausgehen, das machen alle grossen Hersteller so

Auf den Grossrechnern nennen wir das "unattendend batch" und "high availability". Und das übergeordnete Programm wäre ein Fall für ein sogenanntes "control image" auf einem separaten Rechner (IBM). SAP z.B. bietet für ihr Herzstück, die Central Services, die Möglichkeit, sie auszukoppeln und via RZ Automation (das übergeordnete Konrollprogramm) auf weitere Rechner zu schieben, um einen 7*24 Stunden Betrieb der eigentlichen Applikation-Server zu gewährleisten. Wir haben dies mehrfach implementiert und es erfüllt seinen Zweck. Das würde sogar mit Windows Rechnern funktionieren, denn das Konzept macht die Sache stark.

Ich bin bereit, für diese Features, hardware- und softwareseitig, einen hohen Preis zu zahlen und eine Anzahl Hotbackup Rechner zu betreiben, aber ich sehe nicht, dass ich es momentan überhaupt für Geld kaufen kann

Also, mal sehen, ob es noch weitere Vorschläge gibt und ob Herr Knöpfel etwas dazu weiss.

Gruss
Bernd

Hallo zusammen

Ich führe diesen Thread einfach mal täglich weiter, bis RTT läuft ohne Probleme zu verursachen. So als Log.

Heute komme ich um 22 Uhr zurück und finde, dass RTT mal nicht abgestürzt ist. Aber es hat irgendwann im Laufe des Tages Connection Probleme gemeldet mit einem Popup. Ich muss eine manuelle Datenpflege machen - ja was kann ich denn besser, als ein Programm, welches nicht abgestürzt ist?

Meine Vorstellung wäre:
* kein Popup
* statt dessen ein Eintrag in ein, sagen wir mal, RTT-Log
* aiutomatische Neuversuche des Nachladens
* das wäre don't bother me !

Wieso macht RTT das Nachladen nicht gerade selber und nervt mit Popups am Abend? Auch sehe ich nicht, wann es dieses Problem hatte und ob es ein oder mehrmals auftrat.

Ich habe Sweet Light Crude mitlaufen und der Chart sieht mir vernünftig aus. Wie soll ich rausfinden, wo es schiefging und wie oft? Grrr. Ein Programm was läuft soll doch bitte sein Recovery selber machen.

Gruss
Bernd

Hallo Mikel

Ich verstehe schon, dass IB nicht in erster Linie Datenlieferant ist und die Stabilität
schwankt.

Meine Sicht ist aber eine ganz andere: ich bin noch in der Vorproduktionsphase und verwende IB
als Datenfeed für den Investox RTT Stresstest. Lass' es mich so erkären:

In der professionellen Informatik unterteilt sich ein Eintwicklungs- und Einführungszyklus in
verschiedene Pasen. Best practice ist, man macht es so:

* Development - das macht der Programmierer, und in seiner Entwicklungsumgebung macht er auch
funktionale Tests

* Qualitätssicherung - eine Testmannschaft (Applikationsleute, nicht der Entwickler) führt
funktionale Tests in einer definierten Umgebung wiederholbar durch, um die zugesicherte Qualität
zu prüfen

* Stresstest - eine Testmannschaft (Applikationsleute und möglicherweise Systemengineers nicht
der Entwickler) fährt Tests mit instabilen Datenfeeds, möglicherweise zweifelhaften oder
falschen Daten (gerne auch solche von denen man denkt, es könnte das Programm crashen) in einer
definierten Umgebung wiederholbar durch, um sicherzustellen, dass auch im Worstcase die Company
nicht beschädigt wird. Es kommt übrigens für den Entgwickler oder die Entwicklungsmannschaft
nicht gut, wenn das Programm auf diese Weise crashbar ist, das kann ich Dir versichern.

* Performance-Tests - eine Testmannschaft (Systemengineers, event. zusammen mit dem Entwickler)
führen Tests in einer wohldefinierten Umgebung wiederholbar durch, wobei der Datefeed den realen
Daten weitgehend enspricht - wie sie später auch in der Produktion vorkommen. Hier will man
einfach den maximal möglichen Durchsatz unter realen Bedingungen testen. Dafür gibt es gewisse
Erwartungen, die aufgrund der Physik berechnet oder wenigstens geschätzt sind. Werden die Werte
nicht erreicht, stimmt etwas nicht. Entweder am Programm oder am Konzept oder an den Maschinen.
Hier kommt wirklich Hektik auf.

Danach schliesst sich möglicherweise noch eine Pilotphase an, bevor das neue Package wirklich
produktiv startet.

Ich bin momentan mit meinen Maschinen und Investox in der Stresstest Phase - und ich bin nicht überzeugt:

Gerade dass IB ein so instabiler Feed ist, macht ihn für diese Phase so attraktiv. Es zeigt mir,
dass ich mich nicht in dem Masse auf Investox RTT verlassen kann, wie es meiner Erfahrung nach
bei gleichem Equipment konzeptionell möglich wäre. Und wenn der Datenfeed stabiler ist deckt das einfach nur immer noch vorhandene Programm-Schwächen ab - man sieht sie einfach nicht oder so selten, dass man sich nichts mehr dabei denkt. Das ist gefährlich.

Und desswegen treibe ich diesen Aufwand, BEVOR ich mein Geld an dieser Stelle einsetzen kann.

Wenn ich diese Phasen abgeschlossen haben werde, durchlaufen übrigens auf einer ganzen
Plattform-Sequenz ebenfalls meine Projekte mit meinen Investox-Handelssystemen dieselben Phasen.
Stabilität ist nicht gratis zu haben, und auch wenn es für die meisten hier langwierig und nicht
spassig erscheint und den Kopf schütteln mögen: dieses methodische Vorgehen erzeugt ein hohes Mass an Sicherheit. Das kann ich aus jahrzehntelanger Erfahrung sagen.

> Ansonsten würde ich an deiner Stelle zu einem verlässlichen Datenanbieter wechseln, wo es zu
keinen Schnittstellenproblemen kommt.
das kommt ganz sicher wie schon am Anfang dieses Threads angedeutet für mich ab der
Performance-Test Phase. Dazu muss ich aber vorher im Stresstest von der Programm-Verlässlichkeit
überzeugt sein. Und ich möchte auch mit meinem Bericht in diesem Thread dazu beitragen, dass es einmal so sein wird: dies ist mein Feedback als Investox RTT Tester in der Stresstestphase.

Gruss
Bernd

Hallo Frieder

Es geht mir nicht um die Compliance mit unterschiedlichen Datenquellen. Auch ich werde mich am Ende der Tests auf eine allein verlassen.

Es geht mir darum, dass RTT als Programm auch unter widrigen Umständen einen besseren Plan haben sollte,
* als mit einem Popup erstmal die Arbeit einzustellen, oder
* mit stundenlangen zero byte oder ähnlichen Meldungen einfach nichts mehr zu tun

Vielleicht kam RTT bei Deinem besseren Datenfeed nie in diese Situation, keine Idee mehr zu haben. Aber was ist, wenn? Was ist im Worstcase? Ist Dein Vertrauen wirklich gerechtfertigt? Wird es den Worstcase überstehen und das Konto unbeschädigt lassen? Können die automatischen Stops (siehe Beitrag von oko) allen Schaden abwenden, wenn im dümmsten Moment der Feed kurz streikt und RTT keinen sauber getesteten Reconnect kann?

Ich würde auch gerne so pragmatisch an diese Sache herangehen können wie Du oder Mikel. Aber keiner kann über seinen Schatten springen. Und der Schatten ist lang, wenn man in dieser Richtung schon Lektionen lernen musste. Seither bin ich Worstcase Fan.

Gruss
Bernd

PS: heute kam ich heim und alles war ok mit RTT
PS 2: Ein Pessimist ist ein Optimist mit Erfahrung ...

Hallo Frieder

Danke. Dein Beitrag und Deine geschilderten Erfahrungen lassen mich hoffen - und gibt mir genügend Schub, früher als geplant einen stabilen Datenfeed zu kaufen.

Natürlich kann RTT nicht 9/11 Nachteile abwenden. Ich hatte dieser Tage nur viele programmtechnisch suboptimal gehandelte Ausfälle - ohne eine 9/11 Welt-Situation.

Zitat

Original von Frieder
Die Tatsache, daß Du erst abends dazu kommst, das Verhalten vom RTT zu überprüfen, heißt wohl, daß Du die Rechner tagsüber unbeaufsichtigt rödeln läßt. Das ist widerrum mit einer professionellen Annäherung ans Intraday-Realtime-Traden nicht zu vereinbaren.

Jau, so ises. Irgendwo habe ich erwähnt, dass ich in einer Testphase bin. Wie hier im Beitrag vom 2.Juni 06 20:10 Uhr geschildert, gibt es einen Zeitplan. Der Plan sieht auch vor, dass ich ab der Pilot-Phase mehr Zeit mit meinen HSen verbringen werde und natürlich in der Produktions-Phase sehr stark "am Ball" bleibe.

Aber das schöne an Testphasen ist - lass' sie einfach mitlaufen und sieh' was passiert. Man bekommt automatisch genügend Feedback am Abend :] Übrigens machen wir das auch im professionellen Bereich, meistens, so. Kein Mensch (und auch keine Company) kann die Manpower bezahlen, die Testphasen voll zu staffen. Schliesslich soll ja, auch wenn in der Produktion die Leute vor Ort sind, trotzdem alles automatisch ablaufen

Gruss
Bernd