Support Board
Date/Time: Fri, 29 Nov 2024 04:30:12 +0000
Post From: Sierra Chart Does Not Recommend CQG (Various Reasons)
[2020-06-12 21:19:17] |
Sierra Chart Engineering - Posts: 104368 |
We are bringing this back up to the top of the board because we have another reported issue with CQG from a user that came through a ticket, where CQG provided an incorrect fill price for a treasury futures contract, and there was also a position reporting issue. These are not Sierra Chart problems but these problems relate to the CQG service itself. We just want to go into a brief technical discussion about the "incorrect fill price": More specifically what likely happened is that the "raw integer" price failed to get adjusted to the true price due to an issue with the security definition data from CQG. This is something we have discussed with CQG. We think it relates to a problem in one of the protocol buffer messages And we did do a small code change to work around it and we also want to update to the latest protocol buffer Definition files from CQG but we have difficulty with those.
Update: We had a further look into this, and there is a field called correct_price_scale in the contract metadata from CQG. The pricing problem relates to this. When users were getting incorrect market data that was not adjusted using this price scale variable, it was because we were checking to see if that variable was set using a Google protocol buffer library function. CQG says that this variable is always set and there is no need to check if it is set. So we took that check out which should not have failed anyway but apparently was. And we also see that check exists for order prices as well so we are taking that out for order/trading prices and that will be out in version 2122. We do hear about CQG Trade Position Quantity reporting problems from time to time, they are rare but they do happen. You should then see the correct position usually by reconnecting to the data feed. The positions might also be corrected by selecting Trade >> Refresh Trade Data from Service but we would have to see if that would have an effect in the case of CQG. We recommend that users use the Sierra Chart order routing service if they are trading the CME group of exchanges: Sierra Chart / Trading Technologies Futures Order Routing Service Another problem we have with CQG is the latest protocol buffer definition files do not even compile properly in our Visual C++ project without generating errors that we have never seen before. And we know this is not very descriptive because we do not want to go into technical details but the ultimate point we are trying to make is the CQG Web API protocol definition files have become far too large and complex. If you are trading the CME group of markets we simply do not recommend using CQG and we recommend the Sierra Chart order routing service instead: Sierra Chart / Trading Technologies Futures Order Routing Service We have invested a lot in the service, and we have multiple servers for redundancy, and also use a direct Cross Connect to TT: Sierra Chart Order Routing Service to Trading Technologies(TT) Cross Connect The Sierra Chart order routing service would not be affected by incorrect fill prices because there is no price translation required. In many cases, but not in the case of treasury futures there is a price multiplier used but this is not something which leads to any type of problem. If the price multiplier is not set correctly on the Sierra Chart side, then you just simply correct it. There would not be incorrectly logged fill price because there is never any translation of the prices. And finally, the reason why it is we are working towards a unified model of order routing is in order to provide a high-quality level of service and reliability for our user base. It makes completely no sense for us to be supporting so many different services. This is just simply downright inefficient and illogical. And it is also so inefficient and illogical that all of our competitors are doing the same dumb thing. Does it make sense that bookmap and Jigsaw, and others are integrating to all these different services with all these different problems and all these different APIs. No, it is extremely inefficient and illogical. This is why we established the DTC Protocol: https://www.dtcprotocol.org/ Also, we did discuss with jigsaw about interfacing to the DTC protocol server. 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: 2020-06-14 23:48:45
|