NexusFi: Find Your Edge


Home Menu

 





Setup Dedicated Machine Chicago - My experience


Discussion in Brokers

Updated
      Top Posters
    1. looks_one liquidcci with 39 posts (60 thanks)
    2. looks_two Elite with 18 posts (0 thanks)
    3. looks_3 MWinfrey with 11 posts (0 thanks)
    4. looks_4 Big Mike with 10 posts (13 thanks)
      Best Posters
    1. looks_one artemiso with 2.3 thanks per post
    2. looks_two sam028 with 2.1 thanks per post
    3. looks_3 liquidcci with 1.5 thanks per post
    4. looks_4 Big Mike with 1.3 thanks per post
    1. trending_up 45,611 views
    2. thumb_up 131 thanks given
    3. group 44 followers
    1. forum 149 posts
    2. attach_file 2 attachments




 
Search this Thread

Setup Dedicated Machine Chicago - My experience

  #141 (permalink)
 
Jigsaw Trading's Avatar
 Jigsaw Trading  Jigsaw Trading is an official Site Sponsor
 
Posts: 2,988 since Nov 2010
Thanks Given: 831
Thanks Received: 10,393


MWinfrey View Post
Then if you are logging in to the VPS and executing trades on the VPS, you are getting the benefit of faster execution along with the other benefits of a VPS.

Can I get this right?

You co-locate a machine to get better executions but you are still trading via the screen?

What is the latency/overhead of the screen sharing software?

Seems to me that unless you are fully automated, there is no benefit in co-location.

Confused,

Visit my NexusFi Trade Journal Reply With Quote

Can you help answer these questions
from other members on NexusFi?
Better Renko Gaps
The Elite Circle
ZombieSqueeze
Platforms and Indicators
My NT8 Volume Profile Split by Asian/Euro/Open
NinjaTrader
Are there any eval firms that allow you to sink to your …
Traders Hideout
NT7 Indicator Script Troubleshooting - Camarilla Pivots
NinjaTrader
 
  #142 (permalink)
 
Big Mike's Avatar
 Big Mike 
Manta, Ecuador
Site Administrator
Developer
Swing Trader
 
Experience: Advanced
Platform: Custom solution
Broker: IBKR
Trading: Stocks & Futures
Frequency: Every few days
Duration: Weeks
Posts: 50,397 since Jun 2009
Thanks Given: 33,173
Thanks Received: 101,537


DionysusToast View Post

Seems to me that unless you are fully automated, there is no benefit in co-location.

Confused,

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.

Mike

We're here to help: just ask the community or contact our Help Desk

Quick Links: Change your Username or Register as a Vendor
Searching for trading reviews? Review this list
Lifetime Elite Membership: Sign-up for only $149 USD
Exclusive money saving offers from our Site Sponsors: Browse Offers
Report problems with the site: Using the NexusFi changelog thread
Follow me on Twitter Visit my NexusFi Trade Journal Reply With Quote
Thanked by:
  #143 (permalink)
 
Daytrader999's Avatar
 Daytrader999 
Ilsede, Germany
Site Moderator
 
Experience: Advanced
Platform: NinjaTrader 8
Broker: Rithmic / CQG / Ninja Trader Brokerage
Trading: NQ
Posts: 1,525 since Sep 2011
Thanks Given: 2,067
Thanks Received: 2,316



Big Mike View Post
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.

That and the excellent service were exactly the reasons for me to decide to go with Sam's VPS.

So I'm able to access my VPS from my office computer via Teamviewer or Remote Desktop without having the need to let my Trading PC on at home.

Reply With Quote
  #144 (permalink)
 artemiso 
New York, NY
 
Experience: Beginner
Platform: Vanguard 401k
Broker: Yahoo Finance
Trading: Mutual funds
Posts: 1,152 since Jul 2012
Thanks Given: 784
Thanks Received: 2,685


Big Mike View Post
I'd like to see as well, why not post it?

Mike

I didn't want to go off-topic.


Bogan View Post
This is not to say you are wrong, but do you have anything to support this 20-30ms "claim"? Sounds like eternity to me.

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):

1. 6E 03-13, 99th% = 28 ms, max 82 ms, delayed = 5.35%
2. 6J 03-13, 99th% = 34 ms, max = 95 ms, delayed = 2.84%
3. CL 03-13, 99th% = 30 ms, max = 101 ms, delayed = 7.85%
4. ES 03-13, 99th% = 35 ms, max = 298 ms, delayed = 4.78%
5. FDAX 03-13, 99th% = 35 ms, max = 97 ms, delayed = 4.25%
6. FESX 03-13, 99th% = 36 ms, max = 98 ms, delayed = 3.44%
7. FGBM 03-13, 99th% = 34 ms, max = 63 ms, delayed = 2.05%

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.

Reply With Quote
Thanked by:
  #145 (permalink)
 Koepisch 
@ Germany
 
Experience: Beginner
Platform: NinjaTrader
Broker: Mirus Futures/Zen-Fire
Trading: FDAX
Posts: 569 since Nov 2011
Thanks Given: 440
Thanks Received: 518


artemiso View Post
...See your PM for full methodology, details...

@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.

Thanks, Koepisch

Reply With Quote
Thanked by:
  #146 (permalink)
 Bogan 
Australia
 
Posts: 48 since Feb 2011


artemiso View Post
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):

1. 6E 03-13, 99th% = 28 ms, max 82 ms, delayed = 5.35%
2. 6J 03-13, 99th% = 34 ms, max = 95 ms, delayed = 2.84%
3. CL 03-13, 99th% = 30 ms, max = 101 ms, delayed = 7.85%
4. ES 03-13, 99th% = 35 ms, max = 298 ms, delayed = 4.78%
5. FDAX 03-13, 99th% = 35 ms, max = 97 ms, delayed = 4.25%
6. FESX 03-13, 99th% = 36 ms, max = 98 ms, delayed = 3.44%
7. FGBM 03-13, 99th% = 34 ms, max = 63 ms, delayed = 2.05%

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.

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)


artemiso View Post
99th% = 28 ms, max 82 ms, delayed = 5.35%

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.

Reply With Quote
  #147 (permalink)
 artemiso 
New York, NY
 
Experience: Beginner
Platform: Vanguard 401k
Broker: Yahoo Finance
Trading: Mutual funds
Posts: 1,152 since Jul 2012
Thanks Given: 784
Thanks Received: 2,685


Koepisch View Post
@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.

Thanks, Koepisch

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.


Bogan View Post
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.

You're welcome.


Bogan View Post
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)

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.


Quoting 
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?

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.


Quoting 
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.

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.

Reply With Quote
  #148 (permalink)
Frank R
Wash DC
 
Posts: 66 since Sep 2011
Thanks Given: 8
Thanks Received: 25

Really good thread.

If I can use this as a jumping off point:

Xeno View Post
I figure the queue goes

a) the big banks and small professional companies
b) automated retail traders colocated
c) automated retail traders non-colocated
d) retail.

Wouldnt the actual 'ranking' be:

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?

Reply With Quote
Thanked by:
  #149 (permalink)
 Bogan 
Australia
 
Posts: 48 since Feb 2011


artemiso View Post
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.

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.

artemiso View Post
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.

No, I haven't seen, will probably look them up, thanks.

artemiso View Post
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.

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...

Reply With Quote
  #150 (permalink)
 artemiso 
New York, NY
 
Experience: Beginner
Platform: Vanguard 401k
Broker: Yahoo Finance
Trading: Mutual funds
Posts: 1,152 since Jul 2012
Thanks Given: 784
Thanks Received: 2,685


Replied you guys.

Reply With Quote




Last Updated on February 7, 2013


© 2024 NexusFi™, s.a., All Rights Reserved.
Av Ricardo J. Alfaro, Century Tower, Panama City, Panama, Ph: +507 833-9432 (Panama and Intl), +1 888-312-3001 (USA and Canada)
All information is for educational use only and is not investment advice. There is a substantial risk of loss in trading commodity futures, stocks, options and foreign exchange products. Past performance is not indicative of future results.
About Us - Contact Us - Site Rules, Acceptable Use, and Terms and Conditions - Privacy Policy - Downloads - Top
no new posts