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)
Recently IQFeed Support mentioned that TcpAckFrequency could make (in theory) the data feed quicker, but that it was not advisable to change this since it could negatively impact other programs. Is that a valid concern in your view? (My trading pc is fully for trading only, so no email programs or browsers that also send packages)
Even if these would help a little, I think traders may wish to optimize and take what little benefit they can get. Any advice or direction to resources on how to safely/correctly modify these for better speed would be great.
It hsould not be the correct way to change those settings. PRoblem is - it makes only sense when your base latency already is high. THAT Is the problem. Basically changing this is like changing the seatbeld when driving a car way faster than one should - yes, it helps, but it ignores the core problem.
To get the latency down, move the trading setup closer to the exchange. Depending what you trade it should be trivial to rent a VPS ina data center (or a physical machine) within 5ms of the exchange or your upstraem provider. Heck, I am 1ms behind my broker at CME and I am NOT colocating with the exchange.
I have read this thread and should I conclude that:
Not much can be done to solve latency from your trading computer to exchange with todays high speed communications networks. Distance to your data provider and order server is the decider.
VPS is only beneficial latency wise for automated systems - Remoting in would add at least the same delay to the broker plus probably more overhead.
I am about to start live scalping Eurex futures from Australia and I might want to look into my delay factor first as the FGBL can move quite quickly.
I am using Ninjatrader with AMP Futures broker and CQG feed to trade Eurex.
Can anyone help me out with:
- Where does Ninjatrader route my orders too? Chicago AMP Futures or a CQG Server located... where? (one for NT support maybe?)
- Would I be best hiring a VPS close to Eurex exchange or to CQG (wherever that is)?
- Should I move countries?
Worst case scenario I will just have to experience how my fills go.. but with ping time of >200ms to chicago I am looking at ~500ms disadvantage at best when trying to catch the edge.
From CQG - Contains IPs of the servers to Ping and is found via google so sharing link here:
"If we don't loosen up some money, this sucker is going down." -GW Bush, 2008
“Lack of proof that something is true does not prove that it is not true - when you want to believe.” -Humpty Dumpty, 2014
“The greatest shortcoming of the human race is our inability to understand the exponential function.” Prof. Albert Bartlett
Your conclusions are pretty much correct. The latency is broken into two broad parts (assuming you have DSL/ADSL or cable type technology). The local loop will be copper and latency will be determined by how close you are to the exchange. This typically is 20-40 milliseconds. Cable will be potentially better as cable companies run fibre to a distribution box in the street usually. Maybe10 ms.
The second part is directly proportional to distance, the speed of light in glass fibre is the cap. That is going to account for the rest, not much you can do about that without relocating or picking a closer exchange/broker.
There was a discussion earlier in the thread about TCP/IP tweaks. The key ones (IMHO) are the last 2 lines in the description. Some of these tweak everything whether needed or not! I am pretty sure that Zenfire (and presuambly most other data providers) use UDP for their data feed so that part won't benefit at all from these tweaks. You might shave a chunk of time off placing orders and receiving confirmation, actually it can be a good chunk of time.
False: Automated trading does not always use stop and limit orders, but an automated trading strategy can also use market orders. If you only use stop and limit orders, the latency gain of a colocated server …
About what @grahamg wrote about CQG, and their servers locations, I had some interesting information coming from one of my VPS users.
This user is using the CQG API directly to code his own system, and as he will trade CME contracts, I create his VPS on one our servers in Chicago, which seems to be the logical thing to do.
What he told was "the ping to CQG order routing server from the VPS is <1ms but somehow when I send orders using the API it takes almost 100 millisecond before I get response that order is in exchange...", and also "... they are quite slow (data comes from New York)...".
I do not have any CQG account based myself, and can't do deep tests for this, but this kind of latency is really not good at all, compared to what I usually see with my other VPS customers (few ms with Rithmic for example, same with CTS).
If should be interesting to have more details on CQG infrastructure, but I know it's not easy to get detailed information on this.
.
