Support Board
Support Board
Search Board
Control Panel
View My Posts / Threads
Direct MessagesDate/Time: Tue, 07 May 2024 08:08:30 +0000
CQG Data Incorrect
View Count: 1722
| [2018-05-02 22:56:55] |
| User75002 - Posts: 117 |
|
Hello, I know this is not your favorite topic lately, but I have an issue with the close price of a 5 min candle on the GC this morning. I also had the issue yesterday, but do not recall the symbol or timestamp, but it was with the close price as well. I trade with some friends that use different platforms and brokers and when we discuss the close of the 5 min candles, our charts didn't agree. I didn't think much of it yesterday, but when it happened again today, I figured there is something wrong. The close price of the 10:30am ET candle on GC is 1306.0 on my chart, but everywhere else, it is 1306.1. See screenshot. If I look at the 10:34am 1 min candle, it also shows the 1306.0 close. I didn't think it would be a platform issue, but when I used the CQG web trader, they have the correct price, so I'm wondering where the issue is. I have tried reloading the data, disconnecting the data feed, even shutting down and deleting the .scid data file (I know not recommended). Every time, it shows up with the close of 1306.0. http://www.sierrachart.com/image.php?Image=152530006962.png On a slightly related topic, depending on the outcome of this problem and if the random CQG disconnects continue, I may start using the SC real-time data feed. Am I correct in understanding the price would be $35.00/month for 100 symbols and then $3.25/month for the CME group data? And if this setup is configured, my data would be from the SC server, and my orders would be sent directly to the CQG servers when placed without going through your servers? I appreciate any information you may have regarding this problem. Thank you Date Time Of Last Edit: 2018-05-03 12:29:18
|
| [2018-05-03 18:41:25] |
| |
|
Yes, we do see 1360.0 for that time for that GC symbol from CQG data. We have now corrected the data by loading the data from our own historical data service. You can re-download the data for the correct prices. We are aware that CQG is either not sending data or perhaps there is something unusual going on with the protocol buffer decoding and the data is just not getting decoded or processed an unknown reason. This last case though would seem to be extremely unlikely but we have to consider all possibilities. We intend at some point to go over this with CQG. We also wish CQG would support the current protocol definition file for Google protocol buffers version 3 which they do not. This is really quite disappointing they do not do this. Am I correct in understanding the price would be $35.00/month for 100 symbols and then $3.25/month for the CME group data? And if this setup is configured, my data would be from the SC server, and my orders would be sent directly to the CQG servers when placed without going through your servers? Yes. Yes. Make sure in this case, you use the CQG FIX connection for trading. More details are explained here:CQG Trading Platform Service: Frequent Server Disconnections when Using CQG 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: 2018-05-03 18:41:33
|
| [2018-05-09 13:29:18] |
| User75002 - Posts: 117 |
|
Hello again, I had another instance of a candle not showing accurate close information. This time on the EC/6E. When the candle initially closed, it closed with a price of 1.19135, equal to the previous open. I then performed a "delete and download data" and it changed the candle close to 1.19140. Both are wrong. CQG web shows the close should be 1.19125. This candle is the 9:10am ET 5 min candle. See screenshot. If the issue is with CQG not supporting the latest protocol standard, is there anything else that can be done? I asked my broker to talk to CQG on their side about supporting it, but haven't heard anything back yet. It is likely this is probably happening more than I notice. Do you have an idea of when you will be able to work with CQG on this? If it will be awhile, which I understand, I will have to switch to the SC data feed until things get worked out. I just need the best, most accurate data feed, but need to keep CQG for the server-side bracket OCO support. http://www.sierrachart.com/image.php?Image=1525872059693.png Thanks for your help! Date Time Of Last Edit: 2018-05-09 13:53:20
|
| [2018-05-09 18:21:08] |
| |
|
We do not have hope that talking to CQG is going to make any difference and that is why we do not do it because generally it is going to be unproductive. We have much higher priorities.
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: 2018-05-09 18:27:03
|
| [2018-05-09 18:26:25] |
| |
|
. I then performed a "delete and download data" and it changed the candle close to 1.19140. Both are wrong. This is actually an indication that the issue is on the CQG side and the server is delivering inconsistent data per connection. So this is indeed helpful information to us. It confirms what we have suspected. When did you notice this, was it today (2018 05-09)?Make sure this option is disabled: Global Settings >> Data/Trade Service Settings >> Allow Server to Drop Data. Reconnect to the data feed if you change that setting: File Menu: Procedure to Reconnect to the Data and Trade 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, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2018-05-09 18:45:51
|
| [2018-05-09 18:45:09] |
| |
|
But we will put some pressure on CQG to provide us the latest protocol buffer definition file for version 3 of Google protocol buffers. We will do this now. Whether it works or not, we do not know and whether this is the problem or not, we do not know. We are not really hopeful. 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 |
| [2018-05-09 18:58:25] |
| |
|
Message sent to CQG: We require that your protocol definition file compiles under Google protocol buffer version 3.
We have to use Google protocol buffer version 3 compiler and library because we use other Google protocol buffer implementations which require that. The protocol definition file you linked to here does not compile under Google protocol buffer version 3 compiler. You do not have to on your server itself support Google protocol buffer version 3. You just need to have another version of your protocol definition file which will compile under version 3. It still will be the same but just some minor changes are needed. As long as the overall structure of the messages is the same, the underlying encoding will remain the same. We know that from experience and that is what is documented in the Google protocol buffer documentation. So it is not a problem to provide support for version 3. The underlying encoding will be the same. This is important for us because we are using an older CQG Web API definition file and we are wondering if this is what is leading to missing data for our users with the real-time market data. We have many reports of that. Now is this really going to get what we want, we doubt it very much. This is why we just simply are helpless, in this regard and this is why we have to focus on things that are productive. And eventually get to a point where CQG can be completely eliminated. 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 |
| [2018-05-09 22:19:08] |
| User75002 - Posts: 117 |
|
Hello, Thank you for the update. In response to post #5, the delete and download was performed today 5/9/2018 during the next 5 min candle at 9:15am ET immediately after noticing the problem. The Allow Server to Drop Data setting is set to False for the Web and FIX connections. In response to post #7, hopefully CQG helps you out. The response my broker received was basically "we didn't change anything, talk to Sierra..", which doesn't surprise me. With your email to them, it explains what is needed so I hope they can implement the support for version 3. If you do not receive any helpful response back from CQG by the weekend, I will proceed with the 2 week trial of the Sierra feed. If CQG is eliminated, would the replacement you are considering support full server-side bracket OCO orders? Thanks again. |
| [2018-05-10 03:06:33] |
| |
|
We think we might possibly have discovered the problem. We are going to run a test tomorrow. What could be happening is that when CQG reports a market data message is a snapshot, we would not count any trades within it as actual trades. But this should only happen once at the beginning of the connection after subscribing to the symbol. So if this is really the problem, we still would say this is a CQG issue to begin with. To see if this problem has been solved, when you notice the inaccuracy, re-download the data for that bar and see if it becomes correct. If CQG is eliminated, would the replacement you are considering support full server-side bracket OCO orders? https://www.sierrachart.com/index.php?page=doc/CTS_T4.php#SetupInstructionsForAdvancedLowCostConnectionModel 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: 2018-05-10 03:07:47
|
| [2018-05-10 15:47:41] |
| User75002 - Posts: 117 |
|
Hello, Last night I got impatient and decided to set up the SC data feed trial. I figured I would try it out while a fix was being worked on. As soon as you have the fix implemented to the current branch of code, I will be happy to test it out. Even after switching to the SC feed last night, I had to delete the .scid file for the 6E in order to have it download the correct candle data. Simply performing a delete and download was not correcting the candle close price. Regarding CTS, I was considering that option when evaluating CQG, but wanted a mobile/web app to manage trades from when away from computer or experiencing an internet/power outage. If memory serves me right, Using CTS, I would have to still pay their core pricing fee to have access to the mobile/web and then the higher commissions when using it. I may have to look at the overall costs again when accounting for the SC feed on top of the CQG fees. It may now be cheaper to use CTS. |
| [2018-05-10 18:52:35] |
| |
|
Using CTS, I would have to still pay their core pricing fee to have access to the mobile/web and then the higher commissions when using it. You would have to pay the higher commissions, but not certain about the core pricing.
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 |
| [2018-05-10 19:25:36] |
| |
|
At this point it appears that the difference you sometimes see with the close value of a chart bar when using CQG data, would not be solvable because it has to do with CQG timestamps.
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 |
| [2018-05-10 20:27:00] |
| User75002 - Posts: 117 |
|
Thanks for the update. Maybe a statement like this would be helpful on the CQG Services page so people understand that this can happen when using the CQG data feed.
|
To post a message in this thread, you need to log in with your Sierra Chart account: