atomic OCO orders and internet disconnections

[NinjaTrader_RyanM1]

Hi Paul,

Can you at least allow your managed orders to send the Stop Loss order at the same time as the entry order as a true OCO?

OCO is not applicable in this case. If your stop loss order and your entry order are tied together as OCO, then your stop loss order will be canceled as soon as your entry order is filled.

We offer Advanced Trade Management which submits stop loss and profit target orders upon entry execution.

If you want to get your stop loss order in before you enter you can manually place an order that will function as a stop loss.

[pbcah]

atomic IB TWS OCA group orders and internet disconnections

Hi Paul,
OCO is not applicable in this case. If your stop loss order and your entry order are tied together as OCO, then your stop loss order will be canceled as soon as your entry order is filled.

An OCA Group order (one cancels all Bracket) inside the IB TWA can be automatically pre-set ahead of the entry order being transmitted to the server at which point the bracket orders are simultaneously sent to the server as an atomic operation. If any part of the IB TWS OCA Group order fails, all three attached orders are cancelled.

An OCA Group order is applicable in this case, Ninja refers to it as an OCOid in the SubmitOrder method. The whole idea of a bracket order in IB is to protect your position from the get go.

We offer Advanced Trade Management which submits stop loss and profit target orders upon entry execution.

Your link describes using an ATM strategy to manage the trades. Unfortunately it does not allow any back testing which is not practical for our needs at present.

We have programmed in C# (Ninjascript) a complete money management strategy that makes use of several indicators for entry and employs a combination of indicators and price action to decide on exit points. 99% of the strategy works perfectly however we want to employ tried and proven approaches to handling orders over remote connections and your Managed Orders layer appears to function perfectly with the exception that it does not do atomic operations. Our development is written for NT7 so the link to NT6 won't work. Also, you could see this as an opportunity to upgrade this issue and retire it in the NT7 B16 release if there is the will.

The API of the StrategyBase.EnterLongStop and StrategyBase.EnterShortStop methods with their accompanying StrategyBase.SetStopLoss and StrategyBase.SetProfitTarget methods appears well suited as they provide one handle.

From what I can see, their only drawback is that instead of submitting the orders simultaneously with the entry order using one trigger, you delay the StopLoss and ProfitTarget order placement until the OnExecute event is received and here's the beef, you do it from Ninja instead of the remote broker's server.

Ok, this allows you to adjust the stop loss price if there is slippage however, this is at the cost of leaving you naked in the market (should your connection break) and NinjaTrader relies on the internet which is inherently unreliable. You'd be surprised at how often we loose connections with the various IB servers and this means you're building in losses as is being born out by our test team.

If you want to get your stop loss order in before you enter you can manually place an order that will function as a stop loss.

Are you referring to the use of an "ExitLongStop" and ExitShortStop" orders as the NT7 documentation expressly contradicts this "This method is ignored if a long position does not exist" and will this order trigger before an associated "enter" order is placed and filled?

Alternately, can I assume you're suggesting using the unmanaged SubmitOrder method to place three orders, an entry order, a stop loss order and a profit target order with the "OCOid" parameter set to identify these are a common order?

Are these transmitted to the IB TWS in one operation thereby guaranteeing one atomic operation? It does not appear apparent by the sginature of the SubmitOrder method. It appears that orders are sent to the IB TWS and transmitted instead of being simply sent to IB then transmitted (triggered) using one operation.

If I need to use SubmitOrder, do I need to provide any special handling for partial fills and I guess I can modify the order inside the OnExecution event method to account for slippage using the ChangeOrder method? I see that special handling must be added for orders that have already partially filled.

Now Ryan, If you look directly at your feet then continue through the planet to the other side, you'll probably find my house and NO, contrary to popular myth, it's not China (I'm in the Southern Hemisphere in Perth Western Australia). What this means is we are nearly exactly 12 hours apart. Is it possible for you to break my queries down and give me a point by point reply as every question I'm sending is taking 24 hours to tease out a reply which comes while I'm asleep and then my further question comes while you sleep. We're nearly finished with this development and the results look very promising.

When you reply can you please send me to some specific samples that completely demonstrate the methods you've been describing?

As this is a complex and important issues, I'm being somewhat long winded here but I'm trying to be very clear and unambiguous, I'd appreciate the same in return please?

I'd also appreciate your patience and understanding.

Paul

[NinjaTrader_RyanM1]

Hi Paul,

OCO in NinjaTrader works like this:
All orders that are part of the same OCO group are canceled once one of the orders is filled. For this reason attaching a stop loss to an entry as OCO won't have the results you want.

You can achieve what you want in TWS and we have noted this suggestion as something you would like to see in NinjaTrader. My intent was to clarify OCO functionality in NinjaTrader.

My suggestion to place a functional stop loss order prior to an entry order was not related to any specific automated trade strategy methods. It's something you can do in the platform manually and I recognize now this is not what you're looking for.

Using our managed order system, you will not be able to place all three (entry, stop, target) orders at once. You may be able to accomplish what you want with unmanaged order submission, but not by attaching entries, targets and stops with the same OCO id. See here for an introduction to using unmanaged orders.

[pbcah]

Hi Paul,

OCO in NinjaTrader works like this:
All orders that are part of the same OCO group are canceled once one of the orders is filled. For this reason attaching a stop loss to an entry as OCO won't have the results you want.

You can achieve what you want in TWS and we have noted this suggestion as something you would like to see in NinjaTrader. My intent was to clarify OCO functionality in NinjaTrader.

My suggestion to place a functional stop loss order prior to an entry order was not related to any specific automated trade strategy methods. It's something you can do in the platform manually and I recognize now this is not what you're looking for.

Using our managed order system, you will not be able to place all three (entry, stop, target) orders at once. You may be able to accomplish what you want with unmanaged order submission, but not by attaching entries, targets and stops with the same OCO id. See here for an introduction to using unmanaged orders.

Yes, this is what I suspected. Do you by chance use the Dinosaur API for the IB connection as they allow you to send multiple orders to the IB TWS and then send the last order with the Transmit flag set. This then performs a nearly Atomic operation like I'm requesting.

Can you get management to add it to your A category iissues list for implementation in the next NT7 Beta release? If necessary, I'd be happy to provide my services as this is an important and urgent reform.

Regards,

Paul

[NinjaTrader_Bertrand]

Hi Paul, we use the IB API contained in TWS 900.6 - please be assured that your request and enhancement suggestion has been noted, however at this point in time we're working with priority on stabilizing NT 7 beta to make it ready for the production release, after this we'll revisit adding further features and enhancements.

[pbcah]

Hi Paul, we use the IB API contained in TWS 900.6 - please be assured that your request and enhancement suggestion has been noted, however at this point in time we're working with priority on stabilising NT 7 beta to make it ready for the production release, after this we'll revisit adding further features and enhancements.

Yes, when you're in the swamp surrounded by crocodiles, you're not looking at any particular crock. I'm seeing some blogs around that are not exactly flattering.

For my part, we are using NT7 15 within limits and we're confident you're going to get the stability issues sorted out. The current build has a memory leak and grows every time we perform a back test. Perhaps if the StrategyBase took responsibility for the memory clean-up when you set enable to false that issue would be removed.

We also see the entire platform crash every now and then, again, I think that's related to a memory management problem as it only seems to crash after long use.

Is there one point in your code where you can perform exception handling to trap the memory failure and clean-up memory thereby allowing for a soft landing?

Has anyone done a cost benefit analysis on the new features being provided. Can some of these new features be turned off to bring the product back to the core then progressively re-enable expensive features. This should have been done generally ahead of implementing the features however it's a good techniques for delivering systems and provides a way of focusing on the real issues. Also when you turn off some features, you will hear from your user group pretty fast if the items are valuable to them (Political) and this will indicate how much the new features are being used. You can provide a dynamic switch for each feature so they can turn them back on for their testing and if they are the only one experiencing issues, then you know there is a problem in that module.

I recommend getting a copy of "Soft Systems Methodology" from the university of Lancaster. I studied it while I designed a large telecommunications learning diagnostics system in the UK right back in 1990. It calls for examining features of a proposed system from two points of view, a Logical value point of view and a Political Value point of view. Each feature should be given a weighting factor and normally a cost. The rest is simple, do the items in the list that have the highest political and logical rating and the lowest cost first. Then progress down the list with the next highest and so on. Things that have a high cost but a low political and logical weighting may never get done however who cares as they're a waste of time.

If you employ this basic methodology you will deliver the systems on time and on budget every time and your customers will love the features you deliver.

[NinjaTrader_Bertrand]

Paul, sorry for my late reply and thanks for sharing your insight and feedback here - do you have simple test script that would exhibit the memory leak issues you're referring to? We're not aware of any issues at this point and would like to check into with a script showing this issue at play.

Thanks

[pbcah]

Paul, sorry for my late reply and thanks for sharing your insight and feedback here

I hope they helped as was my intent. I have used this methodology on countless projects with very high success and you'll be amazed at how much time you can save.

- do you have simple test script that would exhibit the memory leak issues you're referring to? We're not aware of any issues at this point and would like to check into with a script showing this issue at play.

Thanks

I'm doing lots of regression testing of a strategy and run one over 90 days of 1 minute bars. I can't share this code as it is confidential however I can say that during this testing, the NinjaTrader.exe gradually increases it's memory usage until it fails (occasionally). We did have NinjaTrader.exe binaries staying i memory when closed also.

When I dis-able a strategy does Ninja completely destroy the Strategy instance and it's associated tagged objects or do I need to overtly cleanup and delete objects, indicators and tagged text objects? I'm really expecting the StrategyBase to do most of this work as these should be aggregate components of that base class.

[NinjaTrader_Bertrand]

Hi Paul, releasing resources is handled by the .NET garbage collector - you can't force it to do it's job right on the instant but it will be cleaned up eventually. If you use custom resources be sure to 'tag' them for being cleaned out in OnTermination().

[KBJ]

We also see the entire platform crash every now and then, again, I think that's related to a memory management problem as it only seems to crash after long use.

Is there one point in your code where you can perform exception handling to trap the memory failure and clean-up memory thereby allowing for a soft landing?

This never seems to have been addressed in this thread.

It's over a year since the quoted posting and I wanted to mention that I've seen this happen for some time. I didn't mention it much when NinjaTrader 7 was still in field test, but now that I'm on 7.0.1000.6 it should probably be looked at.

Recently I've seen this with the StrategyAnalyzer where it almost instantly exits NinjaTrader with no messages except a "stack overflow". I've made it happen less often by reducing the memory used. (Strange that trimming memory use should effect a "stack overflow" but it seems to help... My suspicion is that something runs out of memory and that this somehow or other precipitates a stack-overflow.)

[NinjaTrader_Austin]

pbcah, KBJ, memory is managed by .NET, not by NinjaTrader.

Please be sure you are properly disposing your resources in the indicator, and OnTermination() as necessary.

[werner]

Atomic submission of orders

I was reading this thread and I am having the same concerns as Paul. The issue is that if the connection breaks between the sending of entry and stop loss order you might be left without protection.

Has this issue already been solved (since the thread dates from some time ago)?

Regards, Werner

[NinjaTrader_Austin]

Werner, I will have someone get back to you tomorrow.

[NinjaTrader_Bertrand]

Werner, an atomic order submission enhancement suggestion is tracked currently by us under #1166 - at this time the ATM exit brackets are only send if the original execution is received and reporting filled within NT.

[waynewright33]

Was this ever addressed? I've written a strategy where I managed my my own stop prices and forced certain fills with my own fill type to get accurate backtesting results because all my exits take place on stops. Now I'm in the process of re-coding the strategy for live use and need to know what methods to use to have everything possible stored on IB/exchange servers.

This issue of all entry orders and associated OCO's not being sent together as one package and then disseminated by IB concerns me. Is this a real life issue or what's the best way to address it.

If I enter the market, with an initial stop, and keep adjusting it relative to price action, is Set() or ExitStop() the better option if I want the order with IB and not on my PC.

Also is set() slower the exit()?

Thank you.