Sonntag, 9. März 2008, 12:59
Hallo Herr Knöpfel,
@Frieder
Es besteht ja auch die Möglichkeit überhaupt nicht zu protokollieren.
Vuego
evtl. ließe sich das ja automatisch via Aufgabenmanager lösen (Löschen und Archivierung der Logdateien in regelmäßigen Abständen).ich meinte nicht die Orderbucheinträge unter "Orderbuch" des ORM, sondern die LOG-Dateien unter Order/Einstellungen/Protokolle......
@Frieder
Es besteht ja auch die Möglichkeit überhaupt nicht zu protokollieren.
Vuego
Montag, 10. März 2008, 09:03
Hallo Gerasan
Deine Timelags sehen wirklich noch schlimmer aus als meine
zumal Du alles auf einer schnellen Raid-0 C-Platte lokal hast.
Lokal waren meine Tests sogar mit 3x Voll-HS eher im Bereich 0-3 Sekunden. Schlimm wurde es eigentlich erst beim Remote-Zugriff auf die RTT Daten zur Fastmarket Zeit - desswegen kam ich, wie von verschiedenen Kollegen in diesem Thread erwähnt, ebenfalls zum Schluss, dass es sich um ein I/O Problem handelt, was über das LAN verstärkt wird: den Zugriff von Investox auf das langsame SMB-Protokoll (Windows Shares) habe ich im Verdacht!
Deine Timelags sehen wirklich noch schlimmer aus als meine
zumal Du alles auf einer schnellen Raid-0 C-Platte lokal hast.Lokal waren meine Tests sogar mit 3x Voll-HS eher im Bereich 0-3 Sekunden. Schlimm wurde es eigentlich erst beim Remote-Zugriff auf die RTT Daten zur Fastmarket Zeit - desswegen kam ich, wie von verschiedenen Kollegen in diesem Thread erwähnt, ebenfalls zum Schluss, dass es sich um ein I/O Problem handelt, was über das LAN verstärkt wird: den Zugriff von Investox auf das langsame SMB-Protokoll (Windows Shares) habe ich im Verdacht!
Gruss
Bernd
Bernd
Mittwoch, 12. März 2008, 01:05
Hallo Frieder
Ich habe die Protokolle gelöscht und mein 3 Systeme gestern über weite Strecken und heute den ganzen Tag laufen lassen.
Meine Timelags (Differenz lt. Signalprotokoll Datum/Uhrzeit - Tickzeit) für 3x Voll-Handelssystem mit Remote RTT/Tenfore Datenfeed wie beschrieben sind:
* gestern 257 Signalen im Durchschnitt bei 2 Sekunden Timelag, maximal 12 Sekunden
* während der Businesszeit waren es davon 220 Signale, im Durchschnitt 3 Sekunden Timelag, maximal 12 Sekunden
* heute hatte ich 850 Signale im Durchschnitt bei 2 Sekunden Timelag, maximal 12 Sekunden
* während der Buesinesszeit waren es davon 302 Signale, im Durchschnitt 2 Sekunden Timelag, maximal 12 Sekunden
Dabei habe ich nur Signale erzeugt, aber sie nicht geroutet, so dass sich die Log-Dateien NICHT um diese Anzahl von Einträgen aufgebaut haben.
Leider sind die Timelags immer noch weit von meinem Ziel (95% bei 0 Sekunden) entfernt! Danke Dir erstmal trotzdem.
ich meinte nicht die Orderbucheinträge unter "Orderbuch" des ORM, sondern die LOG-Dateien unter Order/Einstellungen/Protokolle......
Ich habe die Protokolle gelöscht und mein 3 Systeme gestern über weite Strecken und heute den ganzen Tag laufen lassen.
Meine Timelags (Differenz lt. Signalprotokoll Datum/Uhrzeit - Tickzeit) für 3x Voll-Handelssystem mit Remote RTT/Tenfore Datenfeed wie beschrieben sind:
* gestern 257 Signalen im Durchschnitt bei 2 Sekunden Timelag, maximal 12 Sekunden
* während der Businesszeit waren es davon 220 Signale, im Durchschnitt 3 Sekunden Timelag, maximal 12 Sekunden
* heute hatte ich 850 Signale im Durchschnitt bei 2 Sekunden Timelag, maximal 12 Sekunden
* während der Buesinesszeit waren es davon 302 Signale, im Durchschnitt 2 Sekunden Timelag, maximal 12 Sekunden
Dabei habe ich nur Signale erzeugt, aber sie nicht geroutet, so dass sich die Log-Dateien NICHT um diese Anzahl von Einträgen aufgebaut haben.
Leider sind die Timelags immer noch weit von meinem Ziel (95% bei 0 Sekunden) entfernt! Danke Dir erstmal trotzdem.
Gruss
Bernd
Bernd
Donnerstag, 13. März 2008, 00:48
Hallo Herr Knöpfel
Ich habe die 850 Signale von gestern noch genauer untersucht. Sie setzen sich so zusammen:
Sekunde Anzahl
0 167
1 326
2 151
3 83
4 48
5 22
6 11
7 11
8 9
9 6
10 9
11 6
12 1
Man sieht, dass es nur einen Fall mit 12 Sekunden Timelag gab, 6 mit 11 Sekunden usw. Also insgesamt tendieren die Signale zu kürzeren Timelags, aber es gibt diese Ausreisser, welche das finanzielle Ergebnis erheblich beeinträchtigen können!
Dabei haben nur die 3 Systeme aktualisiert. Sonst waren keine weiteren HSe und keine weiteren Projekte offen. Berechnungstitel waren auch keine aktiv.
Aktualisierung ist auf alle 0 Sekunden, Signalberechnung nur nach Kursänderung, gesetzt. Leistungsschema, importierte Titel etc. habe ich hier beschrieben in dem an Sie adressierten Text-Teil.
Heute hatte ich nun die selben 3 Systeme mit identischen Einstellungen gegen RTT Titel lokal laufen; es hat sich diese Verteilung der Timelags ergeben:
Sekunde Anzahl
0 911
1 589
2 2
Das heisst, obwohl ich auf dem Rechner lokal nur eine "langsame" 1 TB Platte (7200 uMin.) am Start habe, wären es eigentlich im grossen und ganzen Timelags, die dem erwarteten Bereich schon recht nahe kommen. Wird dagegen via Netzwerk auf die RTT/Tenfore Daten des Sammel-PCs zugegriffen, so entstehen erst die grossen Timelags !!! Und das, obwohl ich ein GB-LAN installiert habe sowie auf dem Sammel-PC die schnelle Raptor Hard-Disk mit 10.000 UMin. und < 4.6 ms mittlere Zugriffszeit!
Es scheint sich also ein I/O Problem abzuzeichnen. Die Fragen sind:
* kann ich auf meiner Seite noch etwas tun, um die Remote Timelags auf die Werte der lokalen Timelags zu reduzieren?
* ist eine Anpassung wie von Udo und anderen Kollegen nachgefragt in Planung, um zwischen RTT und Investox direkt zu streamen, statt über die langsamen Windows Shared Ordner (SMB-Protokoll) gehen zu müssen?
Ich habe mal noch den Netzwerk-Verkehr des Sammel-PCs angesehen:
* wenn dort nur die RTT/Tenfore Daten gesammelt werden (53 Titel mit Geld und Brief), dann sieht man eine Netzwerk-Auslastung unter 0,1% (Bild 1)
* wenn dann die drei Systeme aktiviert werden, so steigt die Netzwerk-Auslastung auf ca. 2,5% (Bild 2) - und dies, obwohl die 3 Systeme nur die gerade vorher von Tenfore downgestreamten Titel lesen und davon sogar nur 3 Titel OHNE Geld/Brief verwendet werden!
Ich habe jetzt mal einfach das Gefühl, dass Verbesserungen in der Kommunikation RTT -> Investox erheblich zur Senkung der Timelags beitragen könnten!
auffällig sind ja die starken Unterschiede von 2-12s. Was ist die Ursache hierfür?
Ich habe die 850 Signale von gestern noch genauer untersucht. Sie setzen sich so zusammen:
Sekunde Anzahl
0 167
1 326
2 151
3 83
4 48
5 22
6 11
7 11
8 9
9 6
10 9
11 6
12 1
Man sieht, dass es nur einen Fall mit 12 Sekunden Timelag gab, 6 mit 11 Sekunden usw. Also insgesamt tendieren die Signale zu kürzeren Timelags, aber es gibt diese Ausreisser, welche das finanzielle Ergebnis erheblich beeinträchtigen können!
Aktualisieren mehrere Systeme, wenn es zu den längeren Verzögerungen kommt, oder sind noch Berechnungstitel aktiv?
Dabei haben nur die 3 Systeme aktualisiert. Sonst waren keine weiteren HSe und keine weiteren Projekte offen. Berechnungstitel waren auch keine aktiv.
Wie lauten die Aktualisierungseinstellungen der HS, wieviele Ticks werden importiert (Leistungsschema?), etc. Ohne genauere Hinweise kann man da wenig sagen.
Aktualisierung ist auf alle 0 Sekunden, Signalberechnung nur nach Kursänderung, gesetzt. Leistungsschema, importierte Titel etc. habe ich hier beschrieben in dem an Sie adressierten Text-Teil.
Heute hatte ich nun die selben 3 Systeme mit identischen Einstellungen gegen RTT Titel lokal laufen; es hat sich diese Verteilung der Timelags ergeben:
Sekunde Anzahl
0 911
1 589
2 2
Das heisst, obwohl ich auf dem Rechner lokal nur eine "langsame" 1 TB Platte (7200 uMin.) am Start habe, wären es eigentlich im grossen und ganzen Timelags, die dem erwarteten Bereich schon recht nahe kommen. Wird dagegen via Netzwerk auf die RTT/Tenfore Daten des Sammel-PCs zugegriffen, so entstehen erst die grossen Timelags !!! Und das, obwohl ich ein GB-LAN installiert habe sowie auf dem Sammel-PC die schnelle Raptor Hard-Disk mit 10.000 UMin. und < 4.6 ms mittlere Zugriffszeit!
Es scheint sich also ein I/O Problem abzuzeichnen. Die Fragen sind:
* kann ich auf meiner Seite noch etwas tun, um die Remote Timelags auf die Werte der lokalen Timelags zu reduzieren?
* ist eine Anpassung wie von Udo und anderen Kollegen nachgefragt in Planung, um zwischen RTT und Investox direkt zu streamen, statt über die langsamen Windows Shared Ordner (SMB-Protokoll) gehen zu müssen?
Ich habe mal noch den Netzwerk-Verkehr des Sammel-PCs angesehen:
* wenn dort nur die RTT/Tenfore Daten gesammelt werden (53 Titel mit Geld und Brief), dann sieht man eine Netzwerk-Auslastung unter 0,1% (Bild 1)
* wenn dann die drei Systeme aktiviert werden, so steigt die Netzwerk-Auslastung auf ca. 2,5% (Bild 2) - und dies, obwohl die 3 Systeme nur die gerade vorher von Tenfore downgestreamten Titel lesen und davon sogar nur 3 Titel OHNE Geld/Brief verwendet werden!
Ich habe jetzt mal einfach das Gefühl, dass Verbesserungen in der Kommunikation RTT -> Investox erheblich zur Senkung der Timelags beitragen könnten!
Gruss
Bernd
Bernd
Donnerstag, 13. März 2008, 09:03
Hallo,
>>Verbesserungen in der Kommunikation RTT -> Investox erheblich zur Senkung der Timelags
wenn es nicht um Millisekunden, sondern um mehrere Sekunden geht, dann hat das Protokoll damit sicher nichts zu tun. Als Ursache der größeren Time-Lags habe ich am ehesten den Import großer Tickmengen über das Netzwerk im Verdacht (40 Tage Tickdaten sind je nach Titel ja nicht wenig, vielleicht können Sie diese auch noch reduzieren).
Daher hatte ich auch geschrieben:
Wenn wirklich unkomprimierte Daten verwendet werden, wäre die effektivste Maßnahme zur Verbesserung im Netzbetrieb die lokale Zwischenspeicherung auch von unkomprimierten Tickdaten.
Viele Grüße
Andreas Knöpfel
>>Verbesserungen in der Kommunikation RTT -> Investox erheblich zur Senkung der Timelags
wenn es nicht um Millisekunden, sondern um mehrere Sekunden geht, dann hat das Protokoll damit sicher nichts zu tun. Als Ursache der größeren Time-Lags habe ich am ehesten den Import großer Tickmengen über das Netzwerk im Verdacht (40 Tage Tickdaten sind je nach Titel ja nicht wenig, vielleicht können Sie diese auch noch reduzieren).
Daher hatte ich auch geschrieben:
Zitat
Zudem würde ich empfehlen zu prüfen, ob die Verwendung von unkomprimierten Tickdaten (in Komps oder Histos) vermieden werden kann (z.B. durch Verwenden der Option "Nur Kursänderung"), da komprimierte Daten den lokalen Zwischenspeicher verwenden (Tick by Tick dagegen nicht.
Wenn wirklich unkomprimierte Daten verwendet werden, wäre die effektivste Maßnahme zur Verbesserung im Netzbetrieb die lokale Zwischenspeicherung auch von unkomprimierten Tickdaten.
Viele Grüße
Andreas Knöpfel
Dienstag, 18. März 2008, 01:48
Hallo Herr Knöpfel
Ich habe nun testweise das Leistungsschema angepasst auf Realtime Import begrenzen auf 2 Tage (statt 40 Tage, also nur noch einen Bruchteil gegenüber den vorhergehenden Tests!), und wie gehabt: Kombititel nur letzten Titel verwenden. Die Begrenzung der komprimierten Perioden steht auch wie bisher auf Standard, das ist 32000.
Die Verteilung der Timelags sieht für den 17.03.2008 unverändert aus, nämlich:
Sekunde Anzahl
0 168
1 346
2 131
3 84
4 40
5 27
6 16
7 8
8 4
9 3
10 2
11 1
Die Titel sind definiert wie im anhängenden Bild; der RTT Titel liegt remote auf dem besagten Sammel-PC auf der WD Raptor, was könnte ich daran besser machen?
Verwende ich (gemäss dem anhängenden Bild) den lokal auf dem Handels-PC liegenden alternativen RTT/IB Titel, dann habe ich wie gepostet erheblich kleinere Timelags. Wenn das nicht am Protokoll liegt, woran kann es dann liegen?
PS: um auszuschliessen, dass es am Ende am Netzwerk liegt, verwende ich übrigens managed Gigabit Switches von HP mit sehr kleiner Latenz-Zeit (1000 Mbit: < 2,1 µs (64-Byte-Pakete)). Dieser Switch hat auch den Vorteil, dass man pro Port die Errors sehen kann und die Broadcast/Multicast Packages sowohl sehen als auch in der Bandbreite beschränken könnte. Jedenfalls ist mein Netzwerk seit Tagen Error-free und die Broadcast/Multicasts mussten nicht eingeschränkt werden, da sie nicht in signifikanter Menge auftreten. Wechselweise habe ich diese Switches auch schon gegen Gigabit Switches eines anderen Herstellers getauscht, ohne einen Unterschied feststellen zu können.
Als Ursache der größeren Time-Lags habe ich am ehesten den Import großer Tickmengen über das Netzwerk im Verdacht (40 Tage Tickdaten sind je nach Titel ja nicht wenig, vielleicht können Sie diese auch noch reduzieren).
Ich habe nun testweise das Leistungsschema angepasst auf Realtime Import begrenzen auf 2 Tage (statt 40 Tage, also nur noch einen Bruchteil gegenüber den vorhergehenden Tests!), und wie gehabt: Kombititel nur letzten Titel verwenden. Die Begrenzung der komprimierten Perioden steht auch wie bisher auf Standard, das ist 32000.
Die Verteilung der Timelags sieht für den 17.03.2008 unverändert aus, nämlich:
Sekunde Anzahl
0 168
1 346
2 131
3 84
4 40
5 27
6 16
7 8
8 4
9 3
10 2
11 1
Wenn wirklich unkomprimierte Daten verwendet werden, wäre die effektivste Maßnahme zur Verbesserung im Netzbetrieb die lokale Zwischenspeicherung auch von unkomprimierten Tickdaten.
Die Titel sind definiert wie im anhängenden Bild; der RTT Titel liegt remote auf dem besagten Sammel-PC auf der WD Raptor, was könnte ich daran besser machen?
wenn es nicht um Millisekunden, sondern um mehrere Sekunden geht, dann hat das Protokoll damit sicher nichts zu tun.
Verwende ich (gemäss dem anhängenden Bild) den lokal auf dem Handels-PC liegenden alternativen RTT/IB Titel, dann habe ich wie gepostet erheblich kleinere Timelags. Wenn das nicht am Protokoll liegt, woran kann es dann liegen?
PS: um auszuschliessen, dass es am Ende am Netzwerk liegt, verwende ich übrigens managed Gigabit Switches von HP mit sehr kleiner Latenz-Zeit (1000 Mbit: < 2,1 µs (64-Byte-Pakete)). Dieser Switch hat auch den Vorteil, dass man pro Port die Errors sehen kann und die Broadcast/Multicast Packages sowohl sehen als auch in der Bandbreite beschränken könnte. Jedenfalls ist mein Netzwerk seit Tagen Error-free und die Broadcast/Multicasts mussten nicht eingeschränkt werden, da sie nicht in signifikanter Menge auftreten. Wechselweise habe ich diese Switches auch schon gegen Gigabit Switches eines anderen Herstellers getauscht, ohne einen Unterschied feststellen zu können.
Gruss
Bernd
Bernd
Samstag, 5. April 2008, 11:16
Hallo zusammen
Ich möchte kurz berichten, was mit welchen Optionen erreicht wurde und was man noch tun könnte.
Zunächst nochmals vielen Dank an Herrn Knöpfel: eine Voraussetzung für die Verbesserungen in den Latenz-Zeiten kam mit einem verbesserten Zwischenspeicher-Management für vorkomprimierte KTs in Verbindung mit Komp() Zugriffen (betrifft also nicht RTT Direktzugriffe).
Direkt nach der Freigabe der neuen Version 5.2.1 hatte ich erstmal gar keine Verbesserung, was dann Gegenstand neuer Tests und eMails mit Herrn Knöpfel war. Das interessante Ergebnis ist, dass meine ursprüngliche KT Vorkomrimierung von 5 Minuten zuviele Ticks beinhaltete, so dass diese nicht von den Verbesserungen profitierten!
Ich bin dann mit der Vorkomrimierung auf 1 Minute herunter gegangen, und hatte "plötzlich" ein viel bessere Ergebnis als je zuvor (Handelstag am 1.4.08, wie gesagt mit einem Testsystem, was nur darauf ausgelegt war, Signale möglichst unregelmässig aber häufig zu generieren); es wurden 1795 Signale generiert mit dieser Verteilung:
Sekunde Anzahl
0 513
1 1154
2 127
3 1
(Die 3 Sekunden Latenz traten während eines morgentlichen Backups auf, die 2 Sekunden Latenzen waren ebenfalls ausserhalb der Handelszeit (das Test-Projekt lief ununterbrochen), möglicherweise auch während irgend eines Windows-Housekeepings).
Nun war das ursprüngliche Ziel: in 95% der Fälle hätte ich gerne 0 Sekunden Latenz Zeit. Darüber habe ich ebenfalls noch mit Herrn Knöpfel diskutiert: um noch weiter herunter zu kommen, müsste ich die Anzahl der Komp() verringern bzw. weitere Komp() in globale Variable nehmen. Er empfiehlt auch, die KTs eventuell in BTs auszulagern, weil diese nur 1x pro Periode berechnet werden müssen (ich würde allerdings erst alle anderen Möglichkeiten ausschöpfen, weil mir dieser Vorschlag rein gefühlsmässig die Komplexität meines Projekts zu sehr steigert).
Eine weitere Möglichkeit ergibt sich daraus, dass die Komp() Zugriffe bei Verminderung der KT Vorkomprimierung von 5 auf 1 Minute erheblich effizienter geworden sind: es könnte nämlich sein, dass eine weitere Verminderung der Vorkomprimierung, z.B. auf 10 Sekunden, die Latenz weiter Richtung Ziel verschiebt.
Man muss verstehen, dass die Verminderung der KT Vorkomprimierung (in Verbindung mit unvollendeten Perioden, die Signale werden also immer auf dem aktuellen Tick generiert) nicht zu einer Erhöhung der Anzahl benötigter Perioden im HS führt (ich also mein ursprüngliches Projekt mit den 5-Minuten HSen darin nicht auf 1 Minute umschreiben muss). Herr Knöpfel sagt dazu:
> "Eine Anpassung von 5'-HS bei der Umstellung der Kombis auf 1' ist nicht erforderlich, die Daten werden einfach im HS von 1' auf 5' hochkomprimiert.".
Mit den bisher gewonnenen Erkentnissen werde ich nun mein eigentliches Projekt anpassen und ab nächste Woche in's PT schicken. Ich bin sehr gespannt, wie sich die dann erheblich verminderte "Investox Projekt-interne" Latenz auf die Slippage auswirkt. Ich erwarte mir eine stark verbesserte Übereinstimmung der real erzielbaren Preise mit den Backtests. Denn durch die ursprünlichen grossen Sprünge in den Latenz-Zeiten waren hier immer wieder grosse Differenzen entstanden.
Wenn es klappt, habe ich dann meinen ersten automatischen Daytrader
Ich möchte kurz berichten, was mit welchen Optionen erreicht wurde und was man noch tun könnte.
Zunächst nochmals vielen Dank an Herrn Knöpfel: eine Voraussetzung für die Verbesserungen in den Latenz-Zeiten kam mit einem verbesserten Zwischenspeicher-Management für vorkomprimierte KTs in Verbindung mit Komp() Zugriffen (betrifft also nicht RTT Direktzugriffe).
Direkt nach der Freigabe der neuen Version 5.2.1 hatte ich erstmal gar keine Verbesserung, was dann Gegenstand neuer Tests und eMails mit Herrn Knöpfel war. Das interessante Ergebnis ist, dass meine ursprüngliche KT Vorkomrimierung von 5 Minuten zuviele Ticks beinhaltete, so dass diese nicht von den Verbesserungen profitierten!
Ich bin dann mit der Vorkomrimierung auf 1 Minute herunter gegangen, und hatte "plötzlich" ein viel bessere Ergebnis als je zuvor (Handelstag am 1.4.08, wie gesagt mit einem Testsystem, was nur darauf ausgelegt war, Signale möglichst unregelmässig aber häufig zu generieren); es wurden 1795 Signale generiert mit dieser Verteilung:
Sekunde Anzahl
0 513
1 1154
2 127
3 1
(Die 3 Sekunden Latenz traten während eines morgentlichen Backups auf, die 2 Sekunden Latenzen waren ebenfalls ausserhalb der Handelszeit (das Test-Projekt lief ununterbrochen), möglicherweise auch während irgend eines Windows-Housekeepings).
Nun war das ursprüngliche Ziel: in 95% der Fälle hätte ich gerne 0 Sekunden Latenz Zeit. Darüber habe ich ebenfalls noch mit Herrn Knöpfel diskutiert: um noch weiter herunter zu kommen, müsste ich die Anzahl der Komp() verringern bzw. weitere Komp() in globale Variable nehmen. Er empfiehlt auch, die KTs eventuell in BTs auszulagern, weil diese nur 1x pro Periode berechnet werden müssen (ich würde allerdings erst alle anderen Möglichkeiten ausschöpfen, weil mir dieser Vorschlag rein gefühlsmässig die Komplexität meines Projekts zu sehr steigert).
Eine weitere Möglichkeit ergibt sich daraus, dass die Komp() Zugriffe bei Verminderung der KT Vorkomprimierung von 5 auf 1 Minute erheblich effizienter geworden sind: es könnte nämlich sein, dass eine weitere Verminderung der Vorkomprimierung, z.B. auf 10 Sekunden, die Latenz weiter Richtung Ziel verschiebt.
Man muss verstehen, dass die Verminderung der KT Vorkomprimierung (in Verbindung mit unvollendeten Perioden, die Signale werden also immer auf dem aktuellen Tick generiert) nicht zu einer Erhöhung der Anzahl benötigter Perioden im HS führt (ich also mein ursprüngliches Projekt mit den 5-Minuten HSen darin nicht auf 1 Minute umschreiben muss). Herr Knöpfel sagt dazu:
> "Eine Anpassung von 5'-HS bei der Umstellung der Kombis auf 1' ist nicht erforderlich, die Daten werden einfach im HS von 1' auf 5' hochkomprimiert.".
Mit den bisher gewonnenen Erkentnissen werde ich nun mein eigentliches Projekt anpassen und ab nächste Woche in's PT schicken. Ich bin sehr gespannt, wie sich die dann erheblich verminderte "Investox Projekt-interne" Latenz auf die Slippage auswirkt. Ich erwarte mir eine stark verbesserte Übereinstimmung der real erzielbaren Preise mit den Backtests. Denn durch die ursprünlichen grossen Sprünge in den Latenz-Zeiten waren hier immer wieder grosse Differenzen entstanden.
Wenn es klappt, habe ich dann meinen ersten automatischen Daytrader
Gruss
Bernd
Bernd