Errant Auto Chase Behavior on Entry Orders in Sim101

[TheFil]

Curious whether this is known/current behavior, but I have instances where limit entry orders submitted via a NinjaScript Strategy utilizing ATM Strategies for order management where AutoChase is enabled and ChaseLimit = 1 are sending perpetual price modifications regardless of price direction (so the entry order is being continuously modified) until the market moves fast enough to fill the order (i.e. the price modification fails to update prior to getting a fill). The Chase functionality seemingly disregards the side of trade, so for example a limit sell at 3900.00 is modified UPWARD to 3900.25 and vice-versa.

This is happening with data vendor Continuum in the Sim101 account in the front-month ES contract.

Thanks for any input/thoughts.

[NinjaTrader_ChrisL]

Hi, thanks for posting. Could you please share a video that demonstrates the issue and shows the ATM template that is being used? I like to use TinyTake to share videos easily.

Kind regards,
-ChrisL

[TheFil]

Thanks NinjaTrader_ChrisL, I'll try to capture a video of the error and share it in this thread.

[TheFil]

NinjaTrader_ChrisL, see attached video: https://www.screencast.com/t/C7Q44Xzvma

I included the full lifecycle; from resting state to initiating the strategy and forward.

I have the Log window and Orders window alongside to help tie everything out.

The first bug occurs at video timestamp 1:21 -- a 1 lot BUY LMT @ 4034.50 order with AutoChase 1 tick enabled is submitted and subsequently modified by AutoChase DOWNWARD to 4034.25 at log timestamp 8:52:40.741. Obviously this should not happen. The order should rest at 4034.50 and only be modified UPWARD by a maximum 1 tick pending the last traded price.

Between the first erroneous modification at 8:52:40.741 and 8:52:43.546 there are a cascade of AutoChase modifications until the LMT price is finally modified UPWARD to 4034.75 at log timestamp 8:52:43.546.

This behavior recurs frequently and is easily reproducible.

Interestingly enough, the NEXT entry order at video timestamp 1:34, 1 lot SELL LMT @ 4036.00 log timestamp 8:52:53.242, is CORRECTLY modified DOWNWARD 1 tick to 4035.75 at log timestamp 8:52:53.422.

Finally, another entry order at video timestamp 2:23, 1 lot BUY LMT @ 4033.75 log timestamp 8:53:41.692 is CORRECTLY modified UPWARD 1 tick to 4034.00 at log timestamp 8:53:41.919.

So, what we have is an example of the buggy behavior on a BUY LMT order, expected behavior on a BUY LMT order, and expected behavior on a SELL LMT order, all within 13 seconds of each other

Let me know your thoughts when you have a moment to review. Happy to provide additional details as required.

[NinjaTrader_ChrisL]

Hi, thanks for the follow up. I'm not able to reproduce it, I did not see the ATM template being used in your video. I attached my test script and included an image of the ATM template I am using If you would like to test on your end.

[TheFil]

Thanks NinjaTrader_ChrisL,

My ATM Template is configured the same as yours:

[NinjaTrader_ChrisL]

Hi, There must be something going wrong in the script you are using. Did you try testing the ATM strategy on its own? I tried both through an automated strategy and standalone ATMs and the auto chase only updated once.

[TheFil]

I've actually experienced this issue across a variety of calling scripts, so while I agree with your logical deduction we can see clearly from the logs that the AutoChase is in fact the action being called and modifying the entry as compared to something within my script that would be making an inadvertent EntryOrder modification...

I was thinking as well, since the ATM Strategy is created async to the calling thread I assume all embedded actions contained within an ATM Template (i.e. AutoChase) also execute on that separate thread -- is that fair to say? Not sure whether that helps us drive towards a resolution, but I'm simply curious to know.

What's strange/concerning is that the error isn't consistent (as per my video where the error occured and then the next two subsequent entries executed as expected). This "random" nature makes me wonder whether multithreading may be contributing to the conundrum in some way.

I'll continue digging/testing and provide an update as I uncover new info.

Any further insight/suggestions are definitely welcome.

Thanks again.

[TheFil]

Continuing to have issues here...

Any thoughts in regards to potential async issues? Maybe I'm entirely off base though.

[NinjaTrader_ChrisL]

Hi, Im sorry for the delay. A NinjaScript object runs off what are called "Instrument Threads" but a NinjaScript object also uses multiple different threads for data (E.g. Historical data operation comes from a thread pool and OnExecutionUpdate/OnOrderUpdate comes from "Adapter" type threads). ATM strategies and NinjaScript objects work from Instrument threads in real time operation, but since they are not the same object, we can not assume they are in sync.

[TheFil]

Thanks NinjaTrader_ChrisL, good info.

In thinking through this I come back full-circle to the notion that the AutoChase feature is "buggy" or perhaps the more apt expression would be "incompatible" with my deployment whether due to the environment instance (i.e. sim v. live), the frequency of computation, or some other reason...

Testing whether it's the first case (sim v. prod issue) is an undesirable endeavor, for obvious reasons, so let's assume that's not it

My understanding of the ATMStrategy object is that it runs async to the OnBarUpdate() calling thread; that is to say that all pre-set parameters (i.e. AutoChase, TrailingStop, etc.) of the ATM Strategy, once the ATMStrategy object is successfully created, execute independently of whatever is happening on the NinjaScript Object OnBarUpdate() thread. Is this an accurate statement?

If so, then that should mean that whatever iterative method that calls updates for the ATMStrategy object (perhaps its a reflection of OnBarUpdate()) should be able to execute the pre-set parameters without error. If you reference my video example, there are no external (external from the perspective of the containing ATMStrategy object) entry order modifications -- only AutoChase. Deductive reasoning points to a bug in the AutoChase code within the containing ATMStrategy object.

Any adapter issue would arise at object instantiation, if I'm not mistaken, so if we know that ATMStrategy has in fact been successfully created then that implies errors "downstream".

What's left at this point is thinking about the entryOrder itself relative to the inside market and last traded price...

I am placing LMT orders, so the chase condition should begin to evaluate after confirmation of the order is received AND the bid/offer moves away from the resting LMT price for a buy/sell order, respectively. I'm trying to think about the condition that would cause this process to fail, and it's not immediately apparent to me.

Assume for a moment we're talking about a buy LMT order. If the entryOrder was submitted with LMT price ABOVE the quoted best bid upon arrival at the exchange then this order should fill assuming sufficient liquidity on the offer at that moment. I'm having this problem with an order size of 1 in the front-month ES contract, so liquidity is not a limiting constraint. If the entryOrder was submitted AT the quoted best bid upon arrival at the exchange, then my order joins the queue in last position and should only update if the inside market moves up 1 tick. If the entryOrder was submitted BELOW the quoted best bid upon arrival at the exchange, it joins the queue at that price level and the same logic regarding an uptick in the inside market applies. Hopefully I'm thinking about all of this in an accurate way.

Looking forward to your thoughts.

[NinjaTrader_ChrisL]

Hi, thanks for the follow up.

For your first question, that is a fair assumption, and if we assume that the ATM strategies work like a NinjaScript object, they also use multiple different threads for data and run on the instrument thread in real time. I can try testing my test script on the same data feed you are using to see if there is different behavior if you would like.

Kind regards,
-ChrisL

[TheFil]

Thanks NinjaTrader_ChrisL,

Yes, could you test on the Continuum data feed please?

[NinjaTrader_ChrisL]

Hi, I tested on Continuum but find no difference in behavior with my test script.

Kind regards,
-ChrisL