Setup Dedicated Machine Chicago - My experience - Reviews of Brokers and Data Feeds | futures io social day trading
futures io futures trading


Setup Dedicated Machine Chicago - My experience
Updated: Views / Replies:25,856 / 149
Created: by liquidcci Attachments:2

Welcome to futures io.

(If you already have an account, login at the top of the page)

futures io is the largest futures trading community on the planet, with over 90,000 members. At futures io, our goal has always been and always will be to create a friendly, positive, forward-thinking community where members can openly share and discuss everything the world of trading has to offer. The community is one of the friendliest you will find on any subject, with members going out of their way to help others. Some of the primary differences between futures io and other trading sites revolve around the standards of our community. Those standards include a code of conduct for our members, as well as extremely high standards that govern which partners we do business with, and which products or services we recommend to our members.

At futures io, our focus is on quality education. No hype, gimmicks, or secret sauce. The truth is: trading is hard. To succeed, you need to surround yourself with the right support system, educational content, and trading mentors Ė all of which you can find on futures io, utilizing our social trading environment.

With futures io, you can find honest trading reviews on brokers, trading rooms, indicator packages, trading strategies, and much more. Our trading review process is highly moderated to ensure that only genuine users are allowed, so you donít need to worry about fake reviews.

We are fundamentally different than most other trading sites:
  • We are here to help. Just let us know what you need.
  • We work extremely hard to keep things positive in our community.
  • We do not tolerate rude behavior, trolling, or vendors advertising in posts.
  • We firmly believe in and encourage sharing. The holy grail is within you, we can help you find it.
  • We expect our members to participate and become a part of the community. Help yourself by helping others.

You'll need to register in order to view the content of the threads and start contributing to our community.  It's free and simple.

-- Big Mike, Site Administrator

Reply
 2  
 
Thread Tools Search this Thread
 

Setup Dedicated Machine Chicago - My experience

  #141 (permalink)
Market Wizard
Bangkok
 
Futures Experience: Intermediate
Platform: MultiCharts.NET, S5, Ninj
Broker/Data: AMP, S5, IB
Favorite Futures: ES
 
DionysusToast's Avatar
 
Posts: 2,674 since Nov 2010
Thanks: 777 given, 8,746 received
Forum Reputation: Legendary


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,

Reply With Quote
 
  #142 (permalink)
Site Administrator
Manta, Ecuador
 
Futures Experience: Advanced
Platform: My own custom solution
Favorite Futures: E-mini ES S&P 500
 
Big Mike's Avatar
 
Posts: 46,240 since Jun 2009
Thanks: 29,357 given, 83,237 received


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

Due to time constraints, please do not PM me if your question can be resolved or answered on the forum.

Need help?
1) Stop changing things. No new indicators, charts, or methods. Be consistent with what is in front of you first.
2) Start a journal and post to it daily with the trades you made to show your strengths and weaknesses.
3) Set goals for yourself to reach daily. Make them about how you trade, not how much money you make.
4) Accept responsibility for your actions. Stop looking elsewhere to explain away poor performance.
5) Where to start as a trader? Watch this webinar and read this thread for hundreds of questions and answers.
6)
Help using the forum? Watch this video to learn general tips on using the site.

If you want
to support our community, become an Elite Member.

Reply With Quote
The following 2 users say Thank You to Big Mike for this post:
 
  #143 (permalink)
Elite Member
Lehrte, Germany
 
Futures Experience: Advanced
Platform: NinjaTrader
Broker/Data: PTP / Rithmic
Favorite Futures: NQ
 
Daytrader999's Avatar
 
Posts: 1,159 since Sep 2011
Thanks: 1,137 given, 1,565 received



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)
Elite Member
Manchester, NH
 
Futures Experience: Beginner
Platform: thinkorswim
Broker/Data: TD Ameritrade
Favorite Futures: Stocks
 
Posts: 902 since Jul 2012
Thanks: 603 given, 1,785 received


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.


Last edited by artemiso; February 6th, 2013 at 04:43 AM.
Reply With Quote
The following 5 users say Thank You to artemiso for this post:
 
  #145 (permalink)
Elite Member
@ Germany
 
Futures Experience: Beginner
Platform: NinjaTrader
Broker/Data: Mirus Futures/Zen-Fire
Favorite Futures: FDAX
 
Posts: 441 since Nov 2011
Thanks: 254 given, 369 received


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
The following 2 users say Thank You to Koepisch for this post:
 
  #146 (permalink)
Banned: Duplicate users/proxy servers
Australia
 
Futures Experience: None
Platform: Paper
Broker/Data: Mirus/Zen
Favorite Futures: TF
 
Posts: 48 since Feb 2011
Thanks: 34 given, 32 received


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)
Elite Member
Manchester, NH
 
Futures Experience: Beginner
Platform: thinkorswim
Broker/Data: TD Ameritrade
Favorite Futures: Stocks
 
Posts: 902 since Jul 2012
Thanks: 603 given, 1,785 received


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.
Please register on futures.io to view futures trading content such as post attachment(s), image(s), and screenshot(s).


Zen-Fire API.
Please register on futures.io to view futures trading content such as post attachment(s), image(s), and screenshot(s).


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.


Last edited by artemiso; February 6th, 2013 at 12:41 PM.
Reply With Quote
The following 4 users say Thank You to artemiso for this post:
 
  #148 (permalink)
Trading for Fun
Wash DC
 
Futures Experience: Intermediate
Platform: multiple
Favorite Futures: varies
 
Posts: 66 since Sep 2011
Thanks: 8 given, 24 received

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?


Last edited by Frank R; February 7th, 2013 at 12:54 AM.
Reply With Quote
The following user says Thank You to Frank R for this post:
 
  #149 (permalink)
Banned: Duplicate users/proxy servers
Australia
 
Futures Experience: None
Platform: Paper
Broker/Data: Mirus/Zen
Favorite Futures: TF
 
Posts: 48 since Feb 2011
Thanks: 34 given, 32 received


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


Last edited by Bogan; February 8th, 2013 at 03:45 AM.
Reply With Quote
The following user says Thank You to Bogan for this post:
 
  #150 (permalink)
Elite Member
Manchester, NH
 
Futures Experience: Beginner
Platform: thinkorswim
Broker/Data: TD Ameritrade
Favorite Futures: Stocks
 
Posts: 902 since Jul 2012
Thanks: 603 given, 1,785 received


Replied you guys.


Last edited by artemiso; February 7th, 2013 at 04:47 PM.
Reply With Quote

Reply



futures io > > > > Setup Dedicated Machine Chicago - My experience

Thread Tools Search this Thread
Search this Thread:

Advanced Search



Upcoming Webinars and Events (4:30PM ET unless noted)

Jigsaw Trading: TBA

Elite only

FuturesTrader71: TBA

Elite only

NinjaTrader: TBA

Jan 18

RandBots: TBA

Jan 23

GFF Brokers & CME Group: Futures & Bitcoin

Elite only

Adam Grimes: TBA

Elite only

Ran Aroussi: TBA

Elite only
     

Similar Threads
Thread Thread Starter Forum Replies Last Post
Will leasing fast server in Chicago give me better fills? MadManmos Commodities Futures Trading 20 September 6th, 2016 01:22 PM
virtual private server in Chicago ? sam028 The Elite Circle 76 April 4th, 2015 11:24 AM
CME threatening to leave chicago kbit News and Current Events 3 May 21st, 2012 04:51 PM
Zen-Fire - Connect from a second machine? fluxsmith Reviews of Brokers and Data Feeds 4 July 4th, 2010 10:41 AM


All times are GMT -4. The time now is 11:06 AM.

Copyright © 2017 by futures io, s.a., Av Ricardo J. Alfaro, Century Tower, Panama, +507 833-9432, info@futures.io
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.
no new posts
Page generated 2017-12-18 in 0.15 seconds with 20 queries on phoenix via your IP 54.226.113.250