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)
That is not true. If you use an ATM for example with moving targets or stops, with a moving trailing stop, then you'll see definite improvements in fills by co-locating.
Also there are many benefits outside of latency, for some - they just need a central location where it's not the system where the wife/kids use it, they can access it from any location, etc.
See your PM for full methodology, details and the data. It's not in my approved scope of usage to upload data from the raw exchange feeds publicly. Examples (Zen-Fire):
Excludes differences in internal latency by trimming out the microsecond/nanosecond parts (e.g. my CME decoder is 330 nanoseconds per message, Zen-Fire's API wrapper alone adds about 15 microseconds to R API in some cases, so the difference in internal latency is huge at this time scale) and tested on the same colo servers (CME and Eurex) to take transmission delay out of the picture. The ZF's Eurex data had to be scrubbed for error of the same sign because their data server is located in Chicago, not Frankfurt. I'll touch up on this post later, it's 3:36 AM.
@artemiso please could you explain your methodology here in more detail without violating any own rules (when you are well rested). The topic is very interesting and could make a huge difference when deciding between approximity hosting and truer colocation. It seems that no (approximity hosting) vendor is speaking about that topic - but it's clear that there must be a difference due to the bottleneck of the LAN to WAN transition. The delay times you mentioned are frighten me.
Thank you for your time and effort, I appreciate that. I read the PM, but will ask most other questions here, as I think this is of interest not only to me. But if we are told this is off topic here, we'll open another thread.
I assume that ZF data was captured on a VPS or dedicated server located in Chicago (not colocated) with sub-ms pings to ZF (Rithmic) tickers, is this correct? (as this is with what it's all started)
I read this as delay for 99% of ticks is within 28ms, max delay 82 ms, 5.35% of all ZF ticks are delayed compared to CME colocated data, is this what you mean?
BTW, if it's not a secret, who do you colocate with?
And out of minor interest, but how did you measure ZF API's intrinsic latency? I think you would need to use an account that allows concurrent connections to connect both R-API and ZF API at the same time or to use 2 equivalent ZF accounts. But I guess this is not what you did, because if you were able to use R-API directly to do that, then why bother with ZF API at all, right? ZF API, to my knowledge, is incomplete and now abandoned project, while R-API is still well supported.
Thanks for respecting my privacy. I think that most people should not worry about these delays. Let's put it in perspective - something like 1/20 ticks, you are experiencing a mean 1.4 ms delay from the data feed. This is enough to make a huge difference between proximity and colocation, but does not make any difference in execution costs if you don't know about it.
You're welcome.
No, these are on the same dedicated servers to take away the network/hardware jitter (even the temperature of your CPU would affect the hardware clocks at this time scale) from the calculations and make them the closest estimates you can get. They are located at 350 E Cermak and Frankfurt Equinix. I don't use VMs for something time-critical like this because of the excessive context switching.
That is correct. I counted 0 ms difference after round-off as "no delay" - by that criterion, only 5.35% of the messages are "delayed" (this comes round to around 3000~ delayed messages in 30 minutes). 28 ms would be the 99th percentile time, and 82 ms would be the 100th percentile time. Note that this is during the night session and the numbers will be larger in the day.
The way that you've suggested is clean too, although I didn't do that. Also, off my head I'd imagine will not eliminate differences due to your code implementation. What I did was to time the entire call stack through the rapi.dll and zenfire.dll modules so I am isolating the internal latency. Can be measured quite precisely down to the microsecond. I'm open to suggestions for better ways to do it. I don't have the time to code a proper unit test, but just screenshots from some old tests so you have an idea how I'm doing it:
R API.
Zen-Fire API.
If you've seen some other posts, I've analyzed CQG, ZF, TT, R API, IQF - I happen to have those feeds and separate brokerage accounts for them actually. ZF is nicer than Rithmic in one way - they paid extra to integrate Eurex EBS into their feed. I had ZF for a long time before I tried Rithmic, so I happen to have both.
1.) Direct Market Access with personal gateway.
2.) Co-location in the cme data centers (See LINK) with your execution service.
3.) Co-lo in the cme data center in general.
4.) Rack space at the same space and provider as your execution service.
5.) Servers discussed in this thread with sub 1ms ping to their execution service servers.
Unless you have direct market access, it is: Your server > Your execution service server > the exchange. Am I incorrect?
@artemiso Was this your point, or was it all based around data feeds?
I see you compared C++ ZF API to R-API.NET, though R-API also exists in C++. I wonder why would you do that if you are familiar with C++ and implement algorithms where microseconds count? While I accept that the same implementation may sometimes work faster in .Net than in C++, garbage collector periodically can effectively be freezing your entire .Net application for seconds in worst case scenarios. And my understanding is that ZF API is just another layer on top of R-API in attempt to increase ease of use and restrict it to ZF feed only.
No, I haven't seen, will probably look them up, thanks.
I see, I think now nothing prevents you from connecting to Eurex through R-API on ZF feed.
I was talking API vs API, not feed vs feed - I can't say anything about that. If you used or tested both ZF and Rithmic feeds - do you have any personal observations on how they compare stability and latency wise? I believe Rithmic hosts ZF tickers side by side with their own, but who knows how those servers compare hardware (read performance) wise...