High Frequency Systems

[Futures_Shark]

I working on a high frequency system. Do you have any suggestions on the best way to implement through NT? I tested out a ninjascript strategy today and it seemed to slow down considerably after a few minutes running in simulated data. The memory usage was going up steadily and the DB grew from 24mb to 31 mb in less than 15 minutes. I had the sounds disabled

would the ATI interface be more suitable to high frequency strategies? Or would it likely be the same?

[NinjaTrader_JoshP]

You could try disabling storing of real-time data. It is in Tools->Options->Data.

[Futures_Shark]

THe example I'm giving here was being run on the simulated data feed so there was no data being stored. I'm thinking the DB grew so rapidly because of recording all the order updates. The orders were updating with every movement of the bid/ask and I was running it on 4 contracts for stress testing purposes.

[NinjaTrader_Ray]

That could be the case. In real-time brokerage, you will not get that many order state changes since changes are queued until they reach a state where it can be changed. If you system really changes the prices of orders on every bid/ask change, it will surely be shut down by your broker after some time.

[Futures_Shark]

Maybe I would be better off writing a program using the DLL. I was looking at doing this but I don;t see anyway to get the NinjaTrader.Data.MarketData.MarketDataItem set up correctly in my code.

I have subscribed to data and can received updates but haven't been able to properly setup an event handler.

I tried this code:

NinjaTrader.Data.MarketData.MarketDataItem += new NinjaTrader.Data.MarketDataItemEventHandler(MarketDataItem);

But it gives an error: An object reference is required for the nonstatic field, method, or property 'NinjaTrader.Data.MarketData.MarketDataItem'

but I do not see any constructor available for creating an instance.

[NinjaTrader_Ray]

This is not supported.

[Lee.Daxx]

In real-time brokerage, you will not get that many order state changes since changes are queued until they reach a state where it can be changed. If you system really changes the prices of orders on every bid/ask change, it will surely be shut down by your broker after some time.

This doesn't prevent the strategy from amending stop/limit orders every tick as such orders can be symulated in NT. For instance, the actual stop-market order will never be placed with the brokerage. Instead, the stop will be triggered inside NT and NT will send a market order. Note that for some strategies, such as trailing stop-loss, the ability to change the stop level is essential. Obviously, symulated stop orders introduce a delay compared to orders placed directly with the brokerage but for scalping strategies a symulated stop is better than a stop that can only be moved by 10 ticks at a time.

[NinjaTrader_JoshP]

The simulated stop order is an optional setting you can set.