Lieber Besucher, herzlich willkommen bei: INVESTOX-Forum. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.
Dienstag, 4. März 2008, 02:25
Investox time to market
Hallo zusammen
Heute schreibe ich Euch von traurigen Erlebnissen der letzten Wochen bezüglich der Signalumsetzung mit Investox und dem Ordermodul.
Vorausschicken möchte ich, dass mir für die Investox-Gegebenheiten
• ein nahezu perfektes Computer-Equipment zur Verfügung steht
• der beste sowie der zweitbeste Datenfeed, welcher derzeit an INV angebunden ist, auf meine Platten feeden (Tenfore und IB)
• mein eigenes technisches Know-How zur Beurteilung der Performance und Verbesserung der selben erheblich sind
• meine finanziellen Möglichkeiten für weitere Verbesserungen nahezu unbegrenzt sind
Trotz dieser Voraussetzungen werde ich von grossen Lücken berichten, die zwischen einem Signal (Tickzeit) und der Signalumsetzung klaffen. Ich hoffe, dass jemand im Forum mir sagen kann, was ich falsch mache. Oder – wenn nicht – wir gemeinsam und in Zusammenarbeit mit Herrn Knöpfel entscheidende Verbesserungen herbeiführen können.
Dieser Thread soll eine ernsthafte Diskussion über Handels-Timing mit Investox im unteren Millisekundenbereich werden. Desswegen möchte ich ausdrücklich betonen, dass trotz der im Folgenden geschilderten Probleme ein profitables Handeln mit Investox und den namentlich genanten Feeds möglich ist! Aber, hey, es könnte echt besser gehen
Zum Problem: zwischen der Tickzeit und der Echtzeit (Spalte Datum/Uhrzeit im Signalprotokoll) liegen jeweils zwischen 0 und 12 Sekunden; ich habe aber auch 20 Sekunden und mehr gesehen.
Diese Zeiten sind so zustand gekommen:
Versuchs-Anordnung 1:
• auf einem Rechner im Netzwerk läuft RTT/Tenfore, sonst nichts. RTT/Tenfore streamt die Daten auf eine Raptor Platte (10.000 U/min, <4,6 ms, gekühlt auf 36C, PCI im 66 MHz Modus, GB-LAN, Antwortzeit gemessen mit hrping (high resolution ping) vom Trading-PC <= 0.7 ms) Sowohl der RTT/Tenfore PC, als auch der Trading-PC (!) haben zur Business-Time eine CPU-Last < 2%.
• Die PCs sind über einen lokalen ganggenauen NTP Server alle 5 Minuten zeitsynchronisiert, der Zeitunterschied ist stets im Bereich +/- -0.0653588 Sekunden
• Trotzdem weißt das Signalprotokoll selten 0 Sekunden Zeitunterschiede aus zwischen Tickzeit und Datum/Uhrzeit; eher sind 3 bis 15 Sekunden typisch zu sehen!
• Alle Performance-Ratschläge aus dem Forum und „Projekt überprüfen“ wurden berücksichtigt (keine Charts life anzeigen; in den Formel nur das Nötigste berechnen etc. blabla); ich habe sehr viel Zeit für die Recherche und Optimierung aufgewendet
• Virenscanner und Firewalls wurden an- und abgeschaltet ohne nenneswerte Unterschiede; Paging-Files wurden an- und abgeschaltet oder auf andere Festplatten verlegt und was der Performance-Spielereien mehr sind. Es macht keinen Unterschied.
Versuchs-Anordnung 2:
• Rahmenbedingungen im Prinzip wie bei Versuch 1
• Nur habe ich den Trading-PC auf den „Alternativen Titel“ eingestell; der streamt auf dem Trading-PC mittels eines lokalen RTT/IB auf die lokale Platte.
• Zwar sind die Unterschiede zwischen Tickzeit und Datum/Uhrzeit im Durchschnitt etwas geringer als bei Versuch 1, aber auch hier sehe ich Unterschiede bis zu 12 Sekunden!
Um sicherzustellen, dass ich keinen Verklemmer im lokalen Netz, dem Router ins Web etc. habe, habe ich auf den beteiligten PCs Winamp installiert und wechselweise an meine Stereo-Anlage angeschlossen. Auf allen PCs habe ich seit Wochen amerikanisches Web-Radio „genossen“, ohne nennenswerte Aussetzer – vor allem keine im Bereich von mehr als einer Sekunde, GESCHWEIGEDENN von 3 Sekunden oder gar 20 Sekunden, wie es sich INV / ORM ständig erlaubt!
Ich kann also sagen, alle PCs arbeiten unterbruchsfrei, ohne Aussetzer, ohne hohen CPU Verbrauch, ohne zu Pagen, ohne hohe Interrupt-Last, es bleiben auch keine Semaphore liegen etc. Aber bei der Umsetzung Investox – ORM – Broker gibt es ständig Aussetzer im Sekundenbereich. Und es gibt bisher keinen Weg, sie zu erklären durch ungenügendes Tuning.
Dazu kommt:
• Direct Access Broker versuchen, in 90% der Fälle Round-Turn Zeiten von 400 ms oder besser zur Börse (!) und zurück zu erreichen
• In diesem Bereich will ich mich UNBEDINGT auch wiederfinden, möchte ich mein Vermögen doch gegen den Markt und die besten Investment-Banker der Welt mit einem starken Back-Office im Rücken wetten
• Tenfore ist etwas teurer als andere Feeder, weil man mehr Ticks pro Sekunde bekommt; diese möchte man auch umsetzen im Zeitraster UNTER einer Sekunde, sonst rechnet sich das nicht
• Alle Messungen mit hrping, netio, netserv usw. auf dem GB-LAN wurden gebenchmarkt gegen die Messergebnisse dieser Arbeit (sowohl was den Durchsatz, als auch was die Response Time betrifft) und finden sich im oberen Mittelfeld. Ich habe alles, und wenn mir jemand glaubhaft erklären kann was fehlt, wird es in wenigen Tagen hier installiert sein.
Fazit:
• selbst wenn INV / ORM mit meinen Tests wenig rechnen muss, gibt es bei Handels-Systemen im Tickbereich Aussetzer von bis zu 20 Sekunden und mehr
• Auch alles (INV + ORM + RTT + TWS) auf einem Rechner bessert die Situation nicht wirklich
• GB-LAN mit KAT 6 Kabeln hilft nicht
• Andere „Echtzeit-Anwendungen“ zeigen in der gleichen Zeit keine Aussetzer
• Ein teurer Feed wie Tenfore kann nicht sinnvoll ausgenutzt werden
Gerne lasse ich mir erklären, was ich falsch mache. Nur zu, sagt es mir bitte! Aber nur fundiert und mit detaillierten Erfahrungen untermauert, denn ich habe bereits selbst viel Zeit aufgewendet, um mit INV / ORM technisch im Tickbereich in einen professionellen Bereich zu gelangen.
Dazu habe ich jetzt schon eine Bitte an Herrn Knöpfel: im Signalprotokoll würde ich gerne (zumindest für Debugging-Zwecke einschaltbar) bei der Tickzeit und der Echtzeit (Datum/Uhrzeit) nicht nur die Sekunden, sondern die MILLIsekunden mit drei Nachkommastellen sehen (wie man auf einem Windows-PC zu Millisekunden-Timestamps gelangen kann, haben die Autoren des hrping beschrieben). Falls ich es eines Tages schaffe, Handelssysteme mit Tickzeit und Datum/Uhrzeit in der selben Sekunde zu haben, würde ich nämlich gerne sehen, wieviel Zeit mein jeweiliges HS selbst braucht für die Signalberechnung. Da ist die Auflösung von einer Sekunde ja nun offensichtlich zu ungenau.
Heute schreibe ich Euch von traurigen Erlebnissen der letzten Wochen bezüglich der Signalumsetzung mit Investox und dem Ordermodul.
Vorausschicken möchte ich, dass mir für die Investox-Gegebenheiten
• ein nahezu perfektes Computer-Equipment zur Verfügung steht
• der beste sowie der zweitbeste Datenfeed, welcher derzeit an INV angebunden ist, auf meine Platten feeden (Tenfore und IB)
• mein eigenes technisches Know-How zur Beurteilung der Performance und Verbesserung der selben erheblich sind
• meine finanziellen Möglichkeiten für weitere Verbesserungen nahezu unbegrenzt sind
Trotz dieser Voraussetzungen werde ich von grossen Lücken berichten, die zwischen einem Signal (Tickzeit) und der Signalumsetzung klaffen. Ich hoffe, dass jemand im Forum mir sagen kann, was ich falsch mache. Oder – wenn nicht – wir gemeinsam und in Zusammenarbeit mit Herrn Knöpfel entscheidende Verbesserungen herbeiführen können.
Dieser Thread soll eine ernsthafte Diskussion über Handels-Timing mit Investox im unteren Millisekundenbereich werden. Desswegen möchte ich ausdrücklich betonen, dass trotz der im Folgenden geschilderten Probleme ein profitables Handeln mit Investox und den namentlich genanten Feeds möglich ist! Aber, hey, es könnte echt besser gehen
Zum Problem: zwischen der Tickzeit und der Echtzeit (Spalte Datum/Uhrzeit im Signalprotokoll) liegen jeweils zwischen 0 und 12 Sekunden; ich habe aber auch 20 Sekunden und mehr gesehen.
Diese Zeiten sind so zustand gekommen:
Versuchs-Anordnung 1:
• auf einem Rechner im Netzwerk läuft RTT/Tenfore, sonst nichts. RTT/Tenfore streamt die Daten auf eine Raptor Platte (10.000 U/min, <4,6 ms, gekühlt auf 36C, PCI im 66 MHz Modus, GB-LAN, Antwortzeit gemessen mit hrping (high resolution ping) vom Trading-PC <= 0.7 ms) Sowohl der RTT/Tenfore PC, als auch der Trading-PC (!) haben zur Business-Time eine CPU-Last < 2%.
• Die PCs sind über einen lokalen ganggenauen NTP Server alle 5 Minuten zeitsynchronisiert, der Zeitunterschied ist stets im Bereich +/- -0.0653588 Sekunden
• Trotzdem weißt das Signalprotokoll selten 0 Sekunden Zeitunterschiede aus zwischen Tickzeit und Datum/Uhrzeit; eher sind 3 bis 15 Sekunden typisch zu sehen!
• Alle Performance-Ratschläge aus dem Forum und „Projekt überprüfen“ wurden berücksichtigt (keine Charts life anzeigen; in den Formel nur das Nötigste berechnen etc. blabla); ich habe sehr viel Zeit für die Recherche und Optimierung aufgewendet
• Virenscanner und Firewalls wurden an- und abgeschaltet ohne nenneswerte Unterschiede; Paging-Files wurden an- und abgeschaltet oder auf andere Festplatten verlegt und was der Performance-Spielereien mehr sind. Es macht keinen Unterschied.
Versuchs-Anordnung 2:
• Rahmenbedingungen im Prinzip wie bei Versuch 1
• Nur habe ich den Trading-PC auf den „Alternativen Titel“ eingestell; der streamt auf dem Trading-PC mittels eines lokalen RTT/IB auf die lokale Platte.
• Zwar sind die Unterschiede zwischen Tickzeit und Datum/Uhrzeit im Durchschnitt etwas geringer als bei Versuch 1, aber auch hier sehe ich Unterschiede bis zu 12 Sekunden!
Um sicherzustellen, dass ich keinen Verklemmer im lokalen Netz, dem Router ins Web etc. habe, habe ich auf den beteiligten PCs Winamp installiert und wechselweise an meine Stereo-Anlage angeschlossen. Auf allen PCs habe ich seit Wochen amerikanisches Web-Radio „genossen“, ohne nennenswerte Aussetzer – vor allem keine im Bereich von mehr als einer Sekunde, GESCHWEIGEDENN von 3 Sekunden oder gar 20 Sekunden, wie es sich INV / ORM ständig erlaubt!
Ich kann also sagen, alle PCs arbeiten unterbruchsfrei, ohne Aussetzer, ohne hohen CPU Verbrauch, ohne zu Pagen, ohne hohe Interrupt-Last, es bleiben auch keine Semaphore liegen etc. Aber bei der Umsetzung Investox – ORM – Broker gibt es ständig Aussetzer im Sekundenbereich. Und es gibt bisher keinen Weg, sie zu erklären durch ungenügendes Tuning.
Dazu kommt:
• Direct Access Broker versuchen, in 90% der Fälle Round-Turn Zeiten von 400 ms oder besser zur Börse (!) und zurück zu erreichen
• In diesem Bereich will ich mich UNBEDINGT auch wiederfinden, möchte ich mein Vermögen doch gegen den Markt und die besten Investment-Banker der Welt mit einem starken Back-Office im Rücken wetten
• Tenfore ist etwas teurer als andere Feeder, weil man mehr Ticks pro Sekunde bekommt; diese möchte man auch umsetzen im Zeitraster UNTER einer Sekunde, sonst rechnet sich das nicht
• Alle Messungen mit hrping, netio, netserv usw. auf dem GB-LAN wurden gebenchmarkt gegen die Messergebnisse dieser Arbeit (sowohl was den Durchsatz, als auch was die Response Time betrifft) und finden sich im oberen Mittelfeld. Ich habe alles, und wenn mir jemand glaubhaft erklären kann was fehlt, wird es in wenigen Tagen hier installiert sein.
Fazit:
• selbst wenn INV / ORM mit meinen Tests wenig rechnen muss, gibt es bei Handels-Systemen im Tickbereich Aussetzer von bis zu 20 Sekunden und mehr
• Auch alles (INV + ORM + RTT + TWS) auf einem Rechner bessert die Situation nicht wirklich
• GB-LAN mit KAT 6 Kabeln hilft nicht
• Andere „Echtzeit-Anwendungen“ zeigen in der gleichen Zeit keine Aussetzer
• Ein teurer Feed wie Tenfore kann nicht sinnvoll ausgenutzt werden
Gerne lasse ich mir erklären, was ich falsch mache. Nur zu, sagt es mir bitte! Aber nur fundiert und mit detaillierten Erfahrungen untermauert, denn ich habe bereits selbst viel Zeit aufgewendet, um mit INV / ORM technisch im Tickbereich in einen professionellen Bereich zu gelangen.
Dazu habe ich jetzt schon eine Bitte an Herrn Knöpfel: im Signalprotokoll würde ich gerne (zumindest für Debugging-Zwecke einschaltbar) bei der Tickzeit und der Echtzeit (Datum/Uhrzeit) nicht nur die Sekunden, sondern die MILLIsekunden mit drei Nachkommastellen sehen (wie man auf einem Windows-PC zu Millisekunden-Timestamps gelangen kann, haben die Autoren des hrping beschrieben). Falls ich es eines Tages schaffe, Handelssysteme mit Tickzeit und Datum/Uhrzeit in der selben Sekunde zu haben, würde ich nämlich gerne sehen, wieviel Zeit mein jeweiliges HS selbst braucht für die Signalberechnung. Da ist die Auflösung von einer Sekunde ja nun offensichtlich zu ungenau.
Gruss
Bernd
Bernd
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Bernd« (4. März 2008, 02:46)
Dienstag, 4. März 2008, 08:45
Hallo Udo
Die Formeln sind, in Verbindung mit den Historien sind eher nicht so rechenintensiv, denn die CPU Auslastung von Investox liegt bei ca. 2%, während die Gesamtlast incl. Investox typisch unter 10% liegt.
Es sind drei HSe im Projekt, Anordnung siehe Bild, die Timelags fangen alle HSe ein. Die HSe laufen auf 5 Minuten Komprimierung und unvollendeten Perioden, mit aktuell (von links nach rechts) 165, 135 und 235 Perioden limitierten Perioden des aktuellen Signals. Sie arbeiten im Original mit einigen KOMP()s. Da ich immer wieder diese Timelags beobachtet habe, wurden für die Tests die Entrys durch zufällige Einstiege "ergänzt", um genügend Verleichsdaten zu bekommen. Das Leistungsschema ist Realtime - kurze Historien mit Begrenzen auf 40 Tage und "Kombi-Titel: Nur letzten Titel verwenden". Der Zwischenspeicher wird aktuell alle 30 Minuten gelöscht. Das Orderbuch löscht automatisch alle 172800 sec. Ich habe es aber auch schon von Hand "durchgelöscht". Mit allen diesen Einstellungen habe ich aber schon heftig variiert ohne grosse Unterschiede!
Lasse ich zusätzlich zu dem Test-Projekt noch das Original-Projket, welches ich eigentlich handeln möchte, laufen: die Time-Lags sind dann in beiden Projekten gleich verteilt. Immer zwischen 0 und 12 Sekunden mit seltenen Ausreissern bis 20 Sekunden. Es macht wie es aussieht keinen Unterschied, ob ein Projekt mit drei Test-HSen alleine läuft oder beide Projekte mit zusammen sechs HSen!
Ich könnte einen Test mit Trades über Linien laufen lassen; komme aber heute nicht gleich dazu. Vielleicht heute Abend.
Übrigens habe ich die Raptor erst auf Anraten eines anderen Users im Forum eingebaut (nur auf dem RTT/Tenfore Rechner); vorher hatte ich dort eine "normal schnelle" S-ATA Platten verbaut: es hat gar keinen erkennbaren Unterschied gemacht! Die Timelags bleiben gleich. Ich könnte natürlich noch auf dem Trading-PC eine Raptor reintun: nur habe ich bei Versuchs-Anordnung 1 praktisch keine Plattenlast auf der Platte des Trading-PCs. Dieser Versuch schein mir daher wenig sinnvoll.
Sind die Formeln so rechenintensiv- und wie lang ist die gewählte Historie beim realen Handel?
Die Formeln sind, in Verbindung mit den Historien sind eher nicht so rechenintensiv, denn die CPU Auslastung von Investox liegt bei ca. 2%, während die Gesamtlast incl. Investox typisch unter 10% liegt.
Es sind drei HSe im Projekt, Anordnung siehe Bild, die Timelags fangen alle HSe ein. Die HSe laufen auf 5 Minuten Komprimierung und unvollendeten Perioden, mit aktuell (von links nach rechts) 165, 135 und 235 Perioden limitierten Perioden des aktuellen Signals. Sie arbeiten im Original mit einigen KOMP()s. Da ich immer wieder diese Timelags beobachtet habe, wurden für die Tests die Entrys durch zufällige Einstiege "ergänzt", um genügend Verleichsdaten zu bekommen. Das Leistungsschema ist Realtime - kurze Historien mit Begrenzen auf 40 Tage und "Kombi-Titel: Nur letzten Titel verwenden". Der Zwischenspeicher wird aktuell alle 30 Minuten gelöscht. Das Orderbuch löscht automatisch alle 172800 sec. Ich habe es aber auch schon von Hand "durchgelöscht". Mit allen diesen Einstellungen habe ich aber schon heftig variiert ohne grosse Unterschiede!
Lasse ich zusätzlich zu dem Test-Projekt noch das Original-Projket, welches ich eigentlich handeln möchte, laufen: die Time-Lags sind dann in beiden Projekten gleich verteilt. Immer zwischen 0 und 12 Sekunden mit seltenen Ausreissern bis 20 Sekunden. Es macht wie es aussieht keinen Unterschied, ob ein Projekt mit drei Test-HSen alleine läuft oder beide Projekte mit zusammen sechs HSen!
Ich könnte einen Test mit Trades über Linien laufen lassen; komme aber heute nicht gleich dazu. Vielleicht heute Abend.
Übrigens habe ich die Raptor erst auf Anraten eines anderen Users im Forum eingebaut (nur auf dem RTT/Tenfore Rechner); vorher hatte ich dort eine "normal schnelle" S-ATA Platten verbaut: es hat gar keinen erkennbaren Unterschied gemacht! Die Timelags bleiben gleich. Ich könnte natürlich noch auf dem Trading-PC eine Raptor reintun: nur habe ich bei Versuchs-Anordnung 1 praktisch keine Plattenlast auf der Platte des Trading-PCs. Dieser Versuch schein mir daher wenig sinnvoll.
Gruss
Bernd
Bernd
Dienstag, 4. März 2008, 10:08
Hallo Bernd,
das sind traumhafte Werte, ich würde mich freuen, wenn bei mir dauerhaft Werte unter 30% .
Wo sollen denn 12-20 Sekunden herkommen wenn Investox nichts zu tun hat, demnach auch keine Verzögerungen im Programmablauf entstehen können?
Ist die Signalgenerierung ok/korrekt?
Evtl. mal mit einem RTT-Titel testen, vielleicht macht der Kombititel Probleme.
das könnte ggfs. eine Bremse sein, vielleicht ohne Komp() testen, wird's dann deutlich besser?
Gruß, Vuego
haben zur Business-Time eine CPU-Last < 2%
das sind traumhafte Werte, ich würde mich freuen, wenn bei mir dauerhaft Werte unter 30% .
Wo sollen denn 12-20 Sekunden herkommen wenn Investox nichts zu tun hat, demnach auch keine Verzögerungen im Programmablauf entstehen können?
Ist die Signalgenerierung ok/korrekt?
Evtl. mal mit einem RTT-Titel testen, vielleicht macht der Kombititel Probleme.
Zitat
Sie arbeiten im Original mit einigen KOMP()s
das könnte ggfs. eine Bremse sein, vielleicht ohne Komp() testen, wird's dann deutlich besser?
Gruß, Vuego
Dienstag, 4. März 2008, 10:41
Hallo Bernd,
zunächst einmal solltest Du KOMP,wie vuego schrieb, herausnehmen und erneut testen. KOMP kann man übrigens auch begrenzen. Ich bin allerdings kein großer Freund der Periodenbegrenzung weil es schon zu oft vor kam, das ich zu knapp begrenzt habe und dann gar nichts mehr berechnet wurde! Ich lasse immer,wenn möglich das volle Programm laufen. Gerade bei den Histogrammen habe ich damit schon Desasters erlebt! Die Zwischenspeicherleerung sollte man etwas verlängern denn jedes neue einlesen bedeutet gleichzeitig Datenstau-wenn auch nur im niedrigen Sekundenbereich. Zu Stoßzeiten kann das aber den flüssigen Ablauf der Ticks stören! Unter HANDELSSYSTEM EINSTELLEN hast Du noch weitere Optionen für die Performance. Hast Du diese Möglichkeiten schon in Betracht gezogen? Die maximale Anzahl der Perioden nach Komprimierung sollte man,wenn möglich, bei 32.000 Perioden belassen.Bei Histogrammen ist das leider nicht immer möglich.Eine hohe Priorität bei der Aktualisierung schluckt ebenfalls Leistung.Im Normalfall genügt es, wenn man 2 Aktualisierungen/Sekunde einstellt!
Diese Time Lags kommen mir aber trotz HS-Formeln sehr ungewöhnlich vor! 3-5 Sekunden ist m.A. schon ein Grenzwert aber im Schnitt 10 Sekunden ist ungewöhnlich lang. IB,RTT und Investox lege ich grundsätzlich auf die primäre Partition um schon von Anfang an Flaschenhälse auszuschließen. Bei der heutigen Rechnerleistung ist es m.A aus Performance-Gründen nicht mehr notwendig die Tools auf logische- oder primäre Partitionen auf HD2 oder zu verteilen-es sei denn man benötigt sie unbedingt im Netzwerk!
Teste aber mal mit den Linien denn wenn es hier ebenfalls zu TimeLags kommt, muss man den Grund wo anders suchen. Ich habe selbst mit einem 1GHz Rechner und ultrakurzen Historien keine Probleme real zu routen. Lange Historien sind m.E. die größten Performance-Schlucker,auch wenn man sie begrenzt,ich weiß aber nicht warum! Aber wie schon geschrieben, ist das begrenzen nicht einfach weil man nicht weiß wie weit man begrenzen kann damit alles noch funktioniert-bzw. die Formeln und Grafiken sauber berechnet werden! Das gleiche gilt für die Berechnung im HS!
@Christian
Ich denke das kann und darf es nicht sein denn sonst kostet das Equipment noch mal 5K...
Bernd's Ansprüche sind hoch-meine auch aber dennoch komme ich mit dem "normalen Setup" so weit zurecht! In erster Linie sind hier aber auch weitere Anbindungen an hochwertige Broker so wie Datenfeeds wichtig!Das Aktuelle ist einfach zu wenig für die Kapazitätsleistung der Software!
zunächst einmal solltest Du KOMP,wie vuego schrieb, herausnehmen und erneut testen. KOMP kann man übrigens auch begrenzen. Ich bin allerdings kein großer Freund der Periodenbegrenzung weil es schon zu oft vor kam, das ich zu knapp begrenzt habe und dann gar nichts mehr berechnet wurde! Ich lasse immer,wenn möglich das volle Programm laufen. Gerade bei den Histogrammen habe ich damit schon Desasters erlebt! Die Zwischenspeicherleerung sollte man etwas verlängern denn jedes neue einlesen bedeutet gleichzeitig Datenstau-wenn auch nur im niedrigen Sekundenbereich. Zu Stoßzeiten kann das aber den flüssigen Ablauf der Ticks stören! Unter HANDELSSYSTEM EINSTELLEN hast Du noch weitere Optionen für die Performance. Hast Du diese Möglichkeiten schon in Betracht gezogen? Die maximale Anzahl der Perioden nach Komprimierung sollte man,wenn möglich, bei 32.000 Perioden belassen.Bei Histogrammen ist das leider nicht immer möglich.Eine hohe Priorität bei der Aktualisierung schluckt ebenfalls Leistung.Im Normalfall genügt es, wenn man 2 Aktualisierungen/Sekunde einstellt!
Diese Time Lags kommen mir aber trotz HS-Formeln sehr ungewöhnlich vor! 3-5 Sekunden ist m.A. schon ein Grenzwert aber im Schnitt 10 Sekunden ist ungewöhnlich lang. IB,RTT und Investox lege ich grundsätzlich auf die primäre Partition um schon von Anfang an Flaschenhälse auszuschließen. Bei der heutigen Rechnerleistung ist es m.A aus Performance-Gründen nicht mehr notwendig die Tools auf logische- oder primäre Partitionen auf HD2 oder zu verteilen-es sei denn man benötigt sie unbedingt im Netzwerk!
Teste aber mal mit den Linien denn wenn es hier ebenfalls zu TimeLags kommt, muss man den Grund wo anders suchen. Ich habe selbst mit einem 1GHz Rechner und ultrakurzen Historien keine Probleme real zu routen. Lange Historien sind m.E. die größten Performance-Schlucker,auch wenn man sie begrenzt,ich weiß aber nicht warum! Aber wie schon geschrieben, ist das begrenzen nicht einfach weil man nicht weiß wie weit man begrenzen kann damit alles noch funktioniert-bzw. die Formeln und Grafiken sauber berechnet werden! Das gleiche gilt für die Berechnung im HS!
@Christian
Ich denke das kann und darf es nicht sein denn sonst kostet das Equipment noch mal 5K...
Bernd's Ansprüche sind hoch-meine auch aber dennoch komme ich mit dem "normalen Setup" so weit zurecht! In erster Linie sind hier aber auch weitere Anbindungen an hochwertige Broker so wie Datenfeeds wichtig!Das Aktuelle ist einfach zu wenig für die Kapazitätsleistung der Software!
Happy Trading
Dienstag, 4. März 2008, 18:30
Hallo zusammen
Erstmal vielen Dank für die vielen Antworten; es gibt mir Anregungen für weitere Tests, denn ich stand zuletzte schon etwas auf dem Schlauch!
Das ist nämlich der Weg, den ich schon gegangen bin für dieses Tickdaten-System, nachdem die Entwicklung im reinen Backtest fertig war:
* Erste Testläufe zeigten Fehltrades aufgrund der unvollendeten Perioden; die glaube ich, nun komplett in den Griff bekommen zu haben
* Schlechte Performance Zeitdifferenzen Datum/Uhrzeit und Tickzeit im Bereich von bis zu 60 Sekunden: hier habe, nicht zuletzt mit den Tipps im Forum, aber auch mit dem Projekt-Ratgeber von Investox, sehr optimiert. Das Ergebnis ist ein ein performantes Setup, jedenfalls ist der CPU Verbrauch heftig reduziert worden, was eigentlich für diese Aussage spricht. Zusätzlich habe ich die Uhren der PCs eng synchroniert, weil einige der Zeitdifferenzen gar keine waren ...
* Es blieben letztlich diese beschriebenen Timelags übrig.
Also habe ich die Hardware aufgerüstet:
* GB-LAN installiert (vorher 100MB LAN); weil die Timelags immer noch da waren das GB-LAN vermessen wie beschrieben - ohne Verbesserung, das GB-LAN performt recht gut und die Antwortzeiten liegen im erwarteten Rahmen
* Raptor im RTT/Tenfore Rechner eingebaut, auch keine Verbesserung.
Tja, und nun was nützt mir ein schneller Datenfeed, wenn ich ihn nicht ausnützen kann? Das Ziel muss sein, in 95% der Fälle eine Zeitdifferenz Datum/Uhrzeit zu Tickzeit von 0 zu sehen! Aktzeptabel fände ich 500ms, aber um das zu beurteilen, müsste Herr Knöpfel die Sekunden-Anzeige im Signalprotokoll erweitern auf 3 Nachkommastellen!
Das ist genau, was ich nicht verstehe.
Ich denke schon. Sie stimmt jedenfalls mit dem Backtest überein und die Signale werden zu IB geroutet wie erwatet. Oder was meinst Du mit der Frage?
Wie geschrieben habe ich auch auf alternative Titel umgschaltet: dort habe ich jeweils einfache RTT Titel auf der lokalen Platte angehängt. Also kein Kombititel. Hier sind die Timelags schon kleiner, aber auch nicht immer ok. Ich kann aufgrund der Kombination Haupttitel = Kombititel RTT/Tenfore Titel + Historien auf der einen Seite und Alternativer Titel = RTT/IB Titel lokal momentan nicht sagen, ob es bessert, weil im zeiten Fall kein Kombititel verwendet wurde oder weil der zweite Titel lokal auf dem Rechner liegt!
Andererseits muss RTT/Tenfore fast zwingend auf einen anderen Rechner ausgelagert sein: man bezahlt bei Tenfore den Feed, und kann ihn dann EINMAL beziehen. Also müssen sich alle Handels-PCs via Netzwerk an den Datensammel-Rechner wenden! Und in dieser Konstellation brauche ich eine Lösung ohne Timelag!
probiere ich noch, wie auch die Trade-Linien, die Udo genannt hat.
Das befürchte ich inzwischen auch! Und scheinbar verschlimmert sich diese Problematik, wenn RTT separat auf einem anderen Netzwerkrechner läuft.
Ich habe mal mit Filemon von Sysinternals getraced, wie Herr Knöpfel auf die RTT Dateien zugreift. Und zwar habe ich im laufenden Betrieb der HSe Zugriffe auf den Titelcache gefunden und direkte Zugriffe. Das sieht so aus:
1 17:15:26 Investox.exe:3272 OPEN C:\Daten\Investox\Titelcache\ SUCCESS Options: Open Directory Access: All
2 17:15:26 Investox.exe:3272 DIRECTORY C:\Daten\Investox\Titelcache\ SUCCESS FileBothDirectoryInformation: BRNQ@GLOBEX_FUT_200803_USD[@#KZ#0#5#0#K].KBDAT
3 17:15:26 Investox.exe:3272 OPEN C:\Daten\Investox\Titelcache\BRNQ@GLOBEX_FUT_200803_USD[@#KZ#0#5#0#K].KBDAT SUCCESS Options: OpenIf Access: All
4 17:15:26 Investox.exe:3272 QUERY INFORMATION C:\Daten\Investox\Titelcache\BRNQ@GLOBEX_FUT_200803_USD[@#KZ#0#5#0#K].KBDAT SUCCESS Length: 309497
5 17:15:26 Investox.exe:3272 READ C:\Daten\Investox\Titelcache\BRNQ@GLOBEX_FUT_200803_USD[@#KZ#0#5#0#K].KBDAT SUCCESS Offset: 0 Length: 2
6 17:15:26 Investox.exe:3272 READ C:\Daten\Investox\Titelcache\BRNQ@GLOBEX_FUT_200803_USD[@#KZ#0#5#0#K].KBDAT SUCCESS Offset: 2 Length: 2
7 17:15:26 Investox.exe:3272 READ C:\Daten\Investox\Titelcache\BRNQ@GLOBEX_FUT_200803_USD[@#KZ#0#5#0#K].KBDAT SUCCESS Offset: 4 Length: 22
8 17:15:26 Investox.exe:3272 READ C:\Daten\Investox\Titelcache\BRNQ@GLOBEX_FUT_200803_USD[@#KZ#0#5#0#K].KBDAT SUCCESS Offset: 26 Length: 2
......
1648 17:15:27 Investox.exe:3272 READ C:\Daten\Investox\Titelcache\BRNQ@GLOBEX_FUT_200803_USD[@#KZ#0#230#0#K].KBDAT SUCCESS Offset: 6377 Length: 944
1649 17:15:27 Investox.exe:3272 CLOSE C:\Daten\Investox\Titelcache\BRNQ@GLOBEX_FUT_200803_USD[@#KZ#0#230#0#K].KBDAT SUCCESS
1650 17:15:27 Investox.exe:3272 CLOSE C:\Daten\Investox\Titelcache\ SUCCESS
1651 17:15:27 Investox.exe:3272 OPEN Q:\Daten_RTT\Investox\RealtimeData\CME Futures\ SUCCESS Options: Open Directory Access: All
1652 17:15:27 Investox.exe:3272 DIRECTORY Q:\Daten_RTT\Investox\RealtimeData\CME Futures\ SUCCESS FileBothDirectoryInformation: @ES0Y@US composite_Futures-ASK.RTT
1653 17:15:27 Investox.exe:3272 CLOSE Q:\Daten_RTT\Investox\RealtimeData\CME Futures\ SUCCESS
1654 17:15:27 Investox.exe:3272 OPEN Q:\Daten_RTT\Investox\RealtimeData\CME Futures\ SUCCESS Options: Open Directory Access: All
1655 17:15:27 Investox.exe:3272 DIRECTORY Q:\Daten_RTT\Investox\RealtimeData\CME Futures\ SUCCESS FileBothDirectoryInformation: @ES0Y@US composite_Futures-ASK.RTT
1656 17:15:27 Investox.exe:3272 OPEN Q:\Daten_RTT\Investox\RealtimeData\CME Futures\@ES0Y@US composite_Futures-ASK.RTT SUCCESS Options: OpenIf Access: All
1657 17:15:27 Investox.exe:3272 QUERY INFORMATION Q:\Daten_RTT\Investox\RealtimeData\CME Futures\@ES0Y@US composite_Futures-ASK.RTT SUCCESS FileFsDeviceInformation
1658 17:15:27 Investox.exe:3272 READ Q:\Daten_RTT\Investox\RealtimeData\CME Futures\@ES0Y@US composite_Futures-ASK.RTT SUCCESS Offset: 0 Length: 36
1659 17:15:27 Investox.exe:3272 READ Q:\Daten_RTT\Investox\RealtimeData\CME Futures\@ES0Y@US composite_Futures-ASK.RTT SUCCESS Offset: 0 Length: 4096
1660 17:15:27 Investox.exe:3272 READ Q:\Daten_RTT\Investox\RealtimeData\CME Futures\@ES0Y@US composite_Futures-ASK.RTT SUCCESS Offset: 36 Length: 2
1661 17:15:27 Investox.exe:3272 READ Q:\Daten_RTT\Investox\RealtimeData\CME Futures\@ES0Y@US composite_Futures-ASK.RTT SUCCESS Offset: 38 Length: 50
1662 17:15:27 Investox.exe:3272 READ Q:\Daten_RTT\Investox\RealtimeData\CME Futures\@ES0Y@US composite_Futures-ASK.RTT SUCCESS Offset: 88 Length: 18
1663 17:15:27 Investox.exe:3272 READ Q:\Daten_RTT\Investox\RealtimeData\CME Futures\@ES0Y@US composite_Futures-ASK.RTT SUCCESS Offset: 106 Length: 250
1664 17:15:27 Investox.exe:3272 READ Q:\Daten_RTT\Investox\RealtimeData\CME Futures\@ES0Y@US composite_Futures-ASK.RTT SUCCESS Offset: 356 Length: 2
1665 17:15:27 Investox.exe:3272 READ Q:\Daten_RTT\Investox\RealtimeData\CME Futures\@ES0Y@US composite_Futures-ASK.RTT SUCCESS Offset: 358 Length: 130
....
1701 17:15:27 Investox.exe:3272 READ Q:\Daten_RTT\Investox\RealtimeData\CME Futures\@ES0Y@US composite_Futures-ASK.RTT SUCCESS Offset: 1314398616 Length: 16
1702 17:15:27 Investox.exe:3272 READ Q:\Daten_RTT\Investox\RealtimeData\CME Futures\@ES0Y@US composite_Futures-ASK.RTT SUCCESS Offset: 1314238616 Length: 16
1703 17:15:27 Investox.exe:3272 READ Q:\Daten_RTT\Investox\RealtimeData\CME Futures\@ES0Y@US composite_Futures-ASK.RTT SUCCESS Offset: 1314078616 Length: 16
1704 17:15:27 Investox.exe:3272 READ Q:\Daten_RTT\Investox\RealtimeData\CME Futures\@ES0Y@US composite_Futures-ASK.RTT SUCCESS Offset: 1313918616 Length: 16
Das heisst, hier wird intensiv ins Filesystem gegriffen mit kleinsten Datenmengen. Und via Netzwerk wird das nicht schneller, da müssen diese tausende von 16 Byte Paketen über das SMB Protokoll verschickt werden. Das scheint mir nun wirklich nicht die beste aller denkbaren Lösungen für die Netzwerkanbindung RTT <-> Investox zu sein! RTT müsste stattdessen die Daten selbst puffern und via einem eigenen Netzwerk-Port so zur Verfügung stellen, dass die Investoxe direkt andocken können ohne Umweg über das Filesystem. Und noch was: der o.g. Trace wurde bei lokal laufendem RTT gezogen! Auch hier verständig sich Investox mit RTT also mit nichten über das Memory (wie es im Forum schon mehrfach behauptet wurde), sondern über das Filesystem !?!
(Nachricht geteilt, weil man max. 10.000 Zeichen pro Beitrag schreiben darf)
Erstmal vielen Dank für die vielen Antworten; es gibt mir Anregungen für weitere Tests, denn ich stand zuletzte schon etwas auf dem Schlauch!
Das ist nämlich der Weg, den ich schon gegangen bin für dieses Tickdaten-System, nachdem die Entwicklung im reinen Backtest fertig war:
* Erste Testläufe zeigten Fehltrades aufgrund der unvollendeten Perioden; die glaube ich, nun komplett in den Griff bekommen zu haben
* Schlechte Performance Zeitdifferenzen Datum/Uhrzeit und Tickzeit im Bereich von bis zu 60 Sekunden: hier habe, nicht zuletzt mit den Tipps im Forum, aber auch mit dem Projekt-Ratgeber von Investox, sehr optimiert. Das Ergebnis ist ein ein performantes Setup, jedenfalls ist der CPU Verbrauch heftig reduziert worden, was eigentlich für diese Aussage spricht. Zusätzlich habe ich die Uhren der PCs eng synchroniert, weil einige der Zeitdifferenzen gar keine waren ...
* Es blieben letztlich diese beschriebenen Timelags übrig.
Also habe ich die Hardware aufgerüstet:
* GB-LAN installiert (vorher 100MB LAN); weil die Timelags immer noch da waren das GB-LAN vermessen wie beschrieben - ohne Verbesserung, das GB-LAN performt recht gut und die Antwortzeiten liegen im erwarteten Rahmen
* Raptor im RTT/Tenfore Rechner eingebaut, auch keine Verbesserung.
Tja, und nun was nützt mir ein schneller Datenfeed, wenn ich ihn nicht ausnützen kann? Das Ziel muss sein, in 95% der Fälle eine Zeitdifferenz Datum/Uhrzeit zu Tickzeit von 0 zu sehen! Aktzeptabel fände ich 500ms, aber um das zu beurteilen, müsste Herr Knöpfel die Sekunden-Anzeige im Signalprotokoll erweitern auf 3 Nachkommastellen!
Wo sollen denn 12-20 Sekunden herkommen wenn Investox nichts zu tun hat, demnach auch keine Verzögerungen im Programmablauf entstehen können?
Das ist genau, was ich nicht verstehe.
Ist die Signalgenerierung ok/korrekt?
Ich denke schon. Sie stimmt jedenfalls mit dem Backtest überein und die Signale werden zu IB geroutet wie erwatet. Oder was meinst Du mit der Frage?
Evtl. mal mit einem RTT-Titel testen, vielleicht macht der Kombititel Probleme.
Wie geschrieben habe ich auch auf alternative Titel umgschaltet: dort habe ich jeweils einfache RTT Titel auf der lokalen Platte angehängt. Also kein Kombititel. Hier sind die Timelags schon kleiner, aber auch nicht immer ok. Ich kann aufgrund der Kombination Haupttitel = Kombititel RTT/Tenfore Titel + Historien auf der einen Seite und Alternativer Titel = RTT/IB Titel lokal momentan nicht sagen, ob es bessert, weil im zeiten Fall kein Kombititel verwendet wurde oder weil der zweite Titel lokal auf dem Rechner liegt!
Andererseits muss RTT/Tenfore fast zwingend auf einen anderen Rechner ausgelagert sein: man bezahlt bei Tenfore den Feed, und kann ihn dann EINMAL beziehen. Also müssen sich alle Handels-PCs via Netzwerk an den Datensammel-Rechner wenden! Und in dieser Konstellation brauche ich eine Lösung ohne Timelag!
das könnte ggfs. eine Bremse sein, vielleicht ohne Komp() testen, wird's dann deutlich besser?
probiere ich noch, wie auch die Trade-Linien, die Udo genannt hat.
Wenn ein pollendes Prinzip via Platte verwendet wurde, muss man sich nicht wundern, wenn man solche Zeiten sieht.
Das befürchte ich inzwischen auch! Und scheinbar verschlimmert sich diese Problematik, wenn RTT separat auf einem anderen Netzwerkrechner läuft.
Ich habe mal mit Filemon von Sysinternals getraced, wie Herr Knöpfel auf die RTT Dateien zugreift. Und zwar habe ich im laufenden Betrieb der HSe Zugriffe auf den Titelcache gefunden und direkte Zugriffe. Das sieht so aus:
1 17:15:26 Investox.exe:3272 OPEN C:\Daten\Investox\Titelcache\ SUCCESS Options: Open Directory Access: All
2 17:15:26 Investox.exe:3272 DIRECTORY C:\Daten\Investox\Titelcache\ SUCCESS FileBothDirectoryInformation: BRNQ@GLOBEX_FUT_200803_USD[@#KZ#0#5#0#K].KBDAT
3 17:15:26 Investox.exe:3272 OPEN C:\Daten\Investox\Titelcache\BRNQ@GLOBEX_FUT_200803_USD[@#KZ#0#5#0#K].KBDAT SUCCESS Options: OpenIf Access: All
4 17:15:26 Investox.exe:3272 QUERY INFORMATION C:\Daten\Investox\Titelcache\BRNQ@GLOBEX_FUT_200803_USD[@#KZ#0#5#0#K].KBDAT SUCCESS Length: 309497
5 17:15:26 Investox.exe:3272 READ C:\Daten\Investox\Titelcache\BRNQ@GLOBEX_FUT_200803_USD[@#KZ#0#5#0#K].KBDAT SUCCESS Offset: 0 Length: 2
6 17:15:26 Investox.exe:3272 READ C:\Daten\Investox\Titelcache\BRNQ@GLOBEX_FUT_200803_USD[@#KZ#0#5#0#K].KBDAT SUCCESS Offset: 2 Length: 2
7 17:15:26 Investox.exe:3272 READ C:\Daten\Investox\Titelcache\BRNQ@GLOBEX_FUT_200803_USD[@#KZ#0#5#0#K].KBDAT SUCCESS Offset: 4 Length: 22
8 17:15:26 Investox.exe:3272 READ C:\Daten\Investox\Titelcache\BRNQ@GLOBEX_FUT_200803_USD[@#KZ#0#5#0#K].KBDAT SUCCESS Offset: 26 Length: 2
......
1648 17:15:27 Investox.exe:3272 READ C:\Daten\Investox\Titelcache\BRNQ@GLOBEX_FUT_200803_USD[@#KZ#0#230#0#K].KBDAT SUCCESS Offset: 6377 Length: 944
1649 17:15:27 Investox.exe:3272 CLOSE C:\Daten\Investox\Titelcache\BRNQ@GLOBEX_FUT_200803_USD[@#KZ#0#230#0#K].KBDAT SUCCESS
1650 17:15:27 Investox.exe:3272 CLOSE C:\Daten\Investox\Titelcache\ SUCCESS
1651 17:15:27 Investox.exe:3272 OPEN Q:\Daten_RTT\Investox\RealtimeData\CME Futures\ SUCCESS Options: Open Directory Access: All
1652 17:15:27 Investox.exe:3272 DIRECTORY Q:\Daten_RTT\Investox\RealtimeData\CME Futures\ SUCCESS FileBothDirectoryInformation: @ES0Y@US composite_Futures-ASK.RTT
1653 17:15:27 Investox.exe:3272 CLOSE Q:\Daten_RTT\Investox\RealtimeData\CME Futures\ SUCCESS
1654 17:15:27 Investox.exe:3272 OPEN Q:\Daten_RTT\Investox\RealtimeData\CME Futures\ SUCCESS Options: Open Directory Access: All
1655 17:15:27 Investox.exe:3272 DIRECTORY Q:\Daten_RTT\Investox\RealtimeData\CME Futures\ SUCCESS FileBothDirectoryInformation: @ES0Y@US composite_Futures-ASK.RTT
1656 17:15:27 Investox.exe:3272 OPEN Q:\Daten_RTT\Investox\RealtimeData\CME Futures\@ES0Y@US composite_Futures-ASK.RTT SUCCESS Options: OpenIf Access: All
1657 17:15:27 Investox.exe:3272 QUERY INFORMATION Q:\Daten_RTT\Investox\RealtimeData\CME Futures\@ES0Y@US composite_Futures-ASK.RTT SUCCESS FileFsDeviceInformation
1658 17:15:27 Investox.exe:3272 READ Q:\Daten_RTT\Investox\RealtimeData\CME Futures\@ES0Y@US composite_Futures-ASK.RTT SUCCESS Offset: 0 Length: 36
1659 17:15:27 Investox.exe:3272 READ Q:\Daten_RTT\Investox\RealtimeData\CME Futures\@ES0Y@US composite_Futures-ASK.RTT SUCCESS Offset: 0 Length: 4096
1660 17:15:27 Investox.exe:3272 READ Q:\Daten_RTT\Investox\RealtimeData\CME Futures\@ES0Y@US composite_Futures-ASK.RTT SUCCESS Offset: 36 Length: 2
1661 17:15:27 Investox.exe:3272 READ Q:\Daten_RTT\Investox\RealtimeData\CME Futures\@ES0Y@US composite_Futures-ASK.RTT SUCCESS Offset: 38 Length: 50
1662 17:15:27 Investox.exe:3272 READ Q:\Daten_RTT\Investox\RealtimeData\CME Futures\@ES0Y@US composite_Futures-ASK.RTT SUCCESS Offset: 88 Length: 18
1663 17:15:27 Investox.exe:3272 READ Q:\Daten_RTT\Investox\RealtimeData\CME Futures\@ES0Y@US composite_Futures-ASK.RTT SUCCESS Offset: 106 Length: 250
1664 17:15:27 Investox.exe:3272 READ Q:\Daten_RTT\Investox\RealtimeData\CME Futures\@ES0Y@US composite_Futures-ASK.RTT SUCCESS Offset: 356 Length: 2
1665 17:15:27 Investox.exe:3272 READ Q:\Daten_RTT\Investox\RealtimeData\CME Futures\@ES0Y@US composite_Futures-ASK.RTT SUCCESS Offset: 358 Length: 130
....
1701 17:15:27 Investox.exe:3272 READ Q:\Daten_RTT\Investox\RealtimeData\CME Futures\@ES0Y@US composite_Futures-ASK.RTT SUCCESS Offset: 1314398616 Length: 16
1702 17:15:27 Investox.exe:3272 READ Q:\Daten_RTT\Investox\RealtimeData\CME Futures\@ES0Y@US composite_Futures-ASK.RTT SUCCESS Offset: 1314238616 Length: 16
1703 17:15:27 Investox.exe:3272 READ Q:\Daten_RTT\Investox\RealtimeData\CME Futures\@ES0Y@US composite_Futures-ASK.RTT SUCCESS Offset: 1314078616 Length: 16
1704 17:15:27 Investox.exe:3272 READ Q:\Daten_RTT\Investox\RealtimeData\CME Futures\@ES0Y@US composite_Futures-ASK.RTT SUCCESS Offset: 1313918616 Length: 16
Das heisst, hier wird intensiv ins Filesystem gegriffen mit kleinsten Datenmengen. Und via Netzwerk wird das nicht schneller, da müssen diese tausende von 16 Byte Paketen über das SMB Protokoll verschickt werden. Das scheint mir nun wirklich nicht die beste aller denkbaren Lösungen für die Netzwerkanbindung RTT <-> Investox zu sein! RTT müsste stattdessen die Daten selbst puffern und via einem eigenen Netzwerk-Port so zur Verfügung stellen, dass die Investoxe direkt andocken können ohne Umweg über das Filesystem. Und noch was: der o.g. Trace wurde bei lokal laufendem RTT gezogen! Auch hier verständig sich Investox mit RTT also mit nichten über das Memory (wie es im Forum schon mehrfach behauptet wurde), sondern über das Filesystem !?!
(Nachricht geteilt, weil man max. 10.000 Zeichen pro Beitrag schreiben darf)
Gruss
Bernd
Bernd
Dienstag, 4. März 2008, 18:30
Auch wurde IB über die TWS (ActiveX) programmtechnisch angebunden
Das wird die nächste Baustelle sein: den Timelags ORM - Provider werde ich mich zuwenden, wenn das Problem "innerhalb meines Netzwes / meiner Rechner / meiner HSe" gelöst ist. Hier werde ich mit anderen Mitteln ran müssen (Ethereal, tcpdump etc.) um herauszufinden, wo die auch hier beobachteten Timelags von anderen 1 bis 8 Sekunden zu lokalisieren sind! Auf den ersten Blick scheinen hier aber 8 Sekunden die Ausnahme zu sein und 1 bis 2 Sekunden die Regel. Aber ich habe diese Ecke noch nicht wirklich genau untersucht. Das kommt noch ...
Deine Ansprüche sind schon sehr hoch.
Investox ist für professionelle Anwender, oder habe ich da was falsch verstanden? Ich gehe davon aus, dass andere professionelle Anwender in den Märkten ebenfalls automatische HSe bis in den Tickbereich hinein handeln.
zunächst einmal solltest Du KOMP,wie vuego schrieb, herausnehmen und erneut testen. KOMP kann man übrigens auch begrenzen.
Klar, mache ich. Nur ist das dann nicht mehr das HS, welches ich handeln will. Die Perioden hab' ich schon begrenzt auf 165, 135 und 235 Perioden. Damit sind die Perioden auf die bei Komp() verwendeten Periodenlängen angepasst so dass es keine Datenpannen gibt.
Die Zwischenspeicherleerung sollte man etwas verlängern denn jedes neue einlesen bedeutet gleichzeitig Datenstau
Klar, desswegen habe ich geschrieben "Der Zwischenspeicher wird aktuell alle 30 Minuten gelöscht.". Ich habe auch anderes von nur einmal am Tag löschen bis herunter zu diesen 30 Minuten getestet. Irgendjemand hatte nämlich im Forum geschrieben, dass gerade diese Löschungen Performance bringen würden. Hat aber so oder so mein Problem nicht gelöst.
Unter HANDELSSYSTEM EINSTELLEN hast Du noch weitere Optionen für die Performance. Hast Du diese Möglichkeiten schon in Betracht gezogen?
Ja, alle. In diversen Kombinationen getetstet und auch die Forumsbeiträge zu diesen Punkten durchgearbeitet. Du, Frieder und auch andere habt dazu ja viele Beiträge verfasst!
B,RTT und Investox lege ich grundsätzlich auf die primäre Partition um schon von Anfang an Flaschenhälse auszuschließen.
Hatt ich auch und bin davon abgekommen. Der Grund ist: nach meiner Beobachtung fragmentiert RTT aufgrund der winzigsten Datenmengen pro Schreibvorgang die Platte erheblich und schnell. Damit da nicht die Betriebssystem-Files dazwischenstecken, habe ich RTT auf einen eigene Partition verbannt, welche nächtens defragmentiert wird. Das geht nach meiner Beobachtung so am schnellsten und war auch eine der Massnahmen auf dem Weg, dieses Tickdaten System performant hinzubekommen!
Ich glaube, daß das belegt, daß die Verzögerungen bei Dir wohl in den Handelssystemen zu suchen
Ich bin noch nicht sicher, möglicherweise ist es eine Kombination aus HS-Regeln (wobei der geringen CPU Verbrauch gegen Probleme im HS spricht) und der RTT/Tenfore Geschichte via Netzwerk in Verbindung mit den Filezugriffen von Investox wie beschrieben!
hängt der Timelag definitiv mit der Titelzwischenspeicherleerung zusammen. Teste bitte andere Einstellungen oder nimm den Zeitfaktor ganz heraus. 30 Minuten ist möglicherweise nicht der richtige Zeitpunkt,
Danke auch Dir, bin oben schon darauf eingegangen.
Gruss
Bernd
Bernd
Dienstag, 4. März 2008, 19:50
Manuelle Orders werden nicht im Signalprotokoll aufgezeichnet. Insofern ist für manuelle Orders kein Timelag zu ersehen / ermitteln als Differenz zwischen Datum/Uhrzeit und Tickzeit.
nun, ich denke mal, dass man, wenn man die TWS auf einem bildschirm und IV auf dem anderen hat und
immer 10 manuelle orders in serien 'rausschickt, schon sehen kann, dass es zu verzögerungen kommt, wenn das der fall
ist. mir ist so schon aufgefallen, dass, immer wenn IV aktualisiert, es teilweise die orders nicht annimmt und ich
zweimal klicken muss. dabei muss man aufpassen, dass man nicht doppelt ordert, wenn man das nicht will.
generell, habe ich den eindruck, dass IV oft durch die aktualisierungen ausgebremst wird. vielleicht hat es ja
damit etwas zu tun...
was ich z.b. extrem störend finde ist, wenn z.b. mein RTT rechner ein problem hat, IV völlig unbedienbar wird,
wenn ich auf irgendeine art und weise eine aktualisierung anfordere (vielleicht leigt das an der hohen priorität
für aktualisierungen)...
Mittwoch, 5. März 2008, 00:46
Hallo hajo
Du meinst, bei Dir gab es noch schlechtere Zeiten als bei mir? 1 Megasekunde = 1 hoch 6 Sekunden = 1000000 Sekunden = 277 Stunden? Wie hast Du es geschafft, die Stunden heute zwischen 19:10 und 19:46 Uhr unterzubringen? Respekt!
Bei mir = IB war alles im Mega- bis Gigasekunden Bereich.
Du meinst, bei Dir gab es noch schlechtere Zeiten als bei mir? 1 Megasekunde = 1 hoch 6 Sekunden = 1000000 Sekunden = 277 Stunden? Wie hast Du es geschafft, die Stunden heute zwischen 19:10 und 19:46 Uhr unterzubringen? Respekt!
Gruss
Bernd
Bernd
Mittwoch, 5. März 2008, 00:58
Hallo Bernd,
Damit meinte ich ob die Syntax in Ordnung ist, evtl. im Simulator testen ob dort sofort mit dem gleichen Tick geroutet wird, mir fällt ein man kann das dort ja nicht sehen, weil andere Zeit. Aber man kann erkennen, ob es flüssig läuft oder irgendetwas stockt.
Vuego
Ist die Signalgenerierung ok/korrekt?
Ich denke schon. Sie stimmt jedenfalls mit dem Backtest überein und die Signale werden zu IB geroutet wie erwatet. Oder was meinst Du mit der Frage?
Damit meinte ich ob die Syntax in Ordnung ist, evtl. im Simulator testen ob dort sofort mit dem gleichen Tick geroutet wird, mir fällt ein man kann das dort ja nicht sehen, weil andere Zeit. Aber man kann erkennen, ob es flüssig läuft oder irgendetwas stockt.
Vuego
Mittwoch, 5. März 2008, 09:17
Hallo Bernd,
wie schon geschrieben,versuche zunächst mit Linien und einem simplen Chartlayout die Orders zu routen.Dabei musst Du nicht vor dem PC sitzen sondern kannst pro Forma Linien reinlegen und dies autom. auslösen lassen. Das sollte auch mit 3 Pseudo Systemen in einem Project funktionieren! Du kannst die DOM- oder die Trade-Linien verwenden! Wenn Du keine Verzögerungen feststellen kannst nimm das Ursprungssystem,entferne KOMP und versuche es erneut! Wenn der Test glatt läuft, begrenze KOMP zeitlich! Wenn es hier hapert, und die Time Lags wieder auftreten sollte sich Herr Knöpfel einmal darum kümmern denn dann ist m.A. etwas nicht in Ordnung,denn das darf so nicht auftreten.Eventuell könntest Du in einem weiteren Test sämtliche Begrenzungen entfernen. Der Zwischenspeicher-egal ob voll oder leer erzeugt keine 20 sec Time-Lag!
Eine leider nicht verfügbare Lösung wäre auch, das man die Ticks primär über den Cache einliest. Bei der heutigen PC-Kapazität kann der RAM locker einen komplette Handelstag Tick speichern. Da zwischen RAM und Tick einlesen keine mech. Bauteile- wie z.B. die Festplatte liegt,gewinnt man in Stoßzeiten locker mal 2 Sekunden! Zudem sind die Datenströme nicht so anfällig,wenn man andere Arbeiten auf der Festplatte macht. 3GB RAM ist heutzutage sowieso schon "Standard" -mehr geht bei 32 B auch nicht... Vielleicht sollte Herr Knöpfel in der Tat ein 64 Bit Version anbieten, damit sich Win 64 Bit, und der damit verbundenen >3 GB Ram auch lohnt...
wie schon geschrieben,versuche zunächst mit Linien und einem simplen Chartlayout die Orders zu routen.Dabei musst Du nicht vor dem PC sitzen sondern kannst pro Forma Linien reinlegen und dies autom. auslösen lassen. Das sollte auch mit 3 Pseudo Systemen in einem Project funktionieren! Du kannst die DOM- oder die Trade-Linien verwenden! Wenn Du keine Verzögerungen feststellen kannst nimm das Ursprungssystem,entferne KOMP und versuche es erneut! Wenn der Test glatt läuft, begrenze KOMP zeitlich! Wenn es hier hapert, und die Time Lags wieder auftreten sollte sich Herr Knöpfel einmal darum kümmern denn dann ist m.A. etwas nicht in Ordnung,denn das darf so nicht auftreten.Eventuell könntest Du in einem weiteren Test sämtliche Begrenzungen entfernen. Der Zwischenspeicher-egal ob voll oder leer erzeugt keine 20 sec Time-Lag!
Eine leider nicht verfügbare Lösung wäre auch, das man die Ticks primär über den Cache einliest. Bei der heutigen PC-Kapazität kann der RAM locker einen komplette Handelstag Tick speichern. Da zwischen RAM und Tick einlesen keine mech. Bauteile- wie z.B. die Festplatte liegt,gewinnt man in Stoßzeiten locker mal 2 Sekunden! Zudem sind die Datenströme nicht so anfällig,wenn man andere Arbeiten auf der Festplatte macht. 3GB RAM ist heutzutage sowieso schon "Standard" -mehr geht bei 32 B auch nicht...
Vielleicht sollte Herr Knöpfel in der Tat ein 64 Bit Version anbieten, damit sich Win 64 Bit, und der damit verbundenen >3 GB Ram auch lohnt...
Happy Trading
Mittwoch, 5. März 2008, 14:53
Grüße nach Moskau-ist es dort auch so kalt?
Handel im ms-Bereich ist auch deswegen schwer bis unmoeglich, weil dein potenziell moeglicher kleiner Gewinn in sehr schlechtem Verhaelltnis zu dem Spread + Slippage + Gebueren steht.
Wenn man sized ist Deine Aussage nicht ganz korrekt! Daher braucht man auch die Power da man Pyramiden auf- und bei hoher Anfangs-Size abbauen muss! Jede Sekunde ist eine Sekunde zu viel! Mit den Brokern und den Datenfeeds die man an Investox koppeln kann ist dieser Handel über Investox allerdings kaum möglich da man immer Time Lags hat die schon von IB und den Vendoren vorgegeben sind! Wenn man damit richtig handeln möchte ist eine Standleitung so wie ein exzellenter Broker unbedingt notwendig! Alles andere ist in dem Bereich eine Lotterie....
Handel im ms-Bereich ist auch deswegen schwer bis unmoeglich, weil dein potenziell moeglicher kleiner Gewinn in sehr schlechtem Verhaelltnis zu dem Spread + Slippage + Gebueren steht.
Wenn man sized ist Deine Aussage nicht ganz korrekt! Daher braucht man auch die Power da man Pyramiden auf- und bei hoher Anfangs-Size abbauen muss! Jede Sekunde ist eine Sekunde zu viel! Mit den Brokern und den Datenfeeds die man an Investox koppeln kann ist dieser Handel über Investox allerdings kaum möglich da man immer Time Lags hat die schon von IB und den Vendoren vorgegeben sind! Wenn man damit richtig handeln möchte ist eine Standleitung so wie ein exzellenter Broker unbedingt notwendig! Alles andere ist in dem Bereich eine Lotterie....
Happy Trading