Support Board
Date/Time: Wed, 27 Nov 2024 19:44:36 +0000
Teton Routing service and appropriate VPS wit lowest Ping!
View Count: 2826
| [2022-03-10 19:10:33] |
| Mr.DaxF - Posts: 44 |
|
Hello dear support Staff, i look for an appropriate VPS and have found some one who have this as result: We tried to ping but only New York location is getting 17ms. C:\Users\Administrator>ping ds1.sierracharts.com Pinging ds1.sierracharts.com [8.18.161.135] with 32 bytes of data: Reply from 8.18.161.135: bytes=32 time=17ms TTL=120 Reply from 8.18.161.135: bytes=32 time=17ms TTL=120 Reply from 8.18.161.135: bytes=32 time=17ms TTL=120 Reply from 8.18.161.135: bytes=32 time=17ms TTL=120 Ping statistics for 8.18.161.135: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 17ms, Maximum = 17ms, Average = 17ms For some unknown reason we are getting 88ms from our Chicago CME. my qouestions are: 1. there are any knowing appropriate VPS!? within fulfills the system requirements!? 2. my goal are to get finally 3-10MS ping! Possible? thank you verry much! Also i find it absolutely usefull and great that SC implement the new feature Teton that will make all greater aswell bether! :) Date Time Of Last Edit: 2022-03-10 19:39:06
|
| [2022-03-10 22:09:48] |
| 1+1=10 - Posts: 270 |
|
There's a lot that goes into round trip order latency. Below I've provided the entire list of factors including two VPS / Dedicated server options that are in the same building as Teton & the CME's servers. By the way, I wouldn't recommend worrying about latency if you're doing manual trading -- even if you reduce the internet latency from 100 ms to 5 ms, it is fairly irrelevant if you have to add 2000ms to the 5ms because it takes you 2 seconds to react to market information and place an order. The exception to this rule would be if you use any orders that are not sent to the exchange such as trailing stops. Because those client-side orders get automatically turned into real orders that are sent to the exchange by SC when the relevant condition is triggered, then internet latency is indeed part of determining how quickly a client-side order will execute. If on the other hand, you are doing automated trading, through any of SC's 4 methods, then yes, reducing latency can be very useful. Anyway, here are the factors involved in receiving market data and then sending an new order based on that data: Receive Market Data From Exhange: 1. +0 millis -- Trade / limit order update takes place at exchange 2. +1 millis -- Exchange actually sends aforementioned update to your market data provider's servers. (NOTE: while typically this happens in < 1 millisecond Rithmic support staff said this delay can be as much as 15 milliseconds during very high volume news events.) 3. +0.250 millis - ~10 millis -- Data provider receives market data update. The duration here is simply related to where the data provider's servers are. If they're in the same building as the exchange, like SC's Teton or Rithmic then it is near the low end. If the data provider's servers are outside the building, like CQG's retail web api that SC uses, then you can get near the higher end. 4. +??? millis -- Time to send data from provider to your algo? NOTE: SC has two aspects which contribute to this duration. First, is the "SC Remote Buffer Delay". In short, SC's own data feed, Denali, only sends updates every 10 millis -- link below. Secondly, the global/chart "update interval" dictates how frequently your ACSIL algo runs (provided you have sc.AlwaysUpdate = true) -- the minimum setting is 10 millis. Thus, the combination of these two factors delays data getting to your algo by 20 millis in the worst-case and 10 millis in the average-case. 4's Standard-case :: +30.0 millis - 270.0 millis -- ACSIL trading algo on home computer. Factoring in SC's aforementioned delays, and assuming your home computer is outside of the exchange's metro area between 10 - 250 millis away gives you this range for step 5. 4's Improved-case :: +20.0 millis - 25.0 millis -- your ACSIL trading algo is on a server in the same metro as the exchange. For instance, if trading on the CME search "Chicago trading/vps/dedicated server". -- one caveat to this is that it will be hard to know such a server's latency to TETEN for sure unless you submit an order from the server through TETON and check the round-trip time. (Internet routing is based on carrier [Version, AT&T, etc.] and every carrier will send the internet packets for market data/orders on different routes back and forth from your server to TETON. If you had 2 servers in a random Chicago building using 2 different carriers, then Verizon's route could take 2 millis and AT&Ts could take 13 millis. 4's 2nd Best-case :: +1 millis - 5 millis -- here we switch to only using SC for research/idea generation. For our algo we switch to Rithmic's API ($100 month) with the trading server as close as possible to the exchange. For the 1 millisecond case we'd need to be in the same building. For CME see https://www.theomne.net/ OR https://www.beeksfinancialcloud.com/catalogue/DS-EMERALD_5/. 4's Best-case :: +0.250 millis -- Here our algo is actually on the data provider's servers; typically $400 - $1000. I can provide links if you'd like.------------------------ Send Order to Exchange 5. ACSIL Algo Processing Time -- this is likely under 100 microseconds. 6. Algo's computer/server -> Data Provider/Order Routing's Computer -- 0.250 - 250 millis: NOTE: this is the same as step 4 above although you have to add 1 milli for the risk check unless on 4's best-case. See Rithmic link below for explanation of risk checks. 7. Data Provider/Order Routing -> Exchange -- 0.250 - 10 millis: NOTE: same as step 3 above. 8. Exchange Matching Time -> 0.5 - 5 millis --------------------------------- To conclude, if you use SC and you get a server in Chicago you can get your worst-case round trip (new data to order) time down to ~30 millis. If you get to some of the more esoteric choices I've mentioned you can get down to ~1-5 millis. |
| [2022-03-11 06:14:50] |
| Tonkadad - Posts: 235 |
|
1+1=10, Would like your opinion regarding latency: the quest for low latency assumes that once a setup is recognized either by human or computer and an order is initiated that it goes in your direction, would you basically agree? If not, please expound upon that. I get the point about stops being triggered and possible que position. Have you ever done any testing from your entry data to see if entering 100 or 200 millis, etc... later gave any appreciable price improvement? Always appreciate your thoughts and insights. Date Time Of Last Edit: 2022-03-11 06:16:21
|
| [2022-03-11 15:23:41] |
| 1+1=10 - Posts: 270 |
|
Hi Tonkadad, I'm going to answer the questions in reverse order: --------------------------------------- Have you ever done any testing from your entry data to see if entering 100 or 200 millis, etc... later gave any appreciable price improvement?
First, let me give the general rule and then give the evidence to support the rule. The rule is that the impact of latency is directly related to how far your take profit is from your entry price. If your take profit is 1 tick, then latency is the #1 factor. At 10 ticks latency might be the difference between profitability and loss. At >= 20 ticks, it is unlikely to make much of a difference. Now as to the evidence to support this rule: 1. According to the CFTC in 2019 fully 50%-90% of trades were automated — the number is likely even slightly higher now. Source: See page 7’s “Exhibit 2: Share Of Automated Futures & Options Transactions”: https://www.cftc.gov/sites/default/files/2019-03/automatedordersreport032719.pdf It is because the majority of trades are automated that latency matters for short-term strategies. 2. The effect of latency on profitability has been the subject of many academic papers. (One of the things I enjoy doing to increase my trading knowledge is reading papers written by Masters/PhD authors, some of whom go on to work as professional traders.) For example, there's a 2014 version of an paper entitled "Risk and Return in High-Frequency Trading": https://www.cftc.gov/sites/default/files/idc/groups/public/@economicanalysis/documents/file/oce_riskandreturn0414.pdf The abstract says: "This paper studies high frequency trading (HFT) in the E-mini S&P 500 futures contract over a two-year period and finds that revenue is concentrated among a small number of HFT firms who achieve greater investment performance through liquidity-taking activity and higher speed. While the median HFT firm realizes an annualized Sharpe ratio of 4.3 and a four-factor annualized alpha of 22.02%, revenues persistently and disproportionally accumulate to top performing HFTs, consistent with winner-takes-all industry structure. New entrants are less profitable and more likely to exit. Our results imply that HFT firms have strong incentives to take liquidity and compete over small increases in speed." In 2018, the same authors submitted a new version of the same paper: https://www.cb.cityu.edu.hk/ef/doc/GRU/WPS/GRU%232017-018%20Baron%20et%20al.pdf The abstract says: "We study performance and competition among firms engaging in high-frequency trading (HFT). We construct measures of latency and find that differences in relative latency account for large differences in HFT firms’ trading performance. HFT firms that improve their latency rank due to colocation upgrades see improved trading performance. The stronger performance associated with speed comes through both the short-lived information channel and the risk management channel, and speed is useful for various strategies, including market making and cross-market arbitrage. We find empirical support for many predictions regarding relative latency competition." ---------------------------- The quest for low latency assumes that once a setup is recognized either by human or computer and an order is initiated that it goes in your direction, would you basically agree? If not, please expound upon that.
A good way to explain when latency matters is by describing a short-term strategy. This is probably not a profitable strategy, to be clear. I should also add this type of strategy is typically done via an automated fashion -- although some claim to do similar things manually: https://www.nobsdaytrading.com/videos/ I will describe the logic of the strategy when making a decision to enter long (but all of this could be reversed in a decision to enter short). Let's say one of my decision making filters is the ratio of buy to sell limit orders and the limit order book looks like this: 990 -- L2 ask size 550 -- L1 ask size ------- 690 -- L1 bid size 1200 -- L2 bid size Let's say more trades are made and the offers are being depleted faster than the bids so now our book looks like this: 860 -- L2 Ask size; this number became smaller due to cancellations 50 -- L1 Ask size ------ 500 -- L1 Bid size 1300 -- L2 Bid size And let's say the strategy thinks this is an advantageous time to place a buy limit order at the L1 Ask price because: 1. 50:500 = 1:10 -- L1 Ask is more likely to be depleted than L1 Bid meaning price is more likely to tick up. 2. (860+50) : (500+1300) = 910:1800 ~= 1:2 -- There's 2x as many immediate buyers as sellers so perhaps there will be follow-through at least for a few ticks. So here is an example where the round trip time between getting new market data and submitting an order is crucial for 2 reasons: 1. Latency answers the question of how delayed is my algorithm's view of the limit order book from the actual state of the limit order book at the exchange. The shorter the latency, the less likely a change has occurred which could result in the invalidation of our reason for sending the order. 2. Latency is what determines our ability to recognize that situation and get our order in at L1 Ask before the other buyers can either move their orders up or enter new orders at L1 Ask. If we're right and price ticks up, but we're too late, then we won't get to trade. Unfortunately, if price ticks down after we get an order in, no matter how late we were, we will get to trade, but it is in a situation where our prediction was wrong! Thus, low latency is what allows a short-term trader to take advantage of their short-term price predictions. Now continuing with the trade let's say we got in long at L1 Ask and we're going to exit the trade for loss at L2 Bid. 860 -- L2 Ask size 50 -- L1 Ask size -- our ENTRY ------ 500 -- L1 Bid size 1300 -- L2 Bid size -- our SL There's 3 situations: 1. We have a stop loss which is simulated by your trading platform and not actually at the exchange or order routing servers. An example of this situation is when on SC you submit a bracket order using some order routers like CQG, or as I mentioned before when you have a trailing stop in SC. If you're a short-term trader in this situation then latency determines slippage. It can be the difference between getting out at your SL price OR getting out 2 ticks worse than your SL price. 2. We have a stop loss at the exchange or order routing servers. Here there's very little about latency we can control other than inquiring about the latency of our order router to the exchange (Teton, CQG, Rithmic, TT, etc.) 3. Let's consider our order book right before a normal stop loss would be triggered: 860 -- L3 Ask size 710 -- L2 Ask size -- our ENTRY 400 -- L1 Ask size ------ 1300 -- L1 Bid size -- our SL The way a stop loss works, for long trades, is when the first trade hits the L1 Bid, then a sell market order gets submitted which should also hopefully hit the L1 Bid. But let's consider the situation where the average trade is much smaller than the L1 Bid size. Let's say the average trade size (from any market participant) is 10 contracts. Then our order book would look like this: 860 -- L3 Ask size 710 -- L2 Ask size -- our ENTRY 400 -- L1 Ask size ------ 1290 -- L1 Bid size -- our SL Now according to a normal stop loss, instantly it would become a market order and get us out of the trade. But this may not be ideal because the probability of price actually going to L2 Bid is not very high as 1290 / 10 == 129 more trades would have to occur for price to go to L2 Bid. Instead, let's wait till L1 Bid size gets depleted before we actually activate our stop loss. Perhaps we wait till L1 Bid size is 300 and then we send our market order to exit the trade. In short-term trading this adjustment can turn losing trades into winners. For this type of stop loss strategy, latency is critical, especially since for a retail trader the decision-making and order sending happens on your computer. (If you pay TT, Rithmic, & CQG $500-$1000 a month you can put your algos on their order routing servers as I mentioned in the previous post.) SC actually has a version of this type of order: Order Types: Bid Ask Quantity Triggered Stop (For exiting a long trade, you'd use the Sell Bid Ask Quantity Triggered Stop.) -------------------------------------------- There's a different type of strategy that is not limit order book orientated that is affected by latency that is simpler to explain: short-term pairs trading. Let's say the front contract for Corn is March 22 and the next contract is May 22. Let's say we're convinced that for this portion of the year there's no significant seasonal differences between the value of March Corn compared to May Corn. So we think we can employ a short-term mean reversion strategy based on Bollinger Bands (Standard Deviation Bands). In short, when the price spread is >= 2 deviations above the spread's 60 minute average price, then we're going to short the spread, and vice-versa for longs. The reason why latency may matter is for two reasons: 1. If other traders are employing the same strategy, and they are faster, then they may enter orders which cause the spread to retract from the extreme before your algo can react. 2. This type of strategy will calculate the spread's price based on the difference between the March bid - May ask or the difference between the March ask - May bid. And one's latency determines how often one samples those differences. If your round trip latency is 100 millis but the spread is only above >= 2 deviations for 20 millis then you may miss a profitable trade. (And again, just like stop losses if the spread >= 2 deviations for longer periods of time, the chance of hitting your stop loss which might be at 2.5 deviations increases.) ------------------------- I know that was a lot but trading is complicated! By the way, I tried to develop a short-term strategy and I abandoned it. Instead, I've been focusing more on longer-term strategies. I actually am about to launch one where I hold trades for weeks based on spread seasonality. For instance, if your entry date is Dec 1 2022 and your exit date is Jan 10 2022, you'd expect Natural Gas Jan 2022 to go up more than Natural Gas Mar 2022, due to the extreme demand for NG in winter. I can explain more about this type of trading if you'd like. Hope this all helps! |
| [2022-03-11 15:38:01] |
| Tonkadad - Posts: 235 |
|
Wow! Sincerely thank you for NOT giving a Readers Digest answer. Appreciate it. Really interesting. Need to ponder. I am actually interested in your last paragraph but let me assimilate what you have already given, first. |
| [2022-03-11 15:43:13] |
| 1+1=10 - Posts: 270 |
|
I tried to be concise, but not sure how successful I was -- haha. As to the last paragraph, you can reply here or direct message me if/when you want me to hear more. Cheers! |
| [2022-03-11 15:48:00] |
| User900285 - Posts: 94 |
|
Thank you for providing your insights regarding round trip order latency. Regarding the second post in this thread By the way, I wouldn't recommend worrying about latency if you're doing manual trading -- even if you reduce the internet latency from 100 ms to 5 ms, it is fairly irrelevant if you have to add 2000ms to the 5ms because it takes you 2 seconds to react to market information and place an order.
I would like to stand up for my manual trader friends because this is just not true. A skilled manual scalper could achieve 250ms reaction time consistently or lower. If they know exactly what they need to see that triggers their already planned decision. |
| [2022-03-11 17:01:25] |
| 1+1=10 - Posts: 270 |
|
User900285, I would like to stand up for my manual trader friends because this is just not true. A skilled manual scalper could achieve 250ms reaction time consistently or lower. If they know exactly what they need to see that triggers their already planned decision. This is a fair critique! Assuming you're using a keyboard, your hands are on the right keys and it takes one key press/combo OR your hand is on the mouse and you're already hovered over the right button, then according to the tests done on the following website the mean reaction time is 273ms -- it has a bell curve and anything quicker than 150ms is exceedingly rare: https://humanbenchmark.com/tests/reactiontime An important note from the site: "In addition to measuring your reaction time, this test is affected by the latency of your computer and monitor. Using a fast computer and low latency / high framerate monitor will improve your score." Actually, come to think of it, if a manual trader's entry orders are done via the immediate reaction to some market change, then they can't reduce latency for entries, even by getting a VPS / dedicated server. (However, they still may be helped by any client-side resting orders such as trailing stops / brackets being sent to the market faster.) Why? It is because one has to connect to a VPS / dedicated server through a remote session from your local computer. Thus, we still have to wait for the packets from the VPS showing the VPS's changed screen to reach the local computer, incurring the same internet delay we'd have even without the VPS! (If you are auto-trading then the decision to trade is made on the VPS server so you don't have to wait for the information to get to your local computer.) By the way I hope my tone doesn't come off argumentative. None of what I wrote was intended to be a critique of manual traders. I'm just trying to reason through in which situations reduced latency can help manual/automated traders so they can decide whether it could help to take steps to address that concern. Date Time Of Last Edit: 2022-03-11 17:04:40
|
| [2022-06-07 19:35:42] |
| User887126 - Posts: 66 |
|
Hi All, What are the VPS provider that is on the same network as denali teton server? I saw 1+1=10 mentioned this in the post for best case scenario under item no.4. thank you in advance. |
| [2022-06-08 07:58:29] |
| Calculus - Posts: 97 |
|
1+1, thanks a lot buddy for taking the time to post, you're giving some great education. Can I ask a quick question re the new Teton and a broker like Edge/Stage 5? Those 2 brokers are IB's and they clear through Dorman (or similar). Does that mean there will be an extra (time) step for filling orders? What I mean is this - Say a client has an account at Dorman (not using Edge/Stage5), then if he wants to buy 1 ES at market, Dorman will first check if the client has enough money and if so, flick the order to the Exchange for filling. All very simple. BUT. If a client opens an account at Edge/Stage 5 and enters a order to market buy 1 ES, will there be an extra step? So first Edge/Stage5 checks the client has enough capital, then Dorman needs to check, and then if the client has enough capital, the order is then flicked to the Exchange to be filled. So that's my question - is there a small time delay when using an IB like Edge/Stage5 over cutting them out (they're sort of middleman) and instead just opening an account with a clearing member. I do understand though that with a small account a clearing broker might not be interested in opening an account hence the client should use an IB like Edge/stage5. Have a great day! |
| [2022-06-08 08:10:45] |
| |
|
Those 2 brokers are IB's and they clear through Dorman (or similar). No matter which clearing firm is used and whether your accountant is at a Introducing Broker or not, has no impact on the routing of orders. They are always straight through to a CME iLink session. It does not involve any clearing firm systems at all. The clearing firm sets the risk parameters ahead of time through Teton. Risk controls are managed by Teton after that. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2022-06-08 08:11:46
|
| [2023-01-11 14:12:17] |
| BillsSBC - Posts: 38 |
|
They are always straight through to a CME iLink session. It does not involve any clearing firm systems at all. The clearing firm sets the risk parameters ahead of time through Teton. Risk controls are managed by Teton after that.
I've pursued a VPS within both Aurora and Cermak and having mixed results on order speed for my algo trading MES. Is the proper way to test with live orders and comparing the DateTime and TransDateTime while allowing SC to modify/update the computer's system time? Cermak gives a difference of 18-24ms consistently but have occasionally seen 7-9ms. Aurora is mixed between 16-24ms or 4-7ms for market orders. Times are always faster for stops. These numbers line up reasonably with 1+1's analysis for Teton/Denali. And clearly the Aurora VPS gives better results but is there any reason for the major difference is speed other than when, say, where in the Denali data buffer process an order is placed? That said, can SC Engineering comment on suggested buffer/compression/update settings to use for a VPS that is colocated with their servers? |
| [2023-01-11 16:04:24] |
| Sierra_Chart Engineering - Posts: 17198 |
|
Provide us all of the lines for a particular order from the Trade Activity Log so we can check the timing and we will also compare it to the server. Instructions: Trade Activity Log: Providing Trade Activity Log Data Lines to Support This is not going to be relevant, for order routing: That said, can SC Engineering comment on suggested buffer/compression/update settings to use for a VPS that is colocated with their servers? Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, use the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2023-01-11 16:04:51
|
| [2023-01-11 16:21:23] |
| BillsSBC - Posts: 38 |
|
This is not going to be relevant, for order routing:
Yes, I agree, but the algo needs to receive and analyze market data from Denali before placing the order; I'd like to decrease lag wherever possible. Attached are several manual trades from the Aurora server today. |
Private File Attachment Deleted. |
| [2023-01-11 16:27:14] |
| Calculus - Posts: 97 |
|
Hey 1+1, thanks a lot man. You always give such good information here and it's really appreciated that you take the time to help. You helped me with a tricky SC problem (for me, not you!) about a year ago and I always look out for your excellent posts. Have a great 2023 buddy! |
| [2023-01-11 20:22:49] |
| User887126 - Posts: 66 |
|
I am currently researching to get my own VPS also in Aurora. Is this supposed to be faster than Cemark? I agree with User488431's comment above regarding reducing the denali market data lag to VPS location. It can give us significant advantage and can become part of your overall strategies. What is the best way to test the lag from Denali to VPS and from VPS back again to Denali? I have been researching it, there does not seem to be clear definitive answer. We would need timestamp info in the order of micro sec to make meaningful comparison. Otherwise, you might as well get cheap VPS within a few miles of CME. |
| [2023-01-11 21:29:24] |
| BillsSBC - Posts: 38 |
|
I am currently researching to get my own VPS also in Aurora. Is this supposed to be faster than Cemark? I agree with User488431's comment above regarding reducing the denali market data lag to VPS location. It can give us significant advantage and can become part of your overall strategies.
Generally speaking, Aurora should be faster but depending on where you're located in both locations, differences could be negligable. Also depends on where you're receiving data, my understanding is SC serves data from both locations...it would be nice to have the option to select which server again like we had previously had the ability. I want to be able to properly test and get the best out of what SC has to offer at a reasonable cost, not get sub-ms data/routing, but doing so and finding documentation for best practices is difficult to figure out. |
| [2023-01-16 18:05:44] |
| BillsSBC - Posts: 38 |
|
Provide us all of the lines for a particular order from the Trade Activity Log so we can check the timing and we will also compare it to the server.
I wanted to follow up and ask if you had a chance to look into this? Post #14 Teton Routing service and appropriate VPS wit lowest Ping! | Post: 333920 |
| [2023-01-17 21:17:49] |
| Sierra_Chart Engineering - Posts: 17198 |
|
Sorry for the delay. We will go over this.
Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, use the Teton service: Sierra Chart Teton Futures Order Routing |
| [2023-01-18 16:12:04] |
| Sierra_Chart Engineering - Posts: 17198 |
|
We did look at that log, and it is too much data. We just need the information for one order only. And that also needs to include the fill as well.
Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, use the Teton service: Sierra Chart Teton Futures Order Routing |
| [2023-01-18 16:52:01] |
| BillsSBC - Posts: 38 |
|
We did look at that log, and it is too much data. We just need the information for one order only. And that also needs to include the fill as well.
Attached is a single market order trade from today. |
Private File |
To post a message in this thread, you need to log in with your Sierra Chart account: