Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
Big thanks at all of your input and i will look into the links provided. BigMike Comment No. 1 is also my understanding. Only 2 timestamps are important , first exchange time (is settled) second my local time. I can't believe that any clock Provider in the world differs in terms of seconds. If i utilize the nearest NTP Server (Radio controlled via USB is an promising Option) i have my local time. The delta time (transmission time is of course part of the overall lag) is easy to measure.
It's clear that i have to measure with my LIVE trading feed (continuum), but due to the lack of NT capabilities this isn't possible. The ping approach doesn't look reliable (TCP vs. UDP, Priority) - but without a comparision we don't know, all guessing.
The only valid test setup seems to be the R|API solution, because it's an low latency feed and i can get the exchange time stamps. Furthermore i need only a local time reference and some R|API programming. But this takes a while because i haven't a rithmic broker yet and i have to join the R|API development program. To test the VPS part is deleted from my list, because i don't assume a big lag.
It's important to understand that i only want to measure the lag to my european machine, because there is the supervisior instance to my running systems on the VPS's in the US. I have a certain amount of tolerable lag, but if the lag is too high then the trading will be blocked. Sadly i can't program all of my discretionary parts into my strategy, so i have to control my running strategies on the VPS (execution) from europe (Supervisor) . Controlling means NOT to enter trades immediately but rather SAY the strategy ENABLE auto entry detection NOW. Then the strategy is in control and searches for entry conditions usually for the next 0-60 seconds and enters per market or stop orders. It will disable himself when the setup is not occuring or an "quitting" pattern occur.
Can you help answer these questions from other members on NexusFi?
In fact +/- 10% isn't an issue and would not justify the efforts for doing it otherwise. For other reasons i wanted to switch to R|API too, so i can antedate this and make my measuring. Then the most interesting part is to compare the results with the ping results. If the costs for an usb radio clock isn't too high i will buy one (Spec: Accuracy < +/-5 ms to UTC).
For me the question is answered and i got a broad input from you guys, thanks! It's not that easy for an semi-descretionary trader trading from europe. If anybody has made some reliable statistics, here is the place to drop it.
I see. I think that the typical game console controller is more ergonomic than a keyboard, but I could be mistaken. I had friends at (if I recall correctly) SIG that spent their time tuning Playstation controllers for trading over 10 years ago and I think they have over 1400 employees today. An Xbox controller has about 9 milliseconds between button press and hitting the interface controller (several pieces were designed at Harvard, which is still the leader in tactile technologies, before Microsoft acquired them). Your ordinary USB keyboard probably has a 20 ms debouncing latency followed by 0.5-8 milliseconds of polling latency on the USB bus.
@Big Mike: I was talking about the case where the trading station is in Europe, but the broker access point near Chicago. This is more a configuration for a discretionary trader.
In my first answer - see link below - I had recommended to use a VPS located near the access point of the broker. This includes of course data centers, which serve the purpose, so I do not think that we disagree.
Koepisch: If you wish to run automated strategies on fast tick based charts for US traded futures or stocks, then you will never be happy with a European based server, but should opt for a US based VPS. Let me explain the reasons.
I've searched i view hours today about NTP and local time sync. Fortunately i've found an excellent solution for that (also defined as stratum 1 source). You can use an Raspberry PI + GPS module and some code to get an sub ms accuracy with less efforts.
VPS is good for someone with a tiny budget. Anyone who is somewhat latency sensitive won't mind spending $150 a month to get a full dedicated Xeon box at Equinix with Steadfast (etc). Anyone who is extremely latency sensitive would co-locate in Aurora.
I can't believe that anyone who was up against this problem would not already know this.