Un-attended trading

March 9th, 2011, 01:17 PM

Hi,

I was wondering if I could kick off a bit of a brainstorm? I’m wondering has anyone done any work with NT on achieving un-attending trading? By this I mean making NT more robust in terms of handling exceptions, order placement for away from bid / ask spreads, etc so it can be more trusted to trade a strategy for itself.

Obviously, this is very open question, therefore, I’m thinking that we might need to specify the problem a little. Therefore, to scope the problem – what about saying we are looking to trade a strategy to trade 1 min bars in the FX market – possibly with a higher timeframe e.g. 60 min – for signals.

To start with an example, one thing I’ve had problems with both in backtest and live testing strategies is the attempted placement of an order within the close of a bar. NT does not like this and it can cause NT to terminate the strategy once the order is rejected by the broker. Therefore, a solution I came up with was checking that we were placing a stop or limit outside a close of the bar. I’ve included a code segment here that I’ve used to do this – it is placed in the OnExecution() method.

Code

        protected override void OnExecution(IExecution execution)
        { 
            if (execution.Order != null && execution.Order.Name == "Long Entry") {
                
                double temp_atr = ATR(BarsArray[0], 20)[0];
                
                // Place the limit order - proftiable exit
                if (execution.Order.AvgFillPrice + (temp_atr) < Closes[1][0]) {
                    
                    ExitLongLimit(1, true, execution.Order.Quantity, (Closes[1][0] + TickSize ), "Exit", "Long Entry");
                    
                } else { 
                
                    ExitLongLimit(1, true, execution.Order.Quantity, execution.Order.AvgFillPrice + (temp_atr), "Exit", "Long Entry");
                    
                }

Just to layout some principles that I think we could possibly focus on making NT NinjaScripts more robust is the try .. catch exception handling code.

I think we probably want to attack the most likely area for errors first – I would suggest that this might be the interaction between the broker and NT. For example, the placing of orders and confirming fills. Again, any suggestions would be greatly received.

Thanks and regards,

drolles

March 9th, 2011, 07:02 PM

drolles,

Thanks for the thread! I agree there needs more robustness in order handling/reporting in the NT<>broker API ... there are other discussions on futures.io (formerly BMT) about setting up and use of VPS closer to exchanges to run automated strategies, to assist with better entries, but that is not where you are looking to here AFAIK.

There are threads on the NT forum about specific issues with most of broker APIs, and none of them are perfect. I do know you are aware of those as well.

Reference to you comment aboutnot having NT stable during backtesting if orders are placed at the value of the close of the bar: by default that it how it is done in backtesting, regardless of either limit or market orders, it is filled at the close price of the trigger bar. Obviously I am not reading your intent here correctly.

I am trying to get my head around your example: it has to do with an order exit, not a entry. I dont understand how that helps. I used COBC=true for running live strategy, and havent had a strategy stopped (that I can remember) due to an order placed after close of the bar.

I think perhaps more detail might assist me, as I do feel improvements need to be made. I just dont know specifically if it can be done on the trader's level.

I have not yet been able to ascertain if the current issues are any worse in NT6.5 than they are with NT7betas: or if in fact NT6.5 is more robust for trade execution.

Looking forward to more discussion,
Jon

March 10th, 2011, 09:39 AM

Trader.Jon,

Thanks for the reply.

Fair questions – let me try to clarify:

The example I’ve given relates to using a second timeframe ATR to determine your stop distance away from your entry price. To take the first example, we test to see if the Close[0] is less than where we will put the Limit exit order. If the close[0] is greater than we put it one Tick above the Close[0]. Ideally, we should be moving this order later after it is safe to put the order closer to its actual require value. I would suspect that this is best done after the next bar in OnBarUpdate().

I’ve had a strategy shut down in mid-flight then a order is rejected by the broker. Take a look at the documentation on the help site: NinjaTrader Version 7. By default NT will showdown your strategy if an order it has submitted is rejected by the broker. You can turn it off or on dependent on what your requirements are. They give a relatively good example in the help documentation.

One of the other areas I was thinking about is using the OnConnectionStatus() method a little more robustly than I have in the past. There are some really good examples on the NT support forum on the use of that method not least here: Connection Lost Notification Code (not working) - [AUTOLINK]NinjaTrader[/AUTOLINK] Support Forum

Kind regards,

drolles

March 21st, 2011, 06:35 PM

Big question. Hope you're still interested - better late than never though.

I assume you are talking about strategies using the NinjaTrader 'managed orders' approach, rather than scripting everything yourself with the unmanaged approach.

In my experience over the previous half year or so, with 10 trades a day roughly, I've only had 2 problems with NinjaTrader screwing up the strategies and as it turns out, I could have ignored the problem and it would have been OK, but my error checking on the IOrder objects my strategies holds told me there was something wrong and therefore they shut themselves down (as I intended when I scripted it).

That was due to the early morning circa 4:30AM GMT+0 Interactive Brokers routine disconnects, as I told you about before I think.

I checked out the NinjaTrader built-in functionality for disconnects and found this:

Quoting

Recalculate: Strategies will attempt to recalculate its strategy position when a connection is reestablished and held for longer than 10 seconds. Recalculations will only occur if the strategy was stopped based on the conditions below. Should the connection be reestablished before the strategy was stopped, the strategy will continue running without recalculating as if no disconnect occurred.

•If data feed disconnects for longer than the time specified in “Disconnect delay seconds”, the strategy is stopped and the disconnect is logged.
•If the order feed disconnects and the strategy places an order action while disconnected, the strategy is stopped and the disconnect is logged.

•If both the data and order feeds disconnect for longer than the time specified in “Disconnect delay seconds”, the strategy is stopped and the disconnect is logged.

I assume this means that NT will submit any orders delayed by connection loss. Or am I assuming too much?

March 21st, 2011, 07:38 PM

drolles if you have not already seen it take a look here:

SystemMonitor for remote servers

I thought it worth starting a new thread as the original thread where this idea started

is very different from where I ended up on a code project.

Use case: You are an NT7 user, you have a remote server you trade on, and you want some protection …

It is in the Elite section so I won't post the code here. Basically you might consider all the things that might go wrong, and code for each of them seperately. You also need to think about what is "global" and what is strategy-specific. Disconnects, for example, might be considered a global problem that can be managed by a seperate strategy.

The biggest problem I've come across is placing limit orders too close to the market. BuyLimit/SellLimit orders on the wrong side of the market will result in a rejection and stratgey shutdown as you have seen.

I have not (yet) migrated to unmanaged orders but that is a next step for me.

traderwerks · March 21st, 2011, 08:53 PM

MXASJ

The biggest problem I've come across is placing limit orders too close to the market. BuyLimit/SellLimit orders on the wrong side of the market will result in a rejection and stratgey shutdown as you have seen.

You mean Stop Limit orders I believe.

March 21st, 2011, 09:06 PM

traderwerks

You mean Stop Limit orders I believe.

It was indeed BuyStopLimit/SellStopLimit that was giving me problems.

March 21st, 2011, 10:09 PM

The only real option I've seen in EL is the use of macros. Macros incorporate the coding that's already in the proprietary matrix. Why the brokers/platforms don't incorporate or release it, is beyond me. It's just dumb and a real pain in the rear.

using macros is simply telling your computer to punch buttons you would.

The biggest problems with hands free, is as you pointed out 1) Uptime and 2) The complexity of limit orders.

I've actually hired a consultant to help with the order rejection on limit orders and I have a viable solution, although it's virtually no different than using a market order. (essentially, you incorporate a pricegap into your order so if you wish to buy at 1.00, then it places the order at 1.00 plus whatever gap you specify .01, .02, .03, etc....which in the end, is the same as experiencing market order slippage.

Even if you get past the dangers in ping lag and having limit orders jumped, the next and bigger issue is partial orders. Limit orders work okay with 1 contract/share, but addressing all the "gotchas" with partial orders is endless. What does it do when it partially fills and then recoils? Do you leave the order out there? Do you cancel the remaining?...How would your exit address either, as if it moves far enough away and hits your stop, does the stop now reflect the number of open shares/contracts?

I've since relegated myself to 2 choices. Either learn to execute macros (which I'm not really sure wouldn't have the same issue...just like a human trying to place an order in very fast moving periods...sometimes you can't click fast enough and your order is skipped/rejected).....OR using market orders. I've had to develop a strategy that can withstand market slippage (and still make acceptible profits after that).

The second issue I'd like to address is dedicated server. DO NOT use a VPS. VPS are partitioned...so you are on the server with others, who have surges in consumption, issues with their partition that warrant restarts, etc.

Pay the additional money and get a dedicated server. I'm planning on using 1and1.com which features $69/month microsoft dual cores....more than enough. Then I'll buy/rent microsoft remote desktop and get a different smart phone that I can access/control the server from anywhere with a connection.

I think the notion of truly hands free is a unicorn. Even with a dedicated server, they still do not guarantee 100% uptime (99.995)% is NOT 100%. Consider this.....there are about 18million seconds in a 6 month period. at 99.995% up time, that's still nearly 800 seconds (over 13 minutes). Ask yourself what 13 minutes could do to you if your platform goes down in the middle of an open position in crazy market conditions. (I personally watched CL move 50c in 5 seconds when the stuff in Lybia was kicking off, which was like 4:00 a.m. Central time...when most people were sleeping.)

I have not checked various service providers for proximity to Chicago and ping response rates...that might be another prudent exercise.

I think at best, you'll have a system where you might be able to have your smart phone on you, but if you're envisioning pushing a start button and going golfing/skiing, I think it's just a matter of time before something melts down. (and if you're progressively upping your positionsize as your profits grow, the risk grows too).

I simply hope for a setup where I can go do other things (while still monitoring my phone) but more like cruise control than auto pilot. The ONLY way you can do that, and it's still not reliable is to hire a human being and train them to babysit for you.

March 22nd, 2011, 05:52 AM

Thanks for all the replies.

This thread has moved on since I last checked it. I’ve obviously got to adjust my settings in the notification of thread updates.

I’ll try to reply individually to the topics raised.

Kind regards,

drolles

Un-attended trading

Discussion in NinjaTrader

Un-attended trading