Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
@Futures Operator
It comes into play with both the platform and the use for custom programming. The former is evident in the lower memory footprint of running SC as compared to NT (all else equal).
As for whether the platform is faster because it is written (mostly) in C++, depends. I cannot guarantee this to you as I have not benchmarked platform-level latency on SC vs NT.
While a code written in a lower-level programming language (C++ vs C#) tends to be faster, writing in that language doesn't guarantee a performance gain. It really depends on how heavily optimized the two pieces of code you're comparing are.
I wouldn't forcefully use a certain language because it is "faster". It's true that many computation-intensive/speed-sensitive financial programs are written in C++, but part of the reason is that there is a large volume of legacy code written in C++ at these firms. Instead, choose the language that you are most comfortable with:
- How accessible is the community, user-base and support for developing trading applications for that language?
- How long do you think it takes to develop and optimize code in that language, based on your ability?
- If you are hiring a programmer(s), you need to make a cost-benefit analysis - C++ programmers tend to charge more.
- Are there any root libraries limited to a particular language that you will you be employing?
- Are you interfacing your code with a database, brokerage API etc., and do these have support for the language you are choosing?
C++, C# and Java are all "premier languages" that are used in low-latency trading environments. For my personal use, I prototype in a different language (it takes less development time so I'll know if it works) then port it to either C# or C++.
I am now using SC primarily, as of a week ago. Starting with the first week of September, I went back to using NT because I just could not visually accept the DOM in SC. It just was not working for me. The best looking DOM I could construct in SC still looked like hell to my eyes. Since the DOM is one of the most important pieces that I use, I went back to NT for the first 3 weeks of the month. Then, SC made changes around version 899 or 900 while I was not using it, that allowed the background colors for the buy/sell columns and depth to be changed.
This change was enough to get me back on board. Finally, I have a DOM that my eyes can see, and while it's still lacking some things (like the ability to make the columns wider for more clickable space), it's quite good now. I am still hoping for the ability to make the chart trading lines in SC shorter (rather than 100% of the screen width).
While using NT I was still plagued by the notorious problem of rectangle bounds. I like to highlight areas more often than I like to draw a single horizontal line. So, for NT I use the rectangle tool. Well, the problem is that if the points of the rectangle are too far from the current view it simply will not draw. This leads to behavior such that zooming in and out will cause rectangles to disappear and reappear. Not only that, but on non-time bar charts such as volume, range, etc., the way NT does things, I kept having to move my rectangle endpoints further out, and when I got them too far out, of course, the rectangle would disappear. In short, rectangles just don't draw properly in NT.
In SC, however, they have the extending rectangle tool, which starts at a point and extends to the right like a ray. Problem solved, and it works. I posted on NT's forum about this problem again and mentioned that SC had a good implementation of this, and my post was deleted. Par for the course--NT generally would rather not put the work into fixing an obvious problem, and certainly doesn't want to hear (or their readers to hear) that
Also, on Sept 16 the CME changed banding parameters for several instruments including ES. On the following day, I was unable to move my stop in NT and got a rejection message from TT. Well, we know that the CME does not support stop market orders, but rather they are actually internally handled as stop limits. So, when a stop market order as the stop loss in a standard NT ATM strategy, at least with TT (but probably with all data providers), you will be unable to move your stop correctly sometimes, due to the fact that the limit price is not changed by NT when you change the stop price. NT's answer was: use a stop limit (which is what internally the CME does anyway). I accept this answer and understand that it's a fine line as to who really is "right" here, but they made no real effort to acknowledge the danger of this (particularly I would think for automated strategies).
So, when I saw that SC had modified the DOM options, I was happy to switch back to them. Plus, it is great to see the charts update at 40ms again in SC, along with an overall general feel of quickness and agility present in SC that NT just cannot match. At market close, when we get the flood of volume, SC hums along pretty steadily with a 40K burst in 60 seconds. It lagged very slightly when 130K traded at the close on Friday. But NT always lags a little bit, regardless. At one point week before last NT got up to 550MB of resident memory usage, and I have yet to see SC go above 100MB with a similar configuration. It will be interesting to see what changes NT 8 brings.
In about a week we will be adding a percentage setting for order lines on a chart to control the horizontal positioning.
When it comes to the column widths for order entry, we will see about making that adjustable. That should not be a problem. This probably will be specified as a minimum character width.
If you have any trouble with the modification of Stop orders when using TT or another trading service, please let us know and we will take care of that. We have not heard of any issue. It is true that a Stop order will be converted to a Stop-Limit order by TT, at least for CME orders, but we do not change the Limit price during an order modification unless the order is entered as a Stop-Limit order to begin with. In that case the difference between the two prices remains the same as the Stop price changes.
This is the attitude all traders want to see, if there is a reasonable request, SC will work on it right away and give you a time table for completion. When you send a request to other platform services, they will either forward your request to develop team or ask you to fill a ticket, and 2 years passed, they still have not touched it. That's why more and more traders switch to SC. Thank you SC.
No problem. We try to do our best. But we have to admit, sometimes some items do take a long time for us to get to. That's why more recently we have been focusing a lot on development recently to catch up on long overdue things.
This is at the expense of sometimes not being able to take too much time answering more advanced usage questions on our Support Board, such as programming/alert related questions. Thankfully, we find that users are helping other users in this area.
If a Stop order is converted to a Stop-Limit order when using TT, and TT provides the Limit price, in the next release of Sierra Chart you will now see the Limit price for the Stop order shown in the Price2 column on the Trade >> Trade Orders and Positions >> Orders tab.
Yes, you are correct. However, the CME does not have a "stop market" order, they have a "stop with protection" (see page 11 and 12 here. For ES it is 12 ticks. Non-reviewable range is 24 ticks, and the limit given to the stop is half of that. What it means is that you cannot get slipped more than this amount (12 ES ticks) on a stop. I suppose that in the case of a catastrophe and you were slipped more than the non-reviewable range, your trade would be reviewed and you would not be at fault, but I really don't know how it would work for sure.
I have not yet had a problem but I have only executed a few trades on Sierra this past week, only traded Monday and Tuesday, so I don't yet have a large enough sample. I am not quite clear; you said that the difference between the two prices remains the same, yet you said that you only change the stop price, not the limit price...? Wouldn't the difference remain unchanged only if you changed both? Maybe I am misunderstanding. From what I understand from NT, they also only change the stop price, and this is, to my knowledge, what caused the problem. At any rate, I will let you know if I encounter any issues with this, and thank you for being ready to make adjustments.
FWIW, this was NT's response to my issue on their forum:
