I'm testing an autotrading strategy that trades CL on 4 range bars.
So far today, the strat has twice encountered the dreaded "sell or stop limit orders can't be placed above the market" condition. That triggers a rejected order and shuts the strat down, as I've not yet coded in rejection handling routines.
I am using NT 7 beta 22, Kinetick data feed and the system was running in Sim mode so it wasn't even connected to a broker API.
I write well optimised code as I have been a pro software developer for years, but I'm starting to wonder if NT is inherently fast enough to cope when a fast moving instrument like CL hits the gas pedal, when using short time frames.
I'm going through the same thing using Unmanaged = true. Please don't quit-with your experience, you should be able to improve on code I'm using to handle these rejections.
Right now, I'm using this in Initialize:
(I haven't noticed if this really helps or not)
and this in OnExecution
Obviously, the order entry section needs to address where price is with respect to your entry stop or limit. I had to test numerous times with chart trader to make sure I understood which one needs to happen below the current price and which is above.
So far this seems to help with only the barstate=2 section. Haven't fully tested the barstate= 3 part yet.
Good luck.
Kirk
The following 4 users say Thank You to zeller4 for this post:
Many thanks for the unmanaged code samples. I do actually use unmanaged orders at the moment, though I haven't added code to handle order rejections yet.
I think the issue is that my strat is multi time frame so this seems to slow down its performance, which becomes a problem when CL starts a rapid price movement - by the time the strat places the order for the target price, the market has moved beyond it.
I use COBC = true to try and speed things up.
As my SL is 4 ticks and PT is 8 ticks on a 4 range chart, the system seems too slow to handle it. I don't know if a shorter time frame for the mtf anchor would speed up performance or not.
If you have programming experience and you have a system that really works, you can code it to use your broker's API directly and bypass Ninja. Even if you convert your strategy to unmanaged code, you have no idea what else Ninja is doing with your CPU.
The following 2 users say Thank You to Crow for this post:
Interesting idea, thanks Crow. I didn't want to reinvent any wheels, hence using NT for its mtf and inbuilt connectivity and order handling capabilities but I'm starting to wonder if it is just adding another layer of latencies.
I see that you use Java. A friend builds HFT systems in Java with direct connectivity to the exchange APIs running on Linux boxes, and gets stunning performance. Have you got any recommendations for Java libraries?
The sad truth is NT isn't fast enough in CL, FDAX or TF. You can try a dedicated server close to the exchange to improve latency and/or adding buffer ticks to the strat. Consider the slippage the price of getting a fill.
I'm not so sure about that (I can't speak for Crow, of course). I've been looking at the strat you're working on which looks very promising, not so sure about the entry criteria though
Yep, makes sense, but with multiple time frames, I think that COBC=false would bog the system down even more.
I really don't want to resort to custom programming a trading system from the ground up unless I really have to so I'm thinking of ways to use just one time frame, but the strat is only profitable when it uses a higher time frame anchor at the moment.
I think CL jumps over some prices occasionally when momentum is boosted, which makes good control of order rejections vital. You are also competing with some very low latency systems which makes autotrading it even more challenging.
If I get it working with NT I'm going to host it on a dedicated server in a Chicago datacentre to try and reduce network latencies as much as possible.
David
The following user says Thank You to David for this post:
Hi Zoe, our replies crossed. It makes you think about trading an easier instrument, but the volatility of CL and the daily profit potential is enormous and maybe worth the challenge assuming that a solution can be found.
Have you traded Aardvark in a live or papertrade environment yet?
The only way I can get good fills is by placing limit orders well ahead of the current price action, which is why I am using MTFs, particularly with an 8 tick profit target where market orders would kill the profit.
I can relate to your problem because I ran into it on a strat that had limit orders placed a bit in advance and got that ugly error message when price moved fast in thin markets shutting the strat down. But since my profit targets were larger than yours, I didn't mind taking a couple of buffer ticks to get a fill. Two ticks wasn't going to be the difference in whether it was profitable or not, since it traded about twice a day.
traderwerks - do you mean call setstoploss() function and then enterlimitlong() function for example at a price above the current ask? Could you share a code sample if you don't mind so I understand your statement better. Thanks!
Use the OnMarketData call to get the incoming price and then send the order. Also help ful if you want to trigger off the bid/ask instead of last. There is code on the web if you Google for it.
The following user says Thank You to traderwerks for this post:
I am still in the strategy development phase and I have not yet found a strategy that I feel comfortable enough automating and letting it run on its own. However, I don't use NinjaTrader and built some of my own charting tools based on JFreeChart (java library for graphics, MyDoggy (Java Window Manager), and everything runs inside RapidMiner (#1 open source datamining platform by KDNuggets). It handles real-time data, but I'm mostly using it to look at historical data in search for a profitable strategy. Main reason that I went with a completely custom solution is because I didn't want to be limited with visualization. Secondary is because and I don't know how Ninja handles the data. It makes some great candlestick charts and pretty indicators, but I also use Linux and Ninja doesn't run too well in WINE. That said, I am surprised your friend built an HFT system on Java. I have not had any performance issues with Java, but the garbage collector / virtual machine do add some performance overhead. I really like Java and it's my favorite programming language, haven't really used C# too much (again, Linux), but it's probably very similar.
The following user says Thank You to Crow for this post:
Thanks, I don't use the IB data feed but use Kinetick, which seems OK, though occasionally I notice that a few ticks "bunch up" and get delivered in a burst which causes the strategy problems.
I think that is caused by Internet connectivity latencies, which I hope would not happen with the server connected via a big pipe in a datacentre.
Many thanks for that Crow. I have a strong PHP/MySQL background so it shouldn't be diffcult to pick up Java, if need be. It was straightforward moving to C#.
So far, the only automated strategy that I've found to be reliable uses small profit and stop loss targets for quick scalps where you can have as much control as possible (which still isn't much), however this is causing the problems discussed in this thread.
My mate is a Java wizard and definitely uses it on Linux, so I don't know how he gets around the problems that you mention. He uses large databases for storing historical SR levels, I believe, so he has to handle database interaction under HFT conditions too.
I wish I could talk to him about his systems in more detail, but he works for a large fund and their systems are their business and are therefore highly confidential.
I've been investigating further into what is causing the rejected order situation.
It doesn't seem to be the MTF computations, but the fact that the strat is placing a stoplimit order two ticks above the trigger bar. As I am using COBC= true, by the time the trade entry order is placed, the market has moved past it.
Whilst I'm relieved that mtf doesn't seem to be causing problems, at least yet, it does mean that I'm going to have to revisit the trade entry criteria to place the entry further from the immediate price action when trading CL.
