what are your opening account balance requirements?
what are your daytrade margins on the popular emini contracts?
(ES, EMD, YM, NQ, QM, CL, TF/AB/ER2, 6A, 6B, 6C, 6E, 6S)
what are your platform choices, and associated fees monthly, if any?
what or which data vendors and fees are available, for say the Ninja platform?
sure would be nice to know those essentials, perhaps even pick up a few converts along the way
The following 2 users say Thank You to kronie for this post:
Due to time constraints, please do not PM me if your question can be resolved or answered on the forum.
Need help? 1) Stop changing things. No new indicators, charts, or methods. Be consistent with what is in front of you first. 2) Start a journal and post to it daily with the trades you made to show your strengths and weaknesses. 3) Set goals for yourself to reach daily. Make them about how you trade, not how much money you make. 4) Accept responsibility for your actions. Stop looking elsewhere to explain away poor performance. 5) Where to start as a trader? Watch this webinar and read this thread for hundreds of questions and answers. 6) Help using the forum? Watch this video to learn general tips on using the site.
If you want to support our community, become an Elite Member.
The following 2 users say Thank You to Big Mike for this post:
We are working on our calculated market statistics, like NYSE TICK. These are intended to be of very good quality and accuracy. We plan to release these in February.
In regards to Zen-Fire and Sierra Chart, if you have a look around at the postings about what is currently going on, at the time of this posting, with Zen-Fire now that it no longer utilizes Rithmic technology, it would not even matter whether we supported their API component or not. There are numerous technical problems being reported on this forum, ninja trader forum, and Mirus has acknowledged this. It would only makes sense that we stay clear of this until these problems are worked out and resolved. Zen-Fire users were always a small percentage of our user base.
We do not work with in process API components. We thought we would make an exception to the new Zen-Fire API, but after working through it, we decided not to continue because of the problems and confusion. It was a mistake for us to even consider this API or any other API for that matter going forward. This comment in no way should be taken negatively towards Mirus or the API developer. These are our own personal views based on decades of experience. We believe in quality and logical engineering and working with a neutral communications protocol between the client and the server.
We believe that when it comes to communicating orders between the client and the server and all of the trading related data, this must be done in a very well understood, clear and structured format. The best protocol is FIX and the best implementation we have seen is TT.
Edit: Also the DTC protocol that we are working to establish, is a good protocol as well. It is efficient with market data. And there is one clearing firm that has adopted it.
We work at the protocol level. We have also started an initiative in this industry to a develop a plug-and-play communications protocol between trading program/applications and the backend trading services and data feeds. This allows complete interoperability between the clients and the servers. If you have a look at the Sierra Chart website, you can learn about the DTC protocol initiative.
We hope Zen-Fire and others will join us in this effort.
However, we do not limit ourselves to DTC. We can work with any protocol, as long as it is logical and clearly documented. We also need sufficient time to be able to interface to a service. With Zen-Fire, there was not sufficient time. The whole thing happened too quickly.
If we have said things, that are not considered appropriate here, then the administrator can delete them. I just wanted to get some thoughts out there to bring an understanding among our Zen-Fire users. If you currently have a Sierra Chart account with paid usage time and cannot use it because you do not have access to Zen-Fire and were previously using Zen-Fire, please get in touch with us about this.
Last edited by SierraChart; January 5th, 2014 at 04:10 PM.
The following 10 users say Thank You to SierraChart for this post:
Rithmic has discontinued their contract with ZenFire. It means ZenFire is no longer available through the Ritmic API that is used in 3rd party platforms like MultiCharts and others. We were provided with a new ZenFire API but as it was developed by ZenFire in short terms, it is not stable enough. We're developing the broker and data feed connections to ZenFire and manage intensive testing to make it work as it should in MultiCharts. Our development team are doing their best to complete the connection development in the shortest possible time. We're sorry for the inconveniences.
We'll be sending the e-mails and posting all the necessary updaters on our Forum for a new API once they are ready. Unfortunately there is no ETA at the moment. Thank you for understanding.
There needs to be more attention brought to this concept of API components. These components are developed for amateur/beginner programmers. Professional programmers do not need to mess around with API components. They only cause us unnecessary trouble and complications.
The idea that a protocol cannot be open, and needs to be private and confidential, is complete nonsense. We have had enough of this nonsense. And Mirus and others should learn something from this.
None of us should be supporting the in process API component concept any longer. This is the source of so many problems for programmers and the end-users. A lot of problems you face with connectivity and stability in the programs that use them are due to API components.
None of us should be using API components any longer and insist upon a change. We have already made that decision and Ninja trader and Multicharts should do the same.
Edit: For those of you who do not fully understand this discussion, I guess a simple way of explaining it is that every programmer has their own way of doing things. It does not make sense to mix with one programmers code into another programmers code base. Inevitably they will conflict with each other and there will be problems. You as an end user have no idea where the source of the problem is.
Each program (the client-side trading program, and the server side market data and trading server) should implement their programs using their own methods and ideas and then use a neutral communications layer between them. This neutral communications layer is going to be a protocol like FIX or DTC. Or some other proprietary protocol.
Obviously, we all have to still deal with the underlying operating systems which computer programs are built on. But the core functions of underlying operating systems, are generally well-designed and well-documented. Critical functions like network sockets and files are very thoroughly designed and provide a proper API. Although the code below a computer program should be as minimal as possible. This is why the fastest, most efficient, and the most reliable programs are ones which are built on top of as little code as possible. This is one reason we do not use .NET. Sierra Chart is built directly on top of the Windows API, at the present time.
Last edited by SierraChart; January 5th, 2014 at 05:18 PM.
The following 10 users say Thank You to SierraChart for this post: