Proper procedure when running live scripts

[coolmoss]

I'm trying to determine what the effect of enabling/disabling a strategy (not to mention other procedures like creating a new chart, etc) might have on other running, live strategies connected to a brokerage account might have.

To the point: if one were to disable and enable some strategy connected to Sim101, would doing so likely effect the timeliness of the the running of code in other strategies? Could this sort of behaviour cause slight (perhaps on the order of several seconds to close to a minute) delays in processing the running strategies? The strategy being disabled/enabled is processing 120 days of tick data.

Mind you, I would never do this myself, but I"m trying to troubleshoot a variety of live fill issues for another user. I'm just stumped except that in the trace logs, wherever there are poor executions I'm investigating, I notice lines directly adjacent to the executions mentioning disable/enable.

I don't wish to unnecassarily place blame, but it sure seems like crunching a bunch of historical ticks is bound to cause issues for live, running strategies set to COBC=false.

Thanks for any comments.

[NinjaTrader_Bertrand]

coolmoss, if you're maxing out resources with the calcs to reenable a strategy I would not be surprised to see this happen, especially considering you're rerunning through 120 days of historical tick data to arrive at the current strategy state to go 'live'.

What issues do you investigate? Late executions for a user's script?

[coolmoss]

Bertrand,

I've posted on a couple different issues, mainly "slippage" but also some orders getting filled which should have had plenty of time to cancel. I'm not the offender, as I'm troubleshooting for another user But during troubleshooting, I began to notice in the trace/log that every time a problem trade was brought to my attention, the lines in the trace/log immediately prior to the problem trade, was a pretty good size gap in time back to next prior line, which was always a disable/enable for some other script. Thanks for your help.

[NinjaTrader_Bertrand]

Could you please contact us or have the user contact us via Help >> Mail to Support so we could review the diagnostic trace / log files from the platform for the issue?

Generally in testing / troubleshooting we often find it helpful to reduce / simplify the setup in order to understand the event sequence better, this is especially true if multiple strategy scripts would be involved.

For the performance: would it be really needed to run through prior 120 days of back-testing the strategy in order to trade today real-time?

[coolmoss]

Hi Bertrand,

120 days is not necessary. The user is basically doing historical research on one chart/strategy, disabling/enabling, changing parameters, etc; while live orders are being executed on other strategys/instruments. I didn't realize he was doing this, but it seems fairly self-evident that if a Ninja chart goes blank while refreshing and Task Manager shows the core resources being maxed out, that this is probably why there are big gaps of time between events in the trace file and delays in getting orders submitted.

Suffice to say, I have urged him to avoid doing anything but letting live strategies run uninterrupted by any user interface with Ninja.

Thanks for your feedback.

[borland]

.... if you're maxing out resources with the calcs to reenable a strategy I would not be surprised to see this happen, ....

Bertrand,

"Maxing out resources"... How would one approach testing for this?

I have seen in the NT7 reference document, about initializing CalculateOnBarClose = true, so as to minimize CPU intensive calculations.

This seems to indicate that some incoming ticks may never be processed by strategy logic imediately following the previous bar's closing tick until the strategy logic complete within the OnBarUpdate() user's script.

Makes sence to process trade logic on historical data with CalculateOnBarClose = true, then switch to CalculateOnBarClose = false and only process remainder of the trade logic that's based on current bar (real-time) or intra-bar data. That would eliminate redundant calculations on data that's historical.

borland

[NinjaTrader_Brett]

Anytime the NinjaTrader CPU thread is maxed out on a CORE it would not be able to proceed further until the CPU is done with its calculations.

If you ever see that the NinjaTrader.exe hits and stays at 25% CPU load on an example 4 core processor (100/4=25%) then you have hit the CPU wall on that core and the core needs to finish before we can process more ticks. The tick buffer will grow in the meantime and there are never any ticks lost. The NinjaTrader GUI, (SuperDOM/Charts) could become unresponsive as this occurs.

All historical processing is done COBC = true.

-Brett

[borland]

The tick buffer will grow in the meantime and there are never any ticks lost. .

All historical processing is done COBC = true.

-Brett

So, are you saying the tick buffer is used by NT to find the current bar's Open, High, Low, and Close?

Assuming NT is processing of user code during OnBarUpdate(), incoming ticks of the current bar (close) wouldn't be lost, but can only be accessible to the user if they are the most recent tick (close), or end up being opening tick, high tick, or low tick. True?

[Radical]

The tick buffer will grow in the meantime and there are never any ticks lost.

Is there any way to access the contents of this buffer programmatically?

[borland]

Is there any way to access the contents of this buffer programmatically?

Looks like the only access to the buffer is with this method call....

Bars.TickCount

http://ninjatrader.com/support/helpGuides/nt7/index.html?getaccountvalue.htm

[NinjaTrader_Brett]

No supported method to access a tick buffer if you even had one in the case of performance problem. By definition they haven't been processed yet so you could not access them.

Best method is to find out why you are having a performance problem and move forward that way.

Let me know if you guys need help with that process.

-Brett