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



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 34,264 views
    2. thumb_up 131 thanks given
    3. group 44 followers
    1. forum 149 posts
    2. attach_file 2 attachments




Welcome to futures io: the largest futures trading community on the planet, with well over 125,000 members
  • 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 and simple.

-- Big Mike, Site Administrator

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

 
Search this Thread
 

Setup Dedicated Machine Chicago - My experience

(login for full post details)
  #101 (permalink)
 Big Mike 
Site Administrator
Swing Trader
Data Scientist & DevOps
Manta, Ecuador
 
Experience: Advanced
Platform: Custom solution
Trading: Futures & Crypto
 
Big Mike's Avatar
 
Posts: 50,002 since Jun 2009
Thanks: 32,468 given, 98,268 received


Elite View Post
I installed MC on my server.
I have come to the conclusion that this co location server doesn't help me at all for faster execusions like the opener in this thread is telling.

Based on your posts, you are not using it correctly. Co-location helps by removing your home PC from the equation. You are not doing that, you are just relaying data thru the VPS.

Co-location absolutely helps with fills, it is your setup that is wrong.

Also, please click on the word screenshot in this post to learn how to do proper screenshots without using a digital camera. It will be much easier.

Mike

We're here to help -- just ask

For the best trading education, watch our webinars
Searching for trading reviews? Review this list

Follow us on Twitter, YouTube, and Facebook

Support our community as an Elite Member:
https://futures.io/elite/

Visit other sites? Please spread the word about your experience with our community!
Follow me on Twitter Visit my futures io Trade Journal Reply With Quote
 
(login for full post details)
  #102 (permalink)
Elite
Rotterdam/Germany
 
 
Posts: 32 since Jan 2013
Thanks: 0 given, 0 received


Big Mike View Post
Based on your posts, you are not using it correctly. Co-location helps by removing your home PC from the equation. You are not doing that, you are just relaying data thru the VPS.

Co-location absolutely helps with fills, it is your setup that is wrong.

Also, please click on the word screenshot in this post to learn how to do proper screenshots without using a digital camera. It will be much easier.

Mike

Thank you Mike.

How do i need to use it correctly, what am i doing wrong/or which setup do i need to make changes?

Reply With Quote
 
(login for full post details)
  #103 (permalink)
 MWinfrey 
Lubbock TX
 
Experience: Intermediate
Platform: NinjaTrader
Broker: Stage 5 Trading
Trading: CL
 
MWinfrey's Avatar
 
Posts: 1,880 since Jul 2009
Thanks: 1,450 given, 3,325 received


Elite View Post
Thank you Mike.

How do i need to use it correctly, what am i doing wrong/or which setup do i need to make changes?

Install MC on the VPS and trade there, not on your PC.

Reply With Quote
 
(login for full post details)
  #104 (permalink)
Elite
Rotterdam/Germany
 
 
Posts: 32 since Jan 2013
Thanks: 0 given, 0 received


MWinfrey View Post
Install MC on the VPS and trade there, not on your PC.

I installed MC on my server, it's not on my own local computer

Reply With Quote
 
(login for full post details)
  #105 (permalink)
 MWinfrey 
Lubbock TX
 
Experience: Intermediate
Platform: NinjaTrader
Broker: Stage 5 Trading
Trading: CL
 
MWinfrey's Avatar
 
Posts: 1,880 since Jul 2009
Thanks: 1,450 given, 3,325 received


Elite View Post
I installed MC on my server, it's not on my own local computer

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.

Reply With Quote
 
(login for full post details)
  #106 (permalink)
Elite
Rotterdam/Germany
 
 
Posts: 32 since Jan 2013
Thanks: 0 given, 0 received


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.

I have a dedicated server, but i have not seen any benefit of faster execution as you see i have put pictures to show, does not give me faster executions, i think tehre is something wrong which i do not know

Reply With Quote
 
(login for full post details)
  #107 (permalink)
 liquidcci 
Austin, TX
 
Experience: Master
Platform: ninjatrader, r-trader
Trading: NQ, CL
 
liquidcci's Avatar
 
Posts: 865 since Jun 2011
Thanks: 610 given, 1,070 received


Elite View Post
I installed MC on my server.
I have come to the conclusion that this co location server doesn't help me at all for faster execusions like the opener in this thread is telling.

This is a 144 tick charts night trading with Strategy Automation on the ES. Market hits the price, the first bar had an up volume of 468 and the second one up volume 511. No fill and eventually stopped me out

Here market hitting my target couple of times and eventually got me filled because price went through.

Can someone clearify this for me? Are my expectation too high or does this co located server thing just being hyped up and i am paying for nothing?

I am the opener of this thread you referenced above. I have been using the setup I started this thread with for over a year. I can absolutely confirm I get better execution. I use limit orders and I have only not been filled one time which is amazing compared to how many times I would miss fills before I went to a setup like this.

"The day I became a winning trader was the day it became boring. Daily losses no longer bother me and daily wins no longer excited me. Took years of pain and busting a few accounts before finally got my mind right. I survived the darkness within and now just chillax and let my black box do the work."
Started this thread Reply With Quote
The following 2 users say Thank You to liquidcci for this post:
 
(login for full post details)
  #108 (permalink)
Elite
Rotterdam/Germany
 
 
Posts: 32 since Jan 2013
Thanks: 0 given, 0 received


liquidcci View Post
I am the opener of this thread you referenced above. I have been using the setup I started this thread with for over a year. I can absolutely confirm I get better execution. I use limit orders and I have only not been filled one time which is amazing compared to how many times I would miss fills before I went to a setup like this.

I just got mine for about 2 weeks and i have lots of no fills and jump ins, if you look at my pictures you know what i mean. Am i doing something wrong? I also trade with limit orders with automation

Reply With Quote
 
(login for full post details)
  #109 (permalink)
 ehlaban 
Netherlands
 
Experience: Advanced
Platform: Ensign, Multicharts
Trading: SP500
 
Posts: 92 since Nov 2009
Thanks: 66 given, 57 received


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.

Not if you are logged in from home on your VPS and enter the executions that way ONLY
if the trading is done automatically from the VPS.

Like Bike Mike said, you have to remove the home part completely to benefit from co-location.

Reply With Quote
 
(login for full post details)
  #110 (permalink)
Elite
Rotterdam/Germany
 
 
Posts: 32 since Jan 2013
Thanks: 0 given, 0 received


ehlaban View Post
Not if you are logged in from home on your VPS and enter the executions that way ONLY
if the trading is done automatically from the VPS.

Like Bike Mike said, you have to remove the home part completely to benefit from co-location.

I have removed everything from home part: Installed MC on the server, installed Global Zen Trader which my platform is from on the server and i log in from home with remote control mscts /span to the server. I believe this is the way to do it.

My limit orders sit on the same price as my third party softwares inputs. I dont believe a third party software anything to do with it

Reply With Quote
 
(login for full post details)
  #111 (permalink)
 ehlaban 
Netherlands
 
Experience: Advanced
Platform: Ensign, Multicharts
Trading: SP500
 
Posts: 92 since Nov 2009
Thanks: 66 given, 57 received


Elite View Post
I have removed everything from home part: Installed MC on the server, installed Global Zen Trader which my platform is from on the server and i log in from home with remote control mscts /span to the server. I believe this is the way to do it.

No this is not the way to do it!

Again you have to skip the "login from home part". This even will give more delay then trading directly from home!

Let's assume the following as an example:
Delay VPS to Broker execution is 10 ms
Delay Home to VPS is 300 ms. 300 + 10 = 310
Delay Home to Broker is 300 ms

Your login from home to your VPS will always give you 300 ms delay
for every command you execute on your VPS because you enter the
command on your home computer even if you have a remote login.


This setup if even worse then directly trading from your home with your broker
as in that case there is no VPS in between with a remote login making everything
even slower.

Reply With Quote
The following user says Thank You to ehlaban for this post:
 
(login for full post details)
  #112 (permalink)
Elite
Rotterdam/Germany
 
 
Posts: 32 since Jan 2013
Thanks: 0 given, 0 received


ehlaban View Post
No this is not the way to do it!

Again you have to skip the "login from home part". This even will give more delay then trading directly from home!

Let's assume the following as an example:
Delay VPS to Broker execution is 10 ms
Delay Home to VPS is 300 ms. 300 + 10 = 310
Delay Home to Broker is 300 ms

Your login from home to your VPS will always give you 300 ms delay
for every command you execute on your VPS because you enter the
command on your home computer even if you have a remote login.


This setup if even worse then directly trading from your home with your broker
as in that case there is no VPS in between with a remote login making everything
even slower.

Ok i believe we are coming to the solution. How do i need to skip login from home? I was told to go to start-> type in search mstsc /span(multiple monitors) a login window opens and press connect. This is the way i log in. How do i need to log in properly then?

Reply With Quote
 
(login for full post details)
  #113 (permalink)
 ehlaban 
Netherlands
 
Experience: Advanced
Platform: Ensign, Multicharts
Trading: SP500
 
Posts: 92 since Nov 2009
Thanks: 66 given, 57 received


Elite View Post
Ok i believe we are coming to the solution. How do i need to skip login from home? I was told to go to start-> type in search mstsc /span(multiple monitors) a login window opens and press connect. This is the way i log in. How do i need to log in properly then?

To get the benefits of your VPS your strategies have to run automatically on the server.

If you login on whatever way you loose the benefits, so there is no login properly.
Again remove the "home part" from the setup as has been said many times before.

Reply With Quote
 
(login for full post details)
  #114 (permalink)
 MWinfrey 
Lubbock TX
 
Experience: Intermediate
Platform: NinjaTrader
Broker: Stage 5 Trading
Trading: CL
 
MWinfrey's Avatar
 
Posts: 1,880 since Jul 2009
Thanks: 1,450 given, 3,325 received


ehlaban View Post
To get the benefits of your VPS your strategies have to run automatically on the server.

If you login on whatever way you loose the benefits, so there is no login properly.
Again remove the "home part" from the setup as has been said many times before.

If I may, @Elite has said that his strategy is running on the VPS and nothing is running on his local PC. He uses remote desktop to connect to the VPS. In this scenario, he should be getting the full benefit of using a VPS.

Reply With Quote
 
(login for full post details)
  #115 (permalink)
Elite
Rotterdam/Germany
 
 
Posts: 32 since Jan 2013
Thanks: 0 given, 0 received


MWinfrey View Post
If I may, @Elite has said that his strategy is running on the VPS and nothing is running on his local PC. He uses remote desktop to connect to the VPS. In this scenario, he should be getting the full benefit of using a VPS.

Yes this is correct, my automation runs on my vps

Reply With Quote
 
(login for full post details)
  #116 (permalink)
 MWinfrey 
Lubbock TX
 
Experience: Intermediate
Platform: NinjaTrader
Broker: Stage 5 Trading
Trading: CL
 
MWinfrey's Avatar
 
Posts: 1,880 since Jul 2009
Thanks: 1,450 given, 3,325 received


Elite View Post
Yes this is correct, my automation runs on my vps

Good. Do you do anything yourself on the VPS other than watch the automated strategy run and make sure it's doing what it's supposed to be doing?

Reply With Quote
 
(login for full post details)
  #117 (permalink)
 ehlaban 
Netherlands
 
Experience: Advanced
Platform: Ensign, Multicharts
Trading: SP500
 
Posts: 92 since Nov 2009
Thanks: 66 given, 57 received


MWinfrey View Post
If I may, @Elite has said that his strategy is running on the VPS and nothing is running on his local PC. He uses remote desktop to connect to the VPS. In this scenario, he should be getting the full benefit of using a VPS.

In general the info i have given is correct. In an earlier post i read that Elite had Multicharts remote
but later on i saw he also installed it on the server.

The question remains why does Elite login from home?

Reply With Quote
 
(login for full post details)
  #118 (permalink)
 MWinfrey 
Lubbock TX
 
Experience: Intermediate
Platform: NinjaTrader
Broker: Stage 5 Trading
Trading: CL
 
MWinfrey's Avatar
 
Posts: 1,880 since Jul 2009
Thanks: 1,450 given, 3,325 received


ehlaban View Post
In general the info i have given is correct. In an earlier post i read that Elite had Multicharts remote
but later on i saw he also installed it on the server.

The question remains why does Elite login from home?

he doesn't except using remote desktop to get to the VPS.

Reply With Quote
 
(login for full post details)
  #119 (permalink)
Elite
Rotterdam/Germany
 
 
Posts: 32 since Jan 2013
Thanks: 0 given, 0 received


MWinfrey View Post
Good. Do you do anything yourself on the VPS other than watch the automated strategy run and make sure it's doing what it's supposed to be doing?

No at 11 EST automation goes on untill 9.27 EST. I dont touch anything. This is for night trading. At 9.30 i trade manually and not with automation so SA is turned off

Reply With Quote
 
(login for full post details)
  #120 (permalink)
 MWinfrey 
Lubbock TX
 
Experience: Intermediate
Platform: NinjaTrader
Broker: Stage 5 Trading
Trading: CL
 
MWinfrey's Avatar
 
Posts: 1,880 since Jul 2009
Thanks: 1,450 given, 3,325 received


Elite View Post
No at 11 EST automation goes on untill 9.27 EST. I dont touch anything. This is for night trading. At 9.30 i trade manually and not with automation so SA is turned off

So, the automated trading is untouched. That's good. It is getting the full benefit of using the VPS.

Now to address you manual trading. I think you said you use limit orders. If this is correct, do you place them ahead of time and leave the alone?

Reply With Quote
 
(login for full post details)
  #121 (permalink)
Elite
Rotterdam/Germany
 
 
Posts: 32 since Jan 2013
Thanks: 0 given, 0 received


MWinfrey View Post
So, the automated trading is untouched. That's good. It is getting the full benefit of using the VPS.

Now to address you manual trading. I think you said you use limit orders. If this is correct, do you place them ahead of time and leave the alone?

Yes, in most cases is place my order ahead and when i get filled i adjust my limit and stop. In some cases i also try to use market order and i adjust my limit depending on market conditions

Reply With Quote
 
(login for full post details)
  #122 (permalink)
 MWinfrey 
Lubbock TX
 
Experience: Intermediate
Platform: NinjaTrader
Broker: Stage 5 Trading
Trading: CL
 
MWinfrey's Avatar
 
Posts: 1,880 since Jul 2009
Thanks: 1,450 given, 3,325 received


Elite View Post
Yes, in most cases is place my order ahead and when i get filled i adjust my limit and stop. In some cases i also try to use market order and i adjust my limit depending on market conditions

Limits placed ahead of time are ok. They will get the full benefit of using the VPS. Market orders probably won't and for explanation I refer you back to

Reply With Quote
 
(login for full post details)
  #123 (permalink)
Elite
Rotterdam/Germany
 
 
Posts: 32 since Jan 2013
Thanks: 0 given, 0 received


MWinfrey View Post
Limits placed ahead of time are ok. They will get the full benefit of using the VPS. Market orders probably won't and for explanation I refer you back to

Yes for manual it's no problem but for automation unfortunately i don't get the benefit. It looks the same like i am trading from home without any co location

Reply With Quote
 
(login for full post details)
  #124 (permalink)
 MWinfrey 
Lubbock TX
 
Experience: Intermediate
Platform: NinjaTrader
Broker: Stage 5 Trading
Trading: CL
 
MWinfrey's Avatar
 
Posts: 1,880 since Jul 2009
Thanks: 1,450 given, 3,325 received


Elite View Post
Yes for manual it's no problem but for automation unfortunately i don't get the benefit. It looks the same like i am trading from home without any co location

Is your automated trading is using limit orders or stoplimit orders?

Reply With Quote
 
(login for full post details)
  #125 (permalink)
Elite
Rotterdam/Germany
 
 
Posts: 32 since Jan 2013
Thanks: 0 given, 0 received


MWinfrey View Post
Is your automated trading is using limit orders or stoplimit orders?

It uses stop/limit orders. on each trade i go in it automatically puts a stoplimit and a limit order.

Reply With Quote
 
(login for full post details)
  #126 (permalink)
 MWinfrey 
Lubbock TX
 
Experience: Intermediate
Platform: NinjaTrader
Broker: Stage 5 Trading
Trading: CL
 
MWinfrey's Avatar
 
Posts: 1,880 since Jul 2009
Thanks: 1,450 given, 3,325 received


Elite View Post
It uses stop/limit orders. on each trade i go in it automatically puts a stoplimit and a limit order.

That's not what I was asking. Your automated strategy enters the market using what kind of order? Is it a limit order or a stoplimit order.

Based on what I remember your original post was, it sounds like it's using limit orders to enter with. That means price must go through the limit order in order to fill. There time when price passes or skips a limit order and does not fill. If the automated strategy does not cancel the entry order and price comes back to the entry order, the entry order may be filled.

None of this has anything to do with the VPS or it's efficiency.

Reply With Quote
 
(login for full post details)
  #127 (permalink)
Elite
Rotterdam/Germany
 
 
Posts: 32 since Jan 2013
Thanks: 0 given, 0 received


MWinfrey View Post
That's not what I was asking. Your automated strategy enters the market using what kind of order? Is it a limit order or a stoplimit order.

Based on what I remember your original post was, it sounds like it's using limit orders to enter with. That means price must go through the limit order in order to fill. There time when price passes or skips a limit order and does not fill. If the automated strategy does not cancel the entry order and price comes back to the entry order, the entry order may be filled.

None of this has anything to do with the VPS or it's efficiency.

It uses limit orders yes. So price must go indeed through to get filled. yes when price comes back then i gets filled. So what kind of order must i use to get the efficiecy of the vps?

Reply With Quote
 
(login for full post details)
  #128 (permalink)
 MWinfrey 
Lubbock TX
 
Experience: Intermediate
Platform: NinjaTrader
Broker: Stage 5 Trading
Trading: CL
 
MWinfrey's Avatar
 
Posts: 1,880 since Jul 2009
Thanks: 1,450 given, 3,325 received


Elite View Post
It uses limit orders yes. So price must go indeed through to get filled. yes when price comes back then i gets filled. So what kind of order must i use to get the efficiecy of the vps?

You are getting the efficiency of the VPS...

Regardless what type of order your automated strategy uses, having the automated strategy located on the VPS collocated with the exchange will get the order to the exchange faster than it will coming from anywhere else in the world.

Reply With Quote
 
(login for full post details)
  #129 (permalink)
Elite
Rotterdam/Germany
 
 
Posts: 32 since Jan 2013
Thanks: 0 given, 0 received


MWinfrey View Post
You are getting the efficiency of the VPS...

Regardless what type of order your automated strategy uses, having the automated strategy located on the VPS collocated with the exchange will get the order to the exchange faster than it will coming from anywhere else in the world.

Then why does the opener of the thread almost never needs to jump in and i had many jump ins in only the first 2 weeks?

Reply With Quote
 
(login for full post details)
  #130 (permalink)
 MWinfrey 
Lubbock TX
 
Experience: Intermediate
Platform: NinjaTrader
Broker: Stage 5 Trading
Trading: CL
 
MWinfrey's Avatar
 
Posts: 1,880 since Jul 2009
Thanks: 1,450 given, 3,325 received


Elite View Post
Then why does the opener of the thread almost never needs to jump in and i had many jump ins in only the first 2 weeks?

I'll try this again. When using limit orders, there are times when limit orders are skipped. The only way to guarantee entry is to use either stoplimit or market orders.

Reply With Quote
 
(login for full post details)
  #131 (permalink)
 liquidcci 
Austin, TX
 
Experience: Master
Platform: ninjatrader, r-trader
Trading: NQ, CL
 
liquidcci's Avatar
 
Posts: 865 since Jun 2011
Thanks: 610 given, 1,070 received


Elite View Post
Then why does the opener of the thread almost never needs to jump in and i had many jump ins in only the first 2 weeks?

You may have put this in another post but what market are you trading? If not a liquid market that could be a problem on any machine in any location. What data feed are you using? Data feed can make a big difference. Again sorry if you already posted this info.

Also could be your software or something in your code.

Many things can affect execution but if you are getting 0 ms then does not sound like an issue with remote server and with right setup this should vastly improve your fills on limits. You can still get skipped on limits like @MWinfrey mentioned but for me it does not happen often and should happen much less on server with 0 ms to the exchange by virtue of getting there faster.

"The day I became a winning trader was the day it became boring. Daily losses no longer bother me and daily wins no longer excited me. Took years of pain and busting a few accounts before finally got my mind right. I survived the darkness within and now just chillax and let my black box do the work."
Started this thread Reply With Quote
The following user says Thank You to liquidcci for this post:
 
(login for full post details)
  #132 (permalink)
Elite
Rotterdam/Germany
 
 
Posts: 32 since Jan 2013
Thanks: 0 given, 0 received


liquidcci View Post
You may have put this in another post but what market are you trading? If not a liquid market that could be a problem on any machine in any location. What data feed are you using? Data feed can make a big difference. Again sorry if you already posted this info.

Also could be your software or something in your code.

Many things can affect execution but if you are getting 0 ms then does not sound like an issue with remote server and with right setup this should vastly improve your fills on limits. You can still get skipped on limits like @MWinfrey mentioned but for me it does not happen often and should happen much less on server with 0 ms to the exchange by virtue of getting there faster.

I only trade ES emini s&p500. I only use Multicharts for data and no other data feed. My softwares are MC which i use for charting and global zen trader for my platform. I dont use any other data feed like iq feed e signal etc. this is it.

I tested from speedtest.net to chicago and had 0 ping dont know if i have to test another way the ping, but i guess ping is fine.

Reply With Quote
 
(login for full post details)
  #133 (permalink)
 liquidcci 
Austin, TX
 
Experience: Master
Platform: ninjatrader, r-trader
Trading: NQ, CL
 
liquidcci's Avatar
 
Posts: 865 since Jun 2011
Thanks: 610 given, 1,070 received


Elite View Post
I only trade ES emini s&p500. I only use Multicharts for data and no other data feed. My softwares are MC which i use for charting and global zen trader for my platform. I dont use any other data feed like iq feed e signal etc. this is it.

I tested from speedtest.net to chicago and had 0 ping dont know if i have to test another way the ping, but i guess ping is fine.

There are other ways to ping but I know the latency at Steadfast is low so should be fine. Plenty of depth on ES so that is not your problem.

So could still be your feed, software, settings. But I don't use any of things you use so can't really comment where the problem could be.

"The day I became a winning trader was the day it became boring. Daily losses no longer bother me and daily wins no longer excited me. Took years of pain and busting a few accounts before finally got my mind right. I survived the darkness within and now just chillax and let my black box do the work."
Started this thread Reply With Quote
 
(login for full post details)
  #134 (permalink)
 artemiso 
New York, NY
 
Experience: Beginner
Platform: Vanguard 401k
Broker: Yahoo Finance
Trading: Mutual funds
 
Posts: 1,129 since Jul 2012
Thanks: 765 given, 2,541 received


sam028 View Post
It's obviously not a problem related to the location or to the data center itself, but a problem with the strategy.
Your dedicated server hoster has nothing to do with this.
If I'm understand correctly, the OEC is launched on the server, and MultiCharts runs locally and is connected to to the server ? This is not the best thing to do, all may run on the server directly.
I'll encourage you to test the system with a demo account first, if something is wrong, it's better to avoid losing real cash.

@Elite:

@sam028's answer is correct. The problem lies with your strategy, not the server. You weren't filled because other orders were placed at the same price level a long time before you did. The benefit of placing your limit order 180 ms earlier is negligible when others have had minutes, hours or days to place the order at the level before you. If your strategy's execution logic is on low frequency data, e.g. 100 tick bars, 1 minute bars, then chances are you are not gaining any advantage. The order book is very thick in the ES, so those fills look realistic to me even if you had full firepower, e.g. 15 microsecond flash to bang. You should be taking liquidity rather than posting it.

Another thing to note is that this is proximity hosting, not "true colo", even if you are located in the same data center, if you are connecting to your brokerage's data feed through WAN. Bandwidth is just as crucial. You should expect to receive your data 20~30 ms behind true colo even if you are sub-1 ms ping away from the data server via WAN. This is not a one-off situation, but something that happens consistently throughout the day. The peak 1s rates on the CME feed can exceed 20,000 messages/s, if we assume the average CME FAST message is 83 bytes, then this is 13.3 gigabits/s. A basic aggregated feed like Nanex or ZF cannot handle these rates. An aggregated feed amortizes the latency by stripping away information that you don't use (so the feed actually has a higher "useful information rate" than the exchange feed), so it can fit into a 20~50 Mbps pipe. But there is a realistic threshold how much it can compress or time it can save you.

Reply With Quote
The following 4 users say Thank You to artemiso for this post:
 
(login for full post details)
  #135 (permalink)
Elite
Rotterdam/Germany
 
 
Posts: 32 since Jan 2013
Thanks: 0 given, 0 received


artemiso View Post
@Elite:

@sam028's answer is correct. The problem lies with your strategy, not the server. You weren't filled because other orders were placed at the same price level a long time before you did. The benefit of placing your limit order 180 ms earlier is negligible when others have had minutes, hours or days to place the order at the level before you. If your strategy's execution logic is on low frequency data, e.g. 100 tick bars, 1 minute bars, then chances are you are not gaining any advantage. The order book is very thick in the ES, so those fills look realistic to me even if you had full firepower, e.g. 15 microsecond flash to bang. You should be taking liquidity rather than posting it.

Another thing to note is that this is proximity hosting, not "true colo", even if you are located in the same data center, if you are connecting to your brokerage's data feed through WAN. Bandwidth is just as crucial. You should expect to receive your data 20~30 ms behind true colo even if you are sub-1 ms ping away from the data server via WAN. This is not a one-off situation, but something that happens consistently throughout the day. The peak 1s rates on the CME feed can exceed 20,000 messages/s, if we assume the average CME FAST message is 83 bytes, then this is 13.3 gigabits/s. A basic aggregated feed like Nanex or ZF cannot handle these rates. An aggregated feed amortizes the latency by stripping away information that you don't use (so the feed actually has a higher "useful information rate" than the exchange feed), so it can fit into a 20~50 Mbps pipe. But there is a realistic threshold how much it can compress or time it can save you.

Thank you for the explanation. Yes it is based on 144 tick. I understand. So would it be wise to keep a dedicated server for $170 p/m? since based on the low frequency data i can't get really advantage and i use limit orders, i will trade automation also on the 3 minutes charts so dont know if it still worth having the server.

Reply With Quote
 
(login for full post details)
  #136 (permalink)
 Jura 
The Netherlands
 
Experience: None
Platform: MultiCharts, TradingView
Trading: ...
 
Jura's Avatar
 
Posts: 774 since Apr 2010
Thanks: 2,347 given, 688 received


artemiso View Post
Another thing to note is that this is proximity hosting, not "true colo", even if you are located in the same data center, if you are connecting to your brokerage's data feed through WAN. Bandwidth is just as crucial. You should expect to receive your data 20~30 ms behind true colo even if you are sub-1 ms ping away from the data server via WAN.

This is not a one-off situation, but something that happens consistently throughout the day. The peak 1s rates on the CME feed can exceed 20,000 messages/s, if we assume the average CME FAST message is 83 bytes, then this is 13.3 gigabits/s. A basic aggregated feed like Nanex or ZF cannot handle these rates. An aggregated feed amortizes the latency by stripping away information that you don't use (so the feed actually has a higher "useful information rate" than the exchange feed), so it can fit into a 20~50 Mbps pipe. But there is a realistic threshold how much it can compress or time it can save you.

I'm not sure if I follow the bold part.

Do you mean that 20-30ms lag is caused by the data feed, regardless of the type of retail data feed?
Or is this 20-30ms lag caused by the broker's risk management processes etc. (which "true colo" will have turned off)?

Reply With Quote
The following user says Thank You to Jura for this post:
 
(login for full post details)
  #137 (permalink)
 artemiso 
New York, NY
 
Experience: Beginner
Platform: Vanguard 401k
Broker: Yahoo Finance
Trading: Mutual funds
 
Posts: 1,129 since Jul 2012
Thanks: 765 given, 2,541 received


Elite View Post
Thank you for the explanation. Yes it is based on 144 tick. I understand. So would it be wise to keep a dedicated server for $170 p/m? since based on the low frequency data i can't get really advantage and i use limit orders, i will trade automation also on the 3 minutes charts so dont know if it still worth having the server.

I must warn that I'm making a very general statement here, but from the sounds of it, your limit orders won't get an advantage but market orders will.

Let's assume the server saves you 200 ms... ah well, I'll try to help you out. Hold on one second, let me turn on the cluster and model this for you, hopefully.


Jura View Post
I'm not sure if I follow the bold part.

Do you mean that 20-30ms lag is caused by the data feed, regardless of the type of retail data feed?
Or is this 20-30ms lag caused by the broker's risk management processes etc. (which "true colo" will have turned off)?

It is caused by the data feed alone. The risk management part that you're talking about is called no-touch, not necessary since there are brokers that will guarantee low-latency risk management.

Reply With Quote
The following user says Thank You to artemiso for this post:
 
(login for full post details)
  #138 (permalink)
 artemiso 
New York, NY
 
Experience: Beginner
Platform: Vanguard 401k
Broker: Yahoo Finance
Trading: Mutual funds
 
Posts: 1,129 since Jul 2012
Thanks: 765 given, 2,541 received

@Elite:

See your inbox. Long explanation.

Reply With Quote
 
(login for full post details)
  #139 (permalink)
 Big Mike 
Site Administrator
Swing Trader
Data Scientist & DevOps
Manta, Ecuador
 
Experience: Advanced
Platform: Custom solution
Trading: Futures & Crypto
 
Big Mike's Avatar
 
Posts: 50,002 since Jun 2009
Thanks: 32,468 given, 98,268 received


artemiso View Post
Let's assume the server saves you 200 ms... ah well, I'll try to help you out. Hold on one second, let me turn on the cluster and model this for you, hopefully.

I'd like to see as well, why not post it?

Mike

We're here to help -- just ask

For the best trading education, watch our webinars
Searching for trading reviews? Review this list

Follow us on Twitter, YouTube, and Facebook

Support our community as an Elite Member:
https://futures.io/elite/

Visit other sites? Please spread the word about your experience with our community!
Follow me on Twitter Visit my futures io Trade Journal Reply With Quote
The following user says Thank You to Big Mike for this post:
 
(login for full post details)
  #140 (permalink)
 Bogan 
Australia
 
 
Posts: 48 since Feb 2011


artemiso View Post
You should expect to receive your data 20~30 ms behind true colo even if you are sub-1 ms ping away from the data server via WAN.

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

Reply With Quote
 
(login for full post details)
  #141 (permalink)
 Jigsaw Trading  Jigsaw Trading is an official Site Sponsor
Site Sponsor

Web: Jigsaw Trading
AMA: Ask Me Anything
Webinars: Jigsaw Trading Webinars
Elite offer: Click here
 
 
Jigsaw Trading's Avatar
 
Posts: 2,982 since Nov 2010
Thanks: 825 given, 10,323 received


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 futures io Trade Journal Reply With Quote
 
(login for full post details)
  #142 (permalink)
 Big Mike 
Site Administrator
Swing Trader
Data Scientist & DevOps
Manta, Ecuador
 
Experience: Advanced
Platform: Custom solution
Trading: Futures & Crypto
 
Big Mike's Avatar
 
Posts: 50,002 since Jun 2009
Thanks: 32,468 given, 98,268 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

We're here to help -- just ask

For the best trading education, watch our webinars
Searching for trading reviews? Review this list

Follow us on Twitter, YouTube, and Facebook

Support our community as an Elite Member:
https://futures.io/elite/

Visit other sites? Please spread the word about your experience with our community!
Follow me on Twitter Visit my futures io Trade Journal Reply With Quote
The following 2 users say Thank You to Big Mike for this post:
 
(login for full post details)
  #143 (permalink)
 Daytrader999 
Legendary Market Wizard
Ilsede, Germany
 
Experience: Advanced
Platform: NinjaTrader 8
Broker: Rithmic / CQG / Ninja Trader Brokerage
Trading: NQ
 
Daytrader999's Avatar
 
Posts: 1,375 since Sep 2011
Thanks: 1,534 given, 2,017 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
 
(login for full post details)
  #144 (permalink)
 artemiso 
New York, NY
 
Experience: Beginner
Platform: Vanguard 401k
Broker: Yahoo Finance
Trading: Mutual funds
 
Posts: 1,129 since Jul 2012
Thanks: 765 given, 2,541 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.

Reply With Quote
The following 5 users say Thank You to artemiso for this post:
 
(login for full post details)
  #145 (permalink)
 Koepisch 
@ Germany
 
Experience: Beginner
Platform: NinjaTrader
Broker: Mirus Futures/Zen-Fire
Trading: FDAX
 
Posts: 522 since Nov 2011
Thanks: 381 given, 453 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:
 
(login for full post details)
  #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
 
(login for full post details)
  #147 (permalink)
 artemiso 
New York, NY
 
Experience: Beginner
Platform: Vanguard 401k
Broker: Yahoo Finance
Trading: Mutual funds
 
Posts: 1,129 since Jul 2012
Thanks: 765 given, 2,541 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.


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
The following 4 users say Thank You to artemiso for this post:
 
(login for full post details)
  #148 (permalink)
Frank R
Wash DC
 
 
Posts: 66 since Sep 2011
Thanks: 8 given, 25 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?

Reply With Quote
The following user says Thank You to Frank R for this post:
 
(login for full post details)
  #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
 
(login for full post details)
  #150 (permalink)
 artemiso 
New York, NY
 
Experience: Beginner
Platform: Vanguard 401k
Broker: Yahoo Finance
Trading: Mutual funds
 
Posts: 1,129 since Jul 2012
Thanks: 765 given, 2,541 received

Replied you guys.

Reply With Quote


futures io Trading Community Trading Reviews and Vendors Brokers > Setup Dedicated Machine Chicago - My experience


Last Updated on February 7, 2013


Upcoming Webinars and Events
 

NinjaTrader Indicator Challenge!

Ongoing
 

Journal Challenge w/$1,800 in prizes!

April
     



Copyright © 2021 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