NexusFi: Find Your Edge


Home Menu

 





NT Providing Bad Price & Volume Data in OnMarketData!!!


Discussion in NinjaTrader

Updated
      Top Posters
    1. looks_one RJay with 6 posts (24 thanks)
    2. looks_two Zondor with 2 posts (5 thanks)
    3. looks_3 aviat72 with 2 posts (2 thanks)
    4. looks_4 NinjaTrader with 2 posts (4 thanks)
      Best Posters
    1. looks_one RJay with 4 thanks per post
    2. looks_two Zondor with 2.5 thanks per post
    3. looks_3 NinjaTrader with 2 thanks per post
    4. looks_4 aviat72 with 1 thanks per post
    1. trending_up 9,804 views
    2. thumb_up 36 thanks given
    3. group 8 followers
    1. forum 18 posts
    2. attach_file 1 attachments




 
Search this Thread

NT Providing Bad Price & Volume Data in OnMarketData!!!

  #1 (permalink)
 
RJay's Avatar
 RJay 
Hartford, CT. USA
 
Experience: Intermediate
Platform: NinjaTrader
Broker: AMP/CQG, Kinetick
Trading: RTY
Posts: 682 since Jun 2009
Thanks Given: 756
Thanks Received: 787

In OnMarketData, NT provides temporary values for coders for volume and price, for bid, ask and last.

These values are accessed with the following code.

-----------------------------------------------------------------

e.MarketData.Ask.Price

e.MarketData.Bid.Price

e.MarketData.Last.Price

e.MarketData.Ask.Volume

e.MarketData.Bid.Volume

e.MarketData.Last.Volume

----------------------------------------------------------------

If you are using any of these coding queries in your indicators, your indicators are displaying bad data!!!


Here are a few examples of what is going wrong:


When several ticks arrive at the same time, NT tends to assign all of those trades the same volume even though the trades all had different volumes.

Also, When the market trends strongly in one direction, the bid and ask prices offered fall behind the live market. This
results in last trades for both the bid and the ask, to be tallied, either, all for the bid, or all for the ask.

This really screws up stuff like volume delta calculations!!!!


This problem is persistent in both NT 6.5 and NT7.


The workaround for this problem is to create your own temporary store values from e.Volume and e.Price.

Below are the lines of code that I now use in my indicators.

---------------------------------------------------------------------------------------------------

if (e.MarketDataType == MarketDataType.Ask)ePriceAsk = e.Price;

if (e.MarketDataType == MarketDataType.Bid)ePriceBid = e.Price;

if (e.MarketDataType == MarketDataType.Last)ePriceLast = e.Price;

if (e.MarketDataType == MarketDataType.Ask)eVolumeAsk = e.Volume;

if (e.MarketDataType == MarketDataType.Bid)eVolumeBid = e.Volume;

if (e.MarketDataType == MarketDataType.Last)eVolumeLast = e.Volume;

---------------------------------------------------------------------------------------------------

After I made these changes and put the temporary patch for the CurrentBar/FirstTickOfBar bug into my indicators, my NT7 indicators are now matching the Time & Sales display window tick for tick.


I plan to post a problem report on the NT forum this Monday and hope they will take steps to resolve this issue.

I am also building an indicator that will send all of the bad data mismatches to the output window to help NT confirm the problem.


Comments and feedback are appreciated,


RJay



FYI, All the Bid/Ask volume indicators I have posted here, on this forum, have this problem. I will update them when NT7 is finally released.

Started this thread Reply With Quote

Can you help answer these questions
from other members on NexusFi?
Are there any eval firms that allow you to sink to your …
Traders Hideout
Deepmoney LLM
Elite Quantitative GenAI/LLM
NexusFi Journal Challenge - April 2024
Feedback and Announcements
NT7 Indicator Script Troubleshooting - Camarilla Pivots
NinjaTrader
Exit Strategy
NinjaTrader
 
Best Threads (Most Thanked)
in the last 7 days on NexusFi
Get funded firms 2023/2024 - Any recommendations or word …
61 thanks
Funded Trader platforms
39 thanks
NexusFi site changelog and issues/problem reporting
26 thanks
The Program
18 thanks
GFIs1 1 DAX trade per day journal
18 thanks
  #3 (permalink)
 Michael.H 
CA
 
Experience: Master
Platform: Marketdelta and Ninja
Broker: Velocity
Trading: NQ
Posts: 663 since Apr 2010
Thanks Given: 64
Thanks Received: 529


Rjay, does this affect the bid/ask ladder in any way according to your research?

Reply With Quote
  #4 (permalink)
 
Zondor's Avatar
 Zondor 
Portland Oregon, United States
 
Experience: Beginner
Platform: NinjatraderŽ
Broker: CQG, Kinetick
Trading: Gameplay KlownbineŽ Trading of Globex
Posts: 1,333 since Jul 2009
Thanks Given: 1,246
Thanks Received: 2,731

The Gom Volume Ladder depends on bid ask data from the GomRecorderIndicator, which is in turn processed by and passed through the GomDeltaIndicator.

I believe that the code in the OnMarketData method of the GomRecorderIndicator is correct. It agrees with sample code that was posted a couple of years ago in the Ninjatrader forums.

  • If the e.MarketDataType is is e.MarketDataType.Bid, it stores the price associated with that event as the most recent bid price.
  • If the e.MarketDataType is MarketDataType.Ask, it stores the price associated with that event as the most recent ask price.
  • If the e.MarketDataType is MarketDataType.Last, that event means an actual trade has occurred. The price and volume associated with that event are the price and volume of the trade. The price of the trade is compared to the most recent bid and ask prices from the MarketDataType.Bid and MarketDataType.Ask events, to see whether the trade occurred AtAsk, AboveAsk, AtBid, BelowBid, or BetweenBidAsk (these are the strings values associated with the tickType Enum.)

Please let me know if anyone can see any problems with this. It looks fine to me.

Follow me on Twitter Visit my NexusFi Trade Journal Reply With Quote
Thanked by:
  #5 (permalink)
 
RJay's Avatar
 RJay 
Hartford, CT. USA
 
Experience: Intermediate
Platform: NinjaTrader
Broker: AMP/CQG, Kinetick
Trading: RTY
Posts: 682 since Jun 2009
Thanks Given: 756
Thanks Received: 787

Zondor and Micheal H. ,

First, Since The volume ladder uses data from the GomIndicator Recorder, It is not using NT's bad volume / price data.

Here is the GomIndicatorRecorder code clearly showing it using e.Price and e.Volume as its data source.

---------------------------------------------------------------------------------------------

TickTypeEnum tickType;

if (!initBidAsk)
initBidAsk=(ask!=0 && bid!=0);

if ((e.MarketDataType==MarketDataType.Last))
{
tickType=GomFileManager.GetIntTickType(bid,ask,e.Price);
if ((recordingOK)&&(initBidAsk)&& (e.Time>fm.LastTimeInFile))



if ((recordingOK)&&(e.Time>fm.LastTimeInFile))

fm.RecordTick(t,tickType,e.Price,(int)e.Volume);

GomOnMarketDataWithTime(t,tickType,e.Price,(int)e.Volume,FirstTickOfBar);
}

else if (e.MarketDataType == MarketDataType.Ask) { ask=e.Price; }

else if (e.MarketDataType == MarketDataType.Bid) { bid=e.Price; }

-----------------------------------------------------------------------------------------------------

However, The ladder does use FirstTickOf Bar in its code. This means it suffers from the FirstTickOf Bar bug in NT7.When the volume ladder is building live on the chart, it is dropping the first tick of every bar.

When you refresh the chart, it will refresh with the correct data from all the ticks.


NT6.5 should be working just fine.

RJay

Started this thread Reply With Quote
Thanked by:
  #6 (permalink)
 
RJay's Avatar
 RJay 
Hartford, CT. USA
 
Experience: Intermediate
Platform: NinjaTrader
Broker: AMP/CQG, Kinetick
Trading: RTY
Posts: 682 since Jun 2009
Thanks Given: 756
Thanks Received: 787


Zondor View Post
The Gom Volume Ladder depends on bid ask data from the GomRecorderIndicator, which is in turn processed by and passed through the GomDeltaIndicator.

I believe that the code in the OnMarketData method of the GomRecorderIndicator is correct. It agrees with sample code that was posted a couple of years ago in the Ninjatrader forums.

  • If the e.MarketDataType is is e.MarketDataType.Bid, it stores the price associated with that event as the most recent bid price.
  • If the e.MarketDataType is MarketDataType.Ask, it stores the price associated with that event as the most recent ask price.
  • If the e.MarketDataType is MarketDataType.Last, that event means an actual trade has occurred. The price and volume associated with that event are the price and volume of the trade. The price of the trade is compared to the most recent bid and ask prices from the MarketDataType.Bid and MarketDataType.Ask events, to see whether the trade occurred AtAsk, AboveAsk, AtBid, BelowBid, or BetweenBidAsk (these are the strings values associated with the tickType Enum.)

Please let me know if anyone can see any problems with this. It looks fine to me.

Zondor,

The purpose of this thread is to warn everyone away from the code you are advocating in your post.

That code is not updating properly!!!

I am your friend and I am urging you not to use that code until NT effect repairs.

RJay

Started this thread Reply With Quote
Thanked by:
  #7 (permalink)
 aviat72 
San Francisco Bay Area
 
Experience: Intermediate
Platform: NT,TOS,IB
Trading: ES,CL,TF
Posts: 281 since Jun 2010
Thanks Given: 161
Thanks Received: 273

Folks:

I need some clarifications here.

1. What exactly is the FirstTickOfBar bug which you are referring to? Is it perhaps the issue that the OnMarketData() call back occurs before the OnBarUpdate() (with FirstTickOfBar == true) occurs if the tick results in the end of the current bar?

If that is indeed the case, I prefer this approach since your code gets the tick prior to all the processing associated with OnBarUpdate for the tick which results in a new bar. When an old bar ends and new bar starts, NT has to do book-keeping for closing the previous bar and creating the new bar. I would prefer if my strategy gets that tick sooner than later.

Ideally, NT could first do a quick check to see if the tick results in a new bar and then set the field accordingly. That brings up a new question:

If you have multiple bars for the same instrument in your indicator, does the OnMarketData() trigger multiple times for each Bar or does it trigger only once for each instrument.

2. Regarding the bad values in the OnMarketData:
I think they use a single structure to store values for all the different tick types but only update the one corresponding to the current tick type. This makes sense from an performance point of view. All they do is set the type and the respective fields and reuse the same-structure instead of resetting it or setting it for the latest value for the other fields. Think if it as getting data tick by tick. When you get a Last Tick (trade), you should not be looking at the fields associated with the Bid/Ask.

Visit my NexusFi Trade Journal Reply With Quote
Thanked by:
  #8 (permalink)
 
RJay's Avatar
 RJay 
Hartford, CT. USA
 
Experience: Intermediate
Platform: NinjaTrader
Broker: AMP/CQG, Kinetick
Trading: RTY
Posts: 682 since Jun 2009
Thanks Given: 756
Thanks Received: 787


aviat72 View Post
Folks:

I need some clarifications here.

1. What exactly is the FirstTickOfBar bug which you are referring to? Is it perhaps the issue that the OnMarketData() call back occurs before the OnBarUpdate() (with FirstTickOfBar == true) occurs if the tick results in the end of the current bar?

If that is indeed the case, I prefer this approach since your code gets the tick prior to all the processing associated with OnBarUpdate for the tick which results in a new bar. When an old bar ends and new bar starts, NT has to do book-keeping for closing the previous bar and creating the new bar. I would prefer if my strategy gets that tick sooner than later.

Ideally, NT could first do a quick check to see if the tick results in a new bar and then set the field accordingly. That brings up a new question:

If you have multiple bars for the same instrument in your indicator, does the OnMarketData() trigger multiple times for each Bar or does it trigger only once for each instrument.

2. Regarding the bad values in the OnMarketData:
I think they use a single structure to store values for all the different tick types but only update the one corresponding to the current tick type. This makes sense from an performance point of view. All they do is set the type and the respective fields and reuse the same-structure instead of resetting it or setting it for the latest value for the other fields. Think if it as getting data tick by tick. When you get a Last Tick (trade), you should not be looking at the fields associated with the Bid/Ask.

Answer to 1.

Version 7 beta22 Dropping Ticks??? - Page 2 - [AUTOLINK]NinjaTrader[/AUTOLINK] Support Forum

Answer to 2.

When determining if a Last Tick occured at above ask, ask, between ask and bid, bid, below bid, you have to look at the most recent bid and ask ticks.

If the bid and ask ticks are not updating in real time, you got a problem.

Started this thread Reply With Quote
Thanked by:
  #9 (permalink)
 aviat72 
San Francisco Bay Area
 
Experience: Intermediate
Platform: NT,TOS,IB
Trading: ES,CL,TF
Posts: 281 since Jun 2010
Thanks Given: 161
Thanks Received: 273



I think the conversation confirms what I wrote in the previous post. The FirstTickOfBar is only valid in the context of OnBarUpdate().

It is not valid on the OnMarketData event. Making it valid would require NT to pre-process the tick and then establish a new bar is being formed prior to sending the OnMarketData event. This requires more computation and would delay the OnMarketData event.

NT is prioritizing the OnMarketData event over OnBarUpdate. They could split the processing of OnBarUpdate into parts; a pre-processing step which checks whether a new bar is being formed which is called prior to OnMarketData() and then the rest of the stuff which is done OnBarUpdate().


Quoting 

Answer to 2.

When determining if a Last Tick occured at above ask, ask, between ask and bid, bid, below bid, you have to look at the most recent bid and ask ticks.

If the bid and ask ticks are not updating in real time, you got a problem.

Rjay:

The point I was trying to make was that the fields which are valid is based on the context of the event type. If the event is of type last, then looking at bid info for that event is not valid. NT could return an exception saying that the field does not even exist; but that will add more code and will slowdown the system.

That is why GOM stores the price stores the last bid/ask locally based on the type of tick. Your expectation of the last bid/ask price and volume data being set correctly on a Last event is not consistent with the type of event OnMarketData() is designed for.

Think of it in terms of a tick stream. If you have a series which says: B,A,A,L,B,A then to check for the Bid fields on event 4 (L) is not valid. You need to check for the value passed on the last Bid event (event 1) which you should store locally.

Visit my NexusFi Trade Journal Reply With Quote
  #10 (permalink)
 
Zondor's Avatar
 Zondor 
Portland Oregon, United States
 
Experience: Beginner
Platform: NinjatraderŽ
Broker: CQG, Kinetick
Trading: Gameplay KlownbineŽ Trading of Globex
Posts: 1,333 since Jul 2009
Thanks Given: 1,246
Thanks Received: 2,731



RJay View Post
Zondor,

The purpose of this thread is to warn everyone away from the code you are advocating in your post.

That code is not updating properly!!!

I am your friend and I am urging you not to use that code until NT effect repairs.

RJay


hi RJay,

Please post sample code or pseudo code showing correct method to use, thanks!

Follow me on Twitter Visit my NexusFi Trade Journal Reply With Quote
Thanked by:




Last Updated on June 5, 2017


© 2024 NexusFi™, s.a., All Rights Reserved.
Av Ricardo J. Alfaro, Century Tower, Panama City, Panama, Ph: +507 833-9432 (Panama and Intl), +1 888-312-3001 (USA and Canada)
All information is for educational use only and is not investment advice. There is a substantial risk of loss in trading commodity futures, stocks, options and foreign exchange products. Past performance is not indicative of future results.
About Us - Contact Us - Site Rules, Acceptable Use, and Terms and Conditions - Privacy Policy - Downloads - Top
no new posts