Support Board
Support Board
Search Board
Control Panel
View My Posts / Threads
Direct MessagesDate/Time: Tue, 16 Apr 2024 05:15:23 +0000
[Locked] - Technical Help for Rithmic is Now Discontinued as of December 1, 2019.
View Count: 8409
| [2019-10-14 20:24:09] |
| |
|
Sierra Chart will formally be discontinuing technical support for Rithmic effective January 2020. Rithmic will still work with Sierra Chart indefinitely but we will be providing no longer any technical help related to Rithmic. If you are using Rithmic, there is no impact to you. But just be aware that we will not be providing any technical help related to using it. This decision is not meant to speak poorly of Rithmic in any way. Sierra Chart has substandard integration to Rithmic which is very time-consuming and involved to resolve, and is going to create a huge support burden upon us and frustrations for you. We do not want this! We are finished with this. We are sick and tired of dealing with external service issues. And we are sick and tired of dealing with God damn damn damn damn CME market data policies. Did we say damn enough here? No we did not. We should say it a million more times. A billion more times. A trillion more times! Dropping support for Rithmic and other services is part of our plan to create a unified method of order routing and use our own trade simulation services. More information can be found here: Year 2019 for Sierra Chart More information on the simulated futures trading service: Simulated Futures Trading Service We are also going to come out with a delayed version of the Simulator Futures Trading service which will have no additional cost and will be included with the Advanced Sierra Chart service package in November 2019. We just do not have the time to be developing to and supporting so many different external services. This is nothing more than crazy and disorderly to say the least. We do know that many trading evaluators use Rithmic, and they can still use Rithmic with Sierra Chart, but it is just that they are responsible for the technical support. We just will no longer be involved with it ourselves. 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: 2019-10-15 16:08:08
|
| [2019-10-18 21:24:57] |
| User760165 - Posts: 4 |
|
I find it amazing that as Sierra is launching Denali the other data providers have become so unreliable and you guys are screaming this from the roof tops. Thanks god you guys dont have a vested interest in Denali. Seems very convenient
|
| [2019-10-18 21:29:59] |
| |
|
They have been unreliable for a long time now. This is the basic fact. You are drawing false conclusions here. Completely false conclusions. We don't even have to even prove this. It is overwhelmingly overwhelmingly clear. And look you don't have to believe us. But we know the facts. And yes we are going to complain massively about CME market data policies and we are just being overwhelmingly overwhelmingly too kind in the way that we speak. Just too kind. Overwhelmingly kind. In regards to CQG, the simple fact is the CQG data feed has always been problematic since we supported it years ago. There was some improvement, but the problems continue to this day and new and different issues. And in regards to Rithmic, this is nothing new. This has been an issue for years. And it relates in part to the method of integration Sierra Chart has to Rithmic and this is something that we have talked about here in regards to in process API components which Rithmic uses: Sierra Chart Does not Support External Service API Components 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: 2019-10-18 21:38:57
|
| [2019-10-18 23:18:40] |
| |
|
For some history and understanding of how things have progressed: We came out with the Sierra Chart Exchange Data Feed back in approximately 2013. This was offered because we needed to have a reasonably economical data feed which was of good quality and high-performance, and well-integrated with Sierra Chart, and easy to get started with, as a substitute for the problematic data feeds from like Interactive Brokers, and Transact and other services at the time. And using IQ Feed was never economical. This really helped Sierra Chart a lot, and allowed users to use an advanced charting platform, with a good market data feed and still trade on services like Interactive Brokers. And it is always been our hope, that we could offer to all of our users one single unified data feed. This would make supporting Sierra Chart so much easier. And we needed to make it more cost-effective and increase redundancy which is essential, and we found a way to do this. This is now the Denali exchange data feed. There also has been a need to solve so many problems related to trading and make Sierra Chart easier-to-use. And this is the reason we started the Sierra Chart order routing service. And this is still a work in progress, with the next item that it will utilize our own direct CME routing. 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: 2019-10-18 23:19:31
|
| [2019-10-25 03:36:15] |
| uM8137 - Posts: 180 |
|
And in regards to Rithmic, this is nothing new. This has been an issue for years. And it relates in part to the method of integration Sierra Chart has to Rithmic and this is something that we have talked about here in regards to in process API components which Rithmic uses:
Sierra Chart Does not Support External Service API Components Out of curiousity: Rithmic said they built their Protocol Buffer based API, "R|Protocol" which requires no external process or in-process API component, just for you, at Sierra Chart's request. They were then perplexed to report that then you do not utilize it. I've used it, and it seems reasonable. I've found one minor bug, nothing major, and when I reported it they fixed it a few days later. Are there other issues, say with the design? Why not just use the Rithmic protocol-buffers API? To be fair, I suppose you could turn it around and ask them why they don't just implement DTC protocol, which is already protocol buffers. I guess my main concern about the SC Data/Barchart Service in comparison to Rithmic is that Barchart has poor (or at least unknown and no guarantee of precision) clock synchronization method, whereas Rithmic uses PTP/GPS synched clocks to stamp their data, and provides all three relevant time stamps, down to nanoseconds. Date Time Of Last Edit: 2019-10-25 08:25:46
|
| [2019-10-25 08:22:51] |
| |
|
In regards to post #5 : We told Rithmic many years ago to adopt the DTC protocol. They did not seem interested so then we suggested using Google protocol buffers and we also suggested a websocket because that was what CQG and others were using. However, use of a websocket really makes no sense. What is the purpose of this. It is just another unnecessary layer. When finally Rithmic came out with their new protocol based API recently, it is at a time that we are very busy, and not interested in adopting any new APIs for trading the major futures exchanges when we already support so many and we already started the project of our own order routing service which ultimately is going to be migrating to our own direct CME order routing connectivity. We are open to the possibility of supporting the Rithmic protocol API for trading and using our own market data feed with it but then it just ends up with a lot of support questions and exchange fee complications, about people thinking they are going to get market data that they do not, and they need to use our data feed. Now if we bundle our data feed with one of our packages like our Advanced package and increase the price a little and just require the Advanced package to be use with Rithmic, well maybe that is a solution. That might happen. In regards to time stamping, you have a significant misunderstanding here. First of all, our new Denali data feed is not provided in cooperation with Barchart. It does not involve them at all. And with our CME Group data through Barchart or our other infrastructure provider (for Denali), in each of these cases the time stamping is always from the exchange. We always use the exchange timestamp if available which is always the case. And the CME, only timestamps with accuracy to the microsecond. There is no such thing as accurate nano second time stamping. We do not see how this could exist accurately. And the CME does not even do it themselves. And it would be useless to do with an exchange received feed because it simply would be inaccurate. 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: 2019-11-18 16:14:32
|
| [2019-11-07 19:18:49] |
| User12089 - Posts: 350 |
|
I offer commercial software development services to hedge funds, brokers and prop traders who want to maintain their Sierra Chart market data interface to Rithmic (and have budgets for custom software development) This can be done by developing a DTC Server for local/personal use. The DTC Server will be the interface between SC and Rithmic and wouldn't require any changes to SC ie it will be completely external to SC piece of software developed and maintained by me As a retail prop trader I have already developed DTC servers for several other proprietary market data vendors, so I could integrate them with SC and hence use them in my analytics and trading. I am a heavy, long time SC user, as well and long time user of Rithmic - hence have extensive trading and software development experience with both SC and DTC Servers. Developing a DTC Server is the approach recommended by SC for custom integration of third-party market data vendors in SC Besides Rithmic, I can also integrate in SC any other Market Data Feeds, which are about to be dropped by SC, as well as ANY currently unsupported market data feeds, which you may need for your trading for contacts: https://uk.linkedin.com/in/evoeftimov evo@isecc.com Date Time Of Last Edit: 2019-11-07 19:56:49
|
| [2019-11-18 15:44:24] |
| |
|
Thank you Matt for your help. We do appreciate 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 |
| [2019-11-18 17:23:15] |
| uM8137 - Posts: 180 |
|
> And the CME, only timestamps with accuracy to the microsecond. There is no such thing as accurate nano second time stamping. We do not see how this could exist accurately. And the CME does not even do it themselves. And it would be useless to do with an exchange received feed because it simply would be inaccurate. Of course. Nobody expects the nanoseconds part to be accurate. But reporting it even still is immensely helpful as a way to identify what should be transactional updates in the level 2 and thus avoid conveying false opportunities. SC's tick structure doesn't otherwise allow us to discern what should an atomic updates of two limit order prices due to limit order movements in the level 2; e.g. what the Rithmic protocol OrderBook_BEGIN, OrderBook_END messages convey. |
| [2019-11-18 19:52:23] |
| User12089 - Posts: 350 |
|
@Matt Z - let me translate for the rest of the world what he is saying Who is Matt Z and who he works for - He works for Optimus Futures (aka a specific Broker) who happens to NOT have developed their own Visualization/Analytics and Trading Platform (wow Matt Z where were you?) and just reused SC for that purpose - good choice Optimus Futures, I can certify to you and the rest of the world that SC is the best trading platform in the world Matt Z - "We are of the belief that regardless of the data feed you are using, your broker should also have the competence to support it. " Many other Brokers - e.g. IB with their TWS (a very poor cousin of the magnificent SC -sorry IB) have their own platforms - in the case of IB that's TWS. Matt Z, go tell IB to "support SC with Rithmic" - good luck with that babe. IB provides suboptimal data and platform (compared to SC) but they are a better broker (offer broader market access etc) than Optimus Futures. And hey Mat Z, there are many other brokers in this world besides Optimus Futures and none of them has SC as their platform not to mention "supporting it" Another gem from Matt Z - "1) R Trader is free of charge that can be used with Sierra to managing orders." - using SC as ONE PLATFORM for both Analytics and Trading offers best trading performance / results / convenience (those who have ever traded in their life moreover with real money will know what I am saying here) |
| [2019-11-18 20:32:18] |
| User12089 - Posts: 350 |
|
"work/own" - doesn't make any difference to me - it is a form of "association" - that's all I care about I am both a software engineer AND a (highly profitable - audited accounts available to qualified counterparties) trader - I am not talking about "customers / relationships / referrals / running a business etc" (all these are good and useful things btw) I am talking about how to actually get the job done (covered in the current thread) brother (and in the current day and age that happens in a very technical way) - ie specific things, specific mechanisms, naming and articulating things as they are ps: and again - congratulations for selecting and using SC - the platform and the guys behind it are THE BEST in the industry Date Time Of Last Edit: 2019-11-18 20:33:50
|
| [2019-12-06 19:05:43] |
| IconBob - Posts: 61 |
|
I agree with your assessment. I use Denali and it’s the superior data feed order router. I also use Rithmic. Here’s the problem. I can’t connect Denali to other systems. I have a requirement to connect to a non Sierra system. The only common data feed is Rithmic. is there anyway Denali can work with other vendors. If no I’m going to be forced to look for a substitute to Sierra Chart. By the way I already see a deterioration in my Sierra Rithmic data feed.
Date Time Of Last Edit: 2019-12-06 19:08:07
|
| [2019-12-06 19:23:20] |
| uM8137 - Posts: 180 |
|
@IconBob the DTC API allows creation of custom bridges. Your other systems would have to have an API though; or be able to read DTC themselves.
Date Time Of Last Edit: 2019-12-06 19:24:19
|
| [2019-12-06 20:55:17] |
| |
|
Just so you know we are going to contact Rithmic and make a very strong case to them that them supporting the basic DTC message set on their websocket API with Google protocol buffer encoding is something that is much to their advantage and that brings about automatic compatibility with Sierra Chart using the new protocol API. Using the DTC protocol will automatically take advantage of the most efficient high-performance interface that Sierra Chart has to external services because the market data processing and historical price data processing is all on background threads. After all, it is Rithmic, who did not produce a very good API to begin with. We should not have to go through a whole new effort to support a properly done API now. And we should not be disregarded. Sierra Chart has a very strong following now. It is well regarded and respected. And we have a lot of our own user base using the DTC protocol. 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: 2019-12-06 20:56:17
|
| [2019-12-06 21:28:03] |
| uM8137 - Posts: 180 |
|
The only problem with translating Rithmic to DTC is that DTC does not support transactional (atomic) multi-part book depth updates. For example, the exchange can publish an atomic cancel/replace where an order is moved to a different price in the book and DTC will convey an invalid intermediate state between those two updates. I overload the timestamp field as an int64 in nanoseconds and use the convention that the same timestamp should all be applied at once before proceeding. Its a workaround that SC could use too if int64 nanosecond timestamps were used. The drawback is that you have to wait for another new (later) timestamp before you know the transaction is complete. Date Time Of Last Edit: 2019-12-06 21:38:57
|
| [2019-12-06 21:45:33] |
| |
|
Two things in regards to this: The only problem with translating Rithmic to DTC is that DTC does not support transactional (atomic) multi-part book depth updates. It is not true because there is this message which we use ourselves. Notice: FinalUpdateInBatch struct s_MarketDepthUpdateLevelFloatWithMilliseconds
{ uint16_t Size; uint16_t Type; uint32_t SymbolID; t_DateTimeWithMillisecondsInt DateTime; float Price; float Quantity; int8_t Side; int8_t UpdateType; uint16_t NumOrders; FinalUpdateInBatchEnum FinalUpdateInBatch; } And it is very easy to add messages or an additional field or two. And furthermore, the way that we process CME multicast data ourselves and this is also according to specifications, is that you do not send out updates for the order book until there is an end of event indicator. And that end of event indicator, is only after all related book updates are done. Typically this is going to be at the end of a message. But could be after more than one message if there is a lot of related updates and trades. We also have another version of this message which does not use a timestamp when there is no timestamp change to preserve bandwidth. You can get the updated files here: https://dtcprotocol.org/ 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: 2019-12-06 21:52:56
|
| [2019-12-06 22:28:39] |
| uM8137 - Posts: 180 |
|
Thanks for pointing out that there is a new DTC protobuf definition with these new FinalUpdateInBatch features. I'm not sure how to enable getting those messages though, since it is still version 8. I appear to have an earlier version 8 that I have been using since March that lacks the MarketDepthUpdateLevelFloatWithMilliseconds message. It would be cool to increment the version when the file changes, if only a minor version number.
|
| [2019-12-06 22:49:53] |
| |
|
On Logon to the DTC server, you need to bitwise or the following into Integer1: DTC_LOGON_REQUEST_INTEGER_1_USE_MARKET_DEPTH_UPDATE_FLOAT_WITH_MS_MESSAGES = 0x80; There is also this new one: const unsigned int DTC_LOGON_REQUEST_INTEGER_1_SUPPORT_NO_TIMESTAMP_MARKET_DATA_MESSAGES = 0x400; 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: 2019-12-07 01:47:28
|
| [2019-12-07 01:47:02] |
| |
|
Actually thinking about this, this flag is not supported in the DTC server in Sierra Chart: const unsigned int DTC_LOGON_REQUEST_INTEGER_1_SUPPORT_NO_TIMESTAMP_MARKET_DATA_MESSAGES = 0x400;
It is supported through a separate real-time server program that we use on our 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 |
| [2020-01-19 16:22:35] |
| |
|
Furthermore in regards to this, support for Top Step Trader effective with Sierra Chart 2037 and higher, is now removed. If you are using Top Step Trader you will need to use an older version and we are not willing to take on any new users on this service. We have no further comment and this decision is final. We are not providing any further technical support and the relationship with Top Step Trader is fully terminated. For trade simulation, this is the recommended service to use: Simulated Futures Trading Service 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-01-20 19:13:26
|
| [2020-02-14 17:32:25] |
| |
|
Effective towards the end of 2020, most likely in December 2020, newer versions of Sierra Chart will no longer support connectivity to Rithmic.
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-02-17 20:43:39
|
To post a message in this thread, you need to log in with your Sierra Chart account: