Login Page - Create Account

Support Board


Date/Time: Wed, 20 Nov 2019 18:02:33 +0000



[Sticky] - Technical Help for Rithmic Now To Be Discontinued January 2020.

[2019-10-14 20:24:09]
Sierra Chart Engineering - Posts: 78321
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:
https://www.sierrachart.com/SupportBoard.php?ThreadID=39221

More information on the simulated futures trading service:
https://www.sierrachart.com/index.php?page=doc/SimulatedFuturesTradingService.php

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. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2019-10-15 16:08:08
[2019-10-18 21:24:57]
User760165 - Posts: 1
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]
Sierra Chart Engineering - Posts: 78321
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:
https://www.sierrachart.com/index.php?page=doc/helpdetails76.html
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2019-10-18 21:38:57
[2019-10-18 23:18:40]
Sierra Chart Engineering - Posts: 78321
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. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2019-10-18 23:19:31
[2019-10-25 03:36:15]
zombiekray - Posts: 83
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:
https://www.sierrachart.com/index.php?page=doc/helpdetails76.html

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]
Sierra Chart Engineering - Posts: 78321
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. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2019-11-18 16:14:32
[2019-11-07 19:18:49]
User12089 - Posts: 176
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:33:25]
User864128 - Posts: 2
Hi Guys,

This is Matt Z from Optimus Futures. In order to help the Sierrachart team with their Rithmic support, please ask any Rithmic or Sierra questions here:
https://community.optimusfutures.com/c/futures-trading-platforms/sierra-chart-platform

We support Rithmic because:
1) R Trader is free of charge that can be used with Sierra to managing orders.
2) Rithmic maintains server is Aurora for CME Futures.

We are of the belief that regardless of the data feed you are using, your broker should also have the competence to support it.
Not everything can fall on the "head" of Sierra.

We will support Rithmic data, and if you decide to migrate from it, we will help you in the process.
However, I have worked with RIthmic for over a decade and I am hopeful that parties could resolve their issues because the ultimate person that suffers is the trader.

Thank you,
Matt Z
Optimus Futures

There is a substantial risk of loss in futures trading. Past performance is not indicative of future results.
[2019-11-18 15:44:24]
Sierra Chart Engineering - Posts: 78321
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. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2019-11-18 17:23:15]
zombiekray - Posts: 83
> 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: 176
@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:21:53]
User864128 - Posts: 2
@User12089

Thank you VERY much for your "translation" and revelation.

A Few more facts:

First, I do not work for Optimus Futures. I own it! AKA "specific"

Second, we do not develop our software. We are not programmers, software developers, or visual UI engineers, and we never claimed to be as such.
However, we do take the role that every software we bring on board, we make best efforts to know it and support it.
In regards to Sierra, we have been sending customers to Sierra for years, and we mutually service many customers.

Third, I never asked anyone here to use R Trader INSTEAD of Sierra. Rather, a native application by the data feed provides is an additional way to manage risk in case you are not sure about your positions, what order have been rejected, what other things are working. Also, those R Trader provides Server-Side Bracket OCO, so you can use them side by side.

We know our role, what we provide, and the value that our customers find in us.

Matt Z
Optimus Futures
www.optimusfutures.com
Date Time Of Last Edit: 2019-11-18 20:23:11
[2019-11-18 20:32:18]
User12089 - Posts: 176
"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

To post a message in this thread, you need to login with your Sierra Chart account:

Login

Login Page - Create Account