Hallo,

 

mal die Frage an die Leute, die MC nutzen. Seit einigen Monaten gibt es bei meiner Multicharts-Installation das Problem, dass das Beenden von MC oder aber Schliessen eines Workspaces nicht immer aber ab und an dazu führt, dass MC nicht mehr reagiert. Kein Busy-Waiting, d.h. Speicher und CPU sind normal. Üblicherweise benötigt MC auf den Ausgaben von QuoteManager eine Weile, um die Disconnects der einzelnen Kontrakte durchzuführen. Bei Custom-Futures scheint das ja einiges zu sein. Thread-Mässig ist diese Aktion leider nicht von der MC-Oberfläche entkoppelt, womit man die Obhut über die Aktivitäten verliert und gar nichts mehr genutzt werden kann.

 

Mit MC gab es bisher einen sehr regen Informationsaustausch bezüglich Logs, Dumps. Es trat auf einer älteren MC 8.0 32 Bit aber auch einer nagelneuen MC 8.0 64 Bit Version auf. Alle Instrumente sind komplett neu eingelesen, womit Strukturänderungen gegenüber alten Versionen ausgeschlossen werden können.

 

Die letzte Protokollierung im QuoteManager vor dem Einfrieren ist immer das Disconnect von einem ES-Contract (erst ESU2 und seit Rollover bei ESZ2, also beim jeweils aktuellen Contract). Der Support hat sich schon alles mögliche angeschaut, ich habe wegen eines anderen Bugs bereits einen Patch für den Interactive Brokers - Adapter. Letztens hat man mir einen HotFix fuer StoragePack.dll gegeben, der hinsichtlich Byte-Groesse identisch war. Ich weiss, wie sich Änderungen im Quellcode auf die Ziel-Kompilate auswirken, ich habe da leichte Zweifel, was diesen HotFix betrifft. Sofern das Problem auf fehlerhafte Thread-Synchronisation und somit auf eine Race-Condition zurückzuführen ist, lässt sich das natürlich u.U. schwer bis extrem schwer lokalisieren. Ich weiss das, da ich jahrelang mich damit beschäftigt habe. Meiner Meinung nach konnte man beim Support in der Entwicklungsumgebung (.Net-Studio) kein Attach auf den ProzessDump durchführen. Weiterhin trat das Verhalten mit zwei verschiedenen SSD als Systempartition wesentlich häufiger auf, als kurzfristig mit einer langsamen normalen Festplatte als Systempartition (gleiches System, nur 'geklont'). Das deutet üblicherweise definitiv auf eine Race-Condition hin.

 

Irgendwelche externen DLLs habe ich ausser ELCollections.dll nicht. Die globalen Variablen konnte man wohl früher nur via externe DLL nutzen, ist aber seit ... Teil von MC. Soweit ich mich erinnere ist MC vor 8.0 nie eingefroren.

 

Vermutlich wird niemand etwas zu diesem Einfrieren sagen können, falls doch würde mich das sehr freuen.

Nachdem ich Deinen Post gelesen habe, dachte ich zuerst mal , dass vermutlich eher die Kollegen von MC bei Dir lernen können als das sie Dir helfen können .

 

Logisch, das dann der KB noch viel weniger beitragen kann ,als die Spezialisten von MC...wenn denn überhaupt .

 

Aber versuchen möchte ich es dennoch, nachdem mich der Begriff der Race-Condition neugierig hat suchen lassen .http://www.tom-next.de/community//public/style_emoticons/default/kaffee.gif

 

Die Problematik "Einfrieren" und Symphtome ähnlich der beschriebenen "Race-Condition" kenne ich aus (viel) früheren Zeiten meiner

Interruptprogrammierung . Es geschah mir , wenn ich Vektoren falsch verbogen hatte oder mich aber in Endlosschleifen verirrt hatte . Die Fehlersuche

kann dann ja leider verzweifelt werden, eben weil der PC nichts erzählt , bevor er sich abmeldet .

Und eine SSD habe auch ich installiert , sie ist wirklich eine unglaubliche Beschleunigung aber seither hat ein (externer) USB-Anschluss mal ne Macke und mal nicht . Blue Screen .

Inzwischen glaube ich nicht mehr an einen Hardwarefehler , es scheint an einen externen Gerät (Funkmaus) zu liegen .

 

Um es nun kurz zu machen , mein Hinweis der vielleicht ein Mini-Schrittchen weiterführen mag :

Hast Du oder aber MC irgendwelche Möglichkeiten den Logout/Disconnect zum einen zu verzögern und zum anderen vielleicht zu dokumentieren (und so indirekt zu verzögern und zusätzlich Informationen zu gewinnen) . Kannst Du vielleicht ELCollection, ADE und GV22 nutzen, um Daten extern ( "C:\..." aber ausserhalb des MC ) zu speichern ...?

 

KB

wenn in den Kernkomponenten Fehler auftreten, hat man da, wo man als MC-Nutzer agieren kann, keinerlei Aktionsmöglichkeiten, hinsichtlich hierfür nutzbarem Logging. Bezüglich 'Disconnect' verzögern, da kann ich nur sagen, dass sich der Support auf dieser Detailebene nicht in die Karten schauen lässt, mehr als meine Hinweise auf diese letzten Logausgaben kann ich da nicht machen. Das kann sich in der Komponente selbst (imho tsIBDataFeed.dll) ganz anders darstellen, dazu weiss ich zuwenig über die interne Architektur. Diese DLL habe ich bereits als gepatchte bekommen bezüglich einem anderen Bugs, diese erneut mit zusätzlichen, kompletten Debug-Informationen zu generieren zzgl. erweitertem Logging oder aber sich auch via RemoteDebug einklinken sind übliche Sachen, nur kann nur TS selbst abwägen, was pragmatischer ist ...

 

Edit: Die TWS-TradingAPI wurde für 8.1. auch aktualisiert, hab die beiden DLLs auch mitbekommen, die dürften an der Stelle aber nicht in Aktion sein.

vielleicht ein Update, dürfte eher in meinem sehr vernachlässigten Mini-Blog von tom-next passen, aber nun ist es hier:

 

nach vielleicht 3-4 Wochen konnte seitens der Entwickler das Verhalten nachgestellt werden. Es kann natürlich nicht garantiert werden, dass es sich um die gleiche Ursache handelt so der Support. "Ganz genau!" dachte ich. Ein Vergleich der Log-Files, die teils sehr detailliert sind, ist immer mit Vorsicht zu geniessen, da diese nicht den richtigen Zeitpunkt (Stichwort kein sofortiges Flushing der Logausgaben) und auch irreführende Ausgaben beinhalten können.

 

Meinerseits ging es mittlerweile darum zu überlegen, ob meine Entscheidung bei der Analyse bei MC den Schwerpunkt zu sehen korrigiert werden sollte oder nicht. Es wäre ärgerlich eine Weile auf das falsche Pferd gesetzt zu haben und den Absprung bzw. richtigen Abzweig verpasst zu haben. Ein wenig vergebene Mühe wäre vor 10 Jahren für mich ein wahres Ärgernis, solch Zeitverschwendung, so ein M*st! Letztlich ist es eine Erfahrung und man lernt daraus, genau wie man an den Märkten aus schlechten Verhaltensweisen lernen sollte. Also wieder ein paar Schritte zurück und MC MC sein lassen und mich in Richtung TradeNavigator orientieren. Mich hat diese Software schon immer gereizt, wenn auch ich keine wirkliche Schlagkraft seitens Support/Development vermute. Andererseits ist für mich die Zeit vorbei ständig auf der Suche nach neuer Software oder Systemen zu sein. Letztlich nährt sich die Suche nach der immer besseren Software, dem Interesse nach einem treffsicheren System, von selbst -- im Endeffekt ist das kontraproduktiv hinsichtlch dem eigentlichen Ziel, das man anstrebt. Ähnliches bei der Fotografie, mein neuester Reiz, die Infrarot-Fotografie. Der Eigenumbau der Kamera ist machbar aber nicht langwierig und lässt sich mit professionellen Mitteln hinsichtlich erreichter Qualitäts und Frequenzerweiterung toppen, preislich dann fast vierstellig aber man will ja auch da mal seine Bälle spielen. Da mir noch ein gewisses Mass an Selbstreflexion geblieben ist, hatte ich deshalb in den letzten 2 Jahren so einige Entscheidungen getroffen, die mich vor solchen Zeit vergeudenden Abwegen bewahren bzw. ich mich einfach für gewisse Dinge entschieden habe. Ein Teil davon ist MC, was für die Analyse und halbautomatisches Handelns hilfreich sein sollte.

 

Um jetzt zum Ausgangspunkt zurückzukommen: In den letzten Monaten sind mir wirklich so einige Punkte in MC aufgestossen, die mich an die Software zweifeln liessen -- das sind teils wirklich rudimentäre Dinge ... Zur Verteidigung muss man sagen, dass man imho von Allen Mitbewerbern in diesem Markt ähnliches schreiben könnte, es ist also kein Alleinstellungsmerkmal von MC. Weiterhin ist es so, dass zu meinem Erstaunen der Support wirklich gut ist. Man interessiert sich wirklich, was der Kunde möchte und das Tracking von Problemen wird teils offen kommuniziert. Um es knapp zu fassen, das ist ein riesiger Pluspunkt von MC und spricht gleichzeitig gegen Software, die lediglich eine kleine Schlagkraft bieten kann (Beispiel dürfte klar sein). ......... Also, um wirklich entscheiden zu können, ob ich meine Entscheidung für MC teilweise revidieren sollte also die Frage, wie komme ich nun weiter bei diesen Punkten in MC, die ein gewisses Problem für mich darstellen? Teils habe ich erfahren, dass man mit Boardmitteln das Problem umschiffen kann (ich sag nur Warten auf Barstatus=2 http://www.tom-next.de/community//public/style_emoticons/default/gossip.gif) oder es wurde in der offiziellen Version behoben, oder ein Patch tat es oder aber man arbeitet noch daran. Im Endeffekt ist die Aussage damit für mich, dass es in die richtige Richtung geht. Meine Hoffnung: Nicht soviel neue Funktionalität, sondern eher an den Feinheiten der Software arbeiten.

 

Weiterhin habe ich natürlich überlegt, ob ich selbst diesem Freeze irgendwie das Handwerk legen kann. Nein das soll kein Hang zum Größenwahn andeuten -- letztlich aber habe ich davon nicht wirklich etwas in dem MC - Forum gelesen, zumindest wäre es mir in Erinnerung geblieben. Woran kann es also liegen??? Um es kurz zu fassen, meine Workspaces habe ich als Kopie aber eben kastriert in Nutzung und zusätzlich noch den Patch, der den Fehler ursprünglich beheben sollte. Damit läuft alles eigentlich wie Butter, in dieser Konstellation kein Freeze mehr! http://www.tom-next.de/community//public/style_emoticons/default/bluelight.gif Nun ist Softwareentwicklung das, wo ich nicht gänzlich blind bin um es vorsichtig auszudrücken ... entsprechend verwundert mich das. Im Prinzip sollte hier keinerlei Relation zu dem benannten Freeze vorhanden sein. Dass ich in meinem Code hinsichtlich Deadlocks/Busywaiting bzw. Loops überhaupt schon geprüft habe, brauche ich hoffentlich nicht zu erwähnen. Das wäre dann aber auch bereits vor dem Schiessen des Workspaces ein Problem. Ich werde sehen, wie sich die Konstellation, mit der ich MC momentan laufen lasse, verhält .... bis jetzt jedenfalls mehr als gut ... vielleicht hat der Patch ja doch ein wenig geholfen.

 

Aber unabhängig der Kritik, die ich hier ausgesprochen habe, will ich noch einmal deutlich betonen, dass IMHO Mitbewerber sicher ähnlche oder wesentlich kritischere Punkte aufzuweisen hätten und mich der Support bei MC schon sehr positiv überrascht hat!! Und genau das findet man nicht wirklich oft.

 

Sollte sich das Rätsel gelöst haben, ggfs. ein Update hier. Auf jeden Fall dürfte sich die nächste öffentliche Version (vermutlich 8.1.) hinsichtlich alles bezüglich Verbindung zu IB gebessert haben.

 

Prost http://www.tom-next.de/community//public/style_emoticons/default/vola.gif

 

 

PS: Klasse bzw. Lob, wie souverän Tom-Next auf die Attacken von wem auch immer reagiert hat!

vielleicht noch eine kleine Info zu den genannten Problemen:

 

seit einer Weile habe ich nun eine neues Build von MC, was die Bugfixes und noch so einige neue Dinge enthält. Auf diese Version möchte ich aber nicht weiter eingehen. Die Version 8.5 Beta 1 ist ja angekündigt -- vielleicht im Frühjahr als Release, who knows ... Für 9.0 gibt es in der PM - Übersicht auch bereits einen Eintrag, kann aber sicherlich noch eine Weile ein Jährchen dauern. Den MC-Blog interpretiere ich so, dass 8.1 nur für die .Net - Version angedacht ist.

 

Auf jeden Fall sind einerseits die Probleme hinsichtlich Einfrieren und verloren gehende Drawings-Einstellungen (verschiedene wie Fibo-Sachen, Pfeile, ...) nicht mehr vorhanden. Bei letzterem Punkt war die Base Data der Drawings nicht immer das eigentliche Symbol. Sollte sich angeblich mit Hilfe der einstellbaren Visual Order ändern lassen, insbesondere, wenn man 'Barpainting' betreibt. Das funktionierte bei mir jedoch nicht ... letztlich aber ist auch das Problem behoben. Weiterhin hatte ich nach dem ersten Versuch nach der Neuinstallation leise das Gefühl, dass MC beim Start als auch Beenden schneller unterwegs ist. Jetzt nach einer Weile bin ich mir ziemlich sicher, dass sich hinsichtlich Performance beim Beenden einiges getan hat. Es hakelt auch nicht mehr so und der nach Beendigung von MC u. QM gestartete Prozess startet jetzt unmittelbar nach deren Beendigung. Wer es nicht kennt, dieser Prozess zeigt nur eine kleine Progressbar an und schreibt die im Cache befindlichen Daten in die History. Sicherlich ist das schnelle Beenden von MC relativ unwichtig, jedoch nicht, wenn man an der Stelle im Fehlerfall oder gar Einfrieren Angst um seine Daten und Workspaceeinstellungen haben muss (bleibt MC beim Abspeichern vor einem ungespeicherten Workspace hängen, war die Arbeit für die Katz). Wenn es dann jedoch rutscht und flutscht, braucht man sich keine Sorgen zu machen und kann schnell von einem Task zum nächsten Wechseln. Bei größerer Last von MC war das einfach nur nervig bis sehr ärgerlich.

 

Kurzum: da scheint sich einiges getan zu haben, mit einem sehr zufriedenstellenden Ergebnis.