INVESTOX-Forum

Hallo Udo,

vollkommen einverstanden!
Ich bin auch der Meinung, daß möglichst alles im Vorfeld einer Realisation diskutiert werden sollte. AK hat es dann sicher leichter, angesehen davon, daß hierdurch nachträgliche Mehrarbeit vermieden wird.

@AK sind wir nicht suuuuuupernett?

Mich wundert nur eins, nach der Vergangenheits-Erfahrung in ganz schlimmen Phasen (solche können auch wieder kommen!!):
Interessiert sich für dieses Thema sonst niemand? Hat keiner je Datenausfälle gehabt?
Dann braucht sich AK auch nicht weiter bemühen.

Hi all

meines bescheidenen Erachtens ist die ganze Switcherei fehleranfällig, lückenhaft und überflüssig.
Die smarteste Lösung des Problems wäre ein drittes RTT-Modul, das fähig ist, RTT-Titel mit mehreren Feeds simultan zu füttern.

In IV selbst bleibt alles so wie es aktuell ist. Gehandelt wird in IV z.B. der RTT-Titel "FDAX_MULTIFEED" aus der Tick-Datei "FDAX_MULTIFEED.RTT" mit ORM und allem Drum und Dran, so wie bisher auch.
Diese FDAX_MULTIFEED.RTT wird geschrieben von dem neuen (dritten) multifeed-fähigen RTT-Modul, nennen wir es mal "RTT3 für MF".
Als gegeben nehmen wir an, daß alle Feeds (L&P, IB u.a.) den originalen Timestamp der jeweiligen Ticks liefern, diese Ticks lediglich, beim einen oder anderen Feed, aus welchen Gründen auch immer, mal verzögert eintreffen (Schlechtwetter über Dortmund) oder für einen gewissen Zeitraum gänzlich ausfallen (IB oder SPRINT down).
RTT3 für MF schreibt (bzw. füttert IV) nun laufend aus den für diesen Titel aktivierten Feeds (theoretisch könnten es auch mehr als 2 Feeds sein) alle eintreffenden Ticks in der Reihenfolge ihres Eintreffens in die FDAX_MULTIFEED.RTT, ungeachtet dessen, aus welchem Feed sie stammen.

Um die zeitliche Chronologie zu gewährleisten, müßte RTT3 für MF lediglich den Timestamp des jeweils letzten in die RTT-Datei geschriebenen Ticks in einer Variablen mitführen und bei eintreffenden Ticks nach folgendem Algorithmus verfahren: Timestamp gleich oder jünger last_written_stamp dann schreiben, Timestamp älter als last_written_stamp dann Tick verwerfen, um die verzögerten Ticks auszufiltern. Dieser Check müßte aber im Millisekunden-Bereich machbar sein und dürfte zu keiner nennenswerten Verzögerung führen.
Das ganze natürlich auch analog dazu mit Bid/Ask-Kursen.

Das Ende vom Lied: IV handelt immer mit dem aktuellsten Tick, der aus mehreren verschiedenen Feeds verfügbar ist. Bei Ausfall oder Verzögerung eines Feeds läuft alles ohne lückenhaften Switch mit einem der anderen Feeds weiter. Erst bei Ausfall aller aktivierten Feeds helfen nur noch die (hoffentlich gesetzten) INIT-Brackets.

Parallel dazu könnte man ja für Backtest und Entwicklung weiterhin z.B. den FDAX_L&P-Feed abends mit RTT2 für TPRT backfillen und pflegen.

Hoffe, meine 2 Cents zum Thema beigetragen zu haben. Bitte nicht übel nehmen, wenn's aus Zeitmangel (wieder mal) meine einzigen Cents für mehrere Monate in diesem Forum bleiben sollten.

Viele Grüße

Jürgen Fiedler

Hallo Herr Knöpfel,
ein andauernder Daten-Mix wäre auch kontraproduktiv, aus Sicht der Berechnungen, die auf verlässliche Datenhistorien aufbauen.
Die Umschaltsituation soll schließlich nicht die Regel, sondern eine Notfall-Lösung sein und bleiben.

Derzeit laufen die DF´s recht zuverläßlich. Wir kennen es aber (leider auch verlustreich!) ganz anders!
Würde man davon ausgehen können, daß die aktuelle Verläßlichkeit Bestand hat, wäre gar kein Handlungsbedarf.

Andererseits, rechtzeitig und ausreichend überlegt, in aller Ruhe realisiert und getestet, kann man m.E. gelassen evtl. schlechteren DF-Zeiten entgegensehen.
Auf die lange Bank geschoben, kann fatal sein, denn für den intraday-Realhandel sind, neben funtionierendem INV, Realdaten das ALLERWICHTIGSTE

Eine Frage noch: wie kann es sein, daß bei Udo PTRT-Alarm sofort und bei mir erst nach ca. 2 Minuten kommt?
Wenn ich richtig weis, haben wir beide WXP und auch die neuesten Versionen von RTT´s und INV

Hallo Herr Knöpfel,

danke.
Ich meinte schon den TPRT - Alarm (siehe Bildanhang i. Beitrag 17)

@Udo
kannst du bitte nochmals checken, ob der Alarm wirklich sekundengenau mit einem "Abwürgen" erfolgt?
Wenn ich hier Firewallstop auslöse oder nach Abziehen der Routerverbindung, dauert es 2 Minuten.

@TP-Realtimedaten-User
Wie lange dauert es bei euch?

Guten Morgen,
würdet ihr bitte so nett sein, bevor ich L&P verrückt mache ...

@Udo
kannst du bitte nochmals checken, ob der Alarm wirklich sekundengenau mit einem "Abwürgen" erfolgt?
Wenn ich hier Firewallstop auslöse oder nach Abziehen der Routerverbindung, dauert es 2 Minuten.

@TP-Realtimedaten-User
Wie lange dauert es bei euch?

Hallo Udo,
danke zunächst :]
dachte schon, du ignorierst mich

Du nutzt doch auch Zonealarm?
Wenn ja, hast du für den TP-Backupserver extra etwas eintragen müssen?
Weil bei mir, gestern Mittags kam hier TP-RT-Alarm, verschiedene reconnect-Versuche ... zunächst erfolglos.
Ich nahm die firewall raus, ... zuerst wie gehabt, kein reconnect - dann aber doch im 3. Versuch.
Nun weis ich nicht, lag es an ZA oder war es generell so?

Hallo Udo,

danke.

Taipan Realtime läuft bei mir nicht mit. Ich nutzte hieraus früher eh nur die News.
Ich starte TPRT also direkt.

Das Verzögerungsproblem werde ich nach Börsenschluß "unter die Lupe" nehmen.

Hallo Moneymaker,

das Problem von letzte Woche ist für Zone Alarm eigentlich ungewöhnlich.

Zone Alarm ist eine Firewall, die sowohl mit Programmfreigaben als auch über Port Freigaben gesteuert wird.

Es wird normalerweise bei jedem neuen Programm welches ins Internet will eine neue Abfrage an den User gestellt, ob er den Zugriff gestatten will.

In Ihrem Fall war dies aber nicht so.

Es hat sich gezeigt, dass Zonealarm Programmupdates des gleichen Produktes übereinander listet.
Unter Programme in Zone Alarm sollte ein Eintrag für die Tai-Pan RT. EXE stehen mit der Versionsnummer, die Sie installiert haben. Wenn Sie nun rechte Maustaste auf diesen Eintrag - Löschen anklicken, kann es durchaus sein, dass darunter noch die vorhergehenden Versionen stehen.

Sie können einmal alle Einträge von TPR dort lösche.

Beim nächsten Start von TPR sollte dann wieder wie gewohnt einmal die Abfrage starten und danach sollten Sie wie immer arbeiten können.

Eventuell hat sich die Firewall einfach verschluckt. (finde gerade kein besseres Wort dafür)

Bei Zone Alarm muss aber keine besondere Freigabe für den Backup Server gegeben werden, da die EXE Datei freigegeben wird.

Bei den Ports ist es ebenfalls 5000 und 5001 TCP.
In Zone Alarm ebenfalls nicht von Bedeutung.

Hoffe ich konnte ein wenig helfen.

Gruss aus Dortmund

Frank Rohmann

Hallo Udo, hallo Frank,
danke für eure Ausführungen!

@Frank
der einzige Eintrag ist Tai-Pan Realtime Client 5.0 mit sämtlichen Freigebaben (4 Häkchen)

Zitat

Eventuell hat sich die Firewall einfach verschluckt

...
nehme ich auch an. Konnte gestern nichts mehr reproduzieren, auch der
Alarm kam jetzt hier sekundengenau wie bei Udo

@Udo
meines Wissens sind in "C:\WINDOWS\Internet Logs" lediglich die Textdateien, in welche (falls in ZA aktiviert) alle Logs/Tag geschrieben werden, zur nachträglichen Ansicht. Ob gelöscht oder nicht, das hat keinen Einfluß auf die Funktionen und es erfolgt entsprechend auch keine neue Zugangsabfrage.
Anders ist es, wenn ein Programm aus der Programmliste entfernt wird (ist so wie Frank es beschreibt)

Zitat

PS: Bei mir läuft es gerade anders rum:IB Daten sind zweite Wahl!

... bei mir doch auch.
Hauptlieferant ist auch bei mir n.w.v. L&P .

Hallo Udo,

Zitat

lösch mal die Internet LOGS raus und schau was passiert..

nun ... habe mir die LOGS angeschaut ... ich meinte im Vorbeitrag auch die Textdateien die "ZALog 2005 ... (Datum)" heißen (einfache Textdateien).

Löschen? ...ich werde den Teufel tun und irgendwelche andere Dateien löschen, von denen ich nicht weis, was sie bewirken.
Da sind z.B xy.RDB´s, und massenweise *.temp´s

momentan läuft ja auch alles, also ... never change a running system 8