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.
Montag, 14. Februar 2011, 22:05
Die Uhrzeit wird doch von Win-XP verwaltet, oder ... ? Gibt es dort vielleicht einen Ansatzpunkt ?
Das Problem ist Windows. Das meine ich für einmal nicht ironisch; Windows ist nicht als Echtzeit-Betriebssystem entworfen worden, sondern als ereignis-geriebener Rechenknecht. Das Problem steckt also in der Architektur. Dazu kommen beim Stellen - und auch beim Abfragen / Vergleich der PC-Uhr gegen eine externe Quelle jedesmal andere Laufzeit-Unterschiede, so dass man letztendlich nicht genau sagen kann, ob zwei Uhren wirklich gleich gehen. Wie man dieses Problem lösen könnte, hat man hier z.B. in Zusammenarbeit mit der Zürcher Hochschule Winterthur untersucht.
Die Uhrzeitdifferenz bewegt sich jetzt in der Größenordnung von 0,5 sec im 3-Minuten Aktualisierungsintervall !
Du darfst nicht vergessen, dass das Synchronisieren nicht *zack* die PC Uhr auf den Stand der korrekten Uhrzeit bringt. Allenfalls, wenn die Abweichung vielleicht 30 Minuten oder mehr ist. Tatsächlich versuchen die System-Dienste, die Windows-Uhr "sanft" an die korrekte Zeit heranzuführen. Alles andere wäre ja auch schädlich, würde z.B. das abrupte Umstellen nachträglich noch Daten in bereits vergangene Datenperioden einliefern - was bei Datenbanken (oder sicher auch RTT) zu Problemen führen könnte. Wenn Du also erst vor kurzem angefangen hast, alle 3 Minuten zu syncen, dann nähert sich das System langsam dem Ziel an und bekommt ab nun alle 3 Minuten den korrekten Wert, um den es dann "herumpendel" kann.
Und 0.5 Sekunden ist doch schonmal ganz ordentlich, eine Raketa schlägst Du damit schonmal um Längen
Die soll im Bereich von -40 bis +20 Sekunden liegen - dazu liesst sich auch noch die Uhrzeit so spieziell analog auch ungewöhnlich ab ...Inzwischen habe ich den INV-Projekten eine radikale Schlankheitskur verordnet. Mal sehen was meine Rechenknechte nun dazu sagen.
Eine kleinere Zahl beschleunigt die Sache erheblich.
Die Last wird sich schon auf die Ganggenauigkeit auswirken - aber nicht bei einer Synchronisation alle 3 Minuten! Selbst auf 95% Auslastung über Wochen konnte ich bei mir hier keine grösseren Abweichungen feststellen! Wohl werden sich aber Probleme im Interrupt-Bereich (fehlerhafte Treiber, falsche I/O Modi, defekte Hardware) auf die Ganggenauigkeit der Uhr auswirken können.
08:55:02 Feb 08: Offset -231ms (ptbtime1.ptb.de, 192.53.103.108
09:02:29 Feb 09: Offset +140ms (ptbtime2.ptb.de, 192.53.103.104)
Noch ein Wort zur Verwendung dieser Zeit-Server: bitte nicht. Das sind Stratum 1 Server, und sollten nicht direkt, nicht in dieser Frequenz (alle 3 Minuten) und nicht von mehreren Maschinen aus dem gleichen Netzwerk und nicht ohne Absprache mit dem Betreiber verwendet werden!
Dies ist eine Liste der Stratum 1 Server, besser bitte Stratum 2 verwenden oder noch besser einen der NTP Pool Server, wenn man sich für ein eigenes Netzwerk schon keinen eigenen Zeitserver halten will. Dies besagen auch die Nutzungsregeln dieser "amtlichen" Server "As the load on the hosts supporting NTP primary (stratum 1) time service is heavy and always increasing, clients should avoid using the primary servers whenever possible ...".
Ich weiss schon, dass sich um sowas eh' keiner mehr schert heutzutage, aber erwähnen wollt' ich es doch und bitten. Das ganze ist hier auch mal auf deutsch und deutlich erklärt, und auch, warum diese Rücksicht angebracht wäre.
Gruss
Bernd
Bernd
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Bernd« (14. Februar 2011, 22:23)
Dienstag, 15. Februar 2011, 12:00
Danke für die Ausführungen.
08:55:02 Feb 08: Offset -231ms
09:02:29 Feb 09: Offset +140ms
sind schon wieder Schnee von gestern.
Heute : + 4.354 , + 3.789 sec.
Noch ein Wort zur Verwendung dieser Zeit-Server: bitte nicht.
Findet bei mir sofort Gehör .
Also habe ich natürlich den PTB-Zeitserver eliminiert ! (Zwischen den Zeilen : Bernd, das Beste ist doch gerade gut genug für uns )
Ach noch das: Aufgescheucht mit der Uhrzeit hatte mich der BlackBen. Er sagte nämlich, dass meine IB-Daten bestenfalls für den Müll wären
und ich meine gewinnbringenden INV-HS vergessen könnte 
Gruß,
hajo
Diese Offset-ZeitenDie Uhrzeitdifferenz bewegt sich jetzt in der Größenordnung von 0,5 sec im 3-Minuten Aktualisierungsintervall !
Und 0.5 Sekunden ist doch schonmal ganz ordentlich,
08:55:02 Feb 08: Offset -231ms
09:02:29 Feb 09: Offset +140ms
sind schon wieder Schnee von gestern.
Heute : + 4.354 , + 3.789 sec.
Noch ein Wort zur Verwendung dieser Zeit-Server: bitte nicht.
Findet bei mir sofort Gehör .
Also habe ich natürlich den PTB-Zeitserver eliminiert ! (Zwischen den Zeilen : Bernd, das Beste ist doch gerade gut genug für uns
)hmmm, wo ... ? habe ich was verpasst ... ?edit von hajo
... Gottseidank kam dann ja bald die Möglichkeit per RTT_IB einen täglichen(?) Zeitabgleich automatisch vornehmen zu lassen.
Ach noch das: Aufgescheucht mit der Uhrzeit hatte mich der BlackBen. Er sagte nämlich, dass meine IB-Daten bestenfalls für den Müll wären
und ich meine gewinnbringenden INV-HS vergessen könnte Gruß,
hajo
Dienstag, 15. Februar 2011, 17:45
Hallo hajo
Daten mit variabel fluktuierender Zeitachse zwischen 1s und 3 Minuten? Ja stimmt, die kann man auch mit dem tollen Dateninspektor aus dem Hause Knöpfel nicht mehr flicken. Da beisst die Maus kein Faden ab
Das war sicher nicht die Formulierung, denn für so eine starke Behauptung müsste man weitere Tests machen.
Nun ist es aber so, dass in die Preisentwicklung massgeblich für deren Handelsentscheidungen auch die Uhrzeit der Marktteilnehmer einfliessen, welche auf 1- 2- 5- 15- oder 60 Minuten Grenzen ihre z.B. Candles suchen oder ihre gleitenden Durchschnitte ausrichten usw., was bei Deiner Zeitreihe nun ein Zufallsprodukt ist - und dass Du deshalb die bisherigen Backtests aufgrund dieser Fantasie-Daten leider wirst vergessen müssen. Das ist ein grosser Unterschied!
Also: schmeiss die Idee nicht gleich zusammen mit den Daten weg, sondern teste auf korrekten Daten nach. Und entscheide dann.
dass meine IB-Daten bestenfalls für den Müll wären
Daten mit variabel fluktuierender Zeitachse zwischen 1s und 3 Minuten? Ja stimmt, die kann man auch mit dem tollen Dateninspektor aus dem Hause Knöpfel nicht mehr flicken. Da beisst die Maus kein Faden ab
und ich meine gewinnbringenden INV-HS vergessen könnte
Das war sicher nicht die Formulierung, denn für so eine starke Behauptung müsste man weitere Tests machen.
Nun ist es aber so, dass in die Preisentwicklung massgeblich für deren Handelsentscheidungen auch die Uhrzeit der Marktteilnehmer einfliessen, welche auf 1- 2- 5- 15- oder 60 Minuten Grenzen ihre z.B. Candles suchen oder ihre gleitenden Durchschnitte ausrichten usw., was bei Deiner Zeitreihe nun ein Zufallsprodukt ist - und dass Du deshalb die bisherigen Backtests aufgrund dieser Fantasie-Daten leider wirst vergessen müssen. Das ist ein grosser Unterschied!
Also: schmeiss die Idee nicht gleich zusammen mit den Daten weg, sondern teste auf korrekten Daten nach. Und entscheide dann.
Gruss
Bernd
Bernd
Ähnliche Themen
-
Formelsprache und Handelssystementwicklung »-
Berechnete Linie auf Zeitachse einschränken
(4. August 2009, 11:36)
-
- Formelsprache und Handelssystementwicklung »
-
Intraday High / Low in einem Zeitfenster
(15. Juni 2008, 17:18)
-
- Indikatoren und Funktionen »
-
Handelszeiten graphisch markieren
(7. Juli 2009, 18:19)
-
- Indikatoren und Funktionen »
-
DatePart und Farbstudie
(27. September 2008, 22:29)
-
- Talk, Talk und allgemeine Themen »
-
Trading Game
(12. Oktober 2004, 20:12)