Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
I think I understood that part. Why even bothering to calculate which side is winning? Just always calculate it both ways and show two lines.
What I'm getting at though is that the system doesn't account for losses. So say we're getting a strong down move with lots of traders getting stopped out over and over. Like the trend down move in treasuries today. You get trapped volume up above you that never gets canceled out. It gets stuck because the volume came out as stops instead of limit orders. So your cost basis estimate ends up being higher than it should.
The easy solution as per your earlier explanations is to just adjust the timeframe you're looking at. View on a 30 minute basis or a 5 minute basis. Then that old volume gets rolled off. But if you factor stop orders in as well then you can safely eliminate some of those trapped traders from the calculation and get a more accurate reading without having to reset.
A "tick" is the minimum integral unit of price change possible. Sure, multiple tick levels when averaged would
fall "in between" allowed price tick levels, but I digress.
When we do Market Depth Analysis, we capture data at PRICE-SPECIFIC LEVELS. So we allocate analyzers,
using a HashMap or Dictionary approach, where each POSSIBLE Price level (as enforced by the idea of a
"tick") is associated with an "Analyzer" which captures Quotes at that specific price for each Analyzer.
However, when we wish to take a "Snapshot" of the Market Bias, for purposes of predicting Market direction,
it is at this moment when we use the BID price (and lower prices) and the ASK/OFFER price (and higher prices)
to fetch the reports from the Analyzers, and we then represent them as "Tier Specific Offsets" from the
Inside Market (the current inside BID and ASK prices).
It ain't that easy LOL but, as I've said elsewhere, "Thar's Gold in Them Thar Hillz" if you can evaluate the
Market Depth (aka "The Live Book") correctly.
And IT MAKES SENSE, DOESN'T IT? that Market Makers advertise their intentions in the critical placements
of their BIDs and OFFERs in the "Markets that they Make; ya know, Market Makers is what they are"...
I think I could write it in bookmap. I'm just not really in a spot to invest in a new platform, and there's some execution based edges that I don't think I can get over there. If there's a way to get around that I'd be interested in helping write it in Bookmap. Maybe though I'm just enamoured with the idea of writing something that touches the API directly? We're talking about some things that are fairly calculation and memory intense. It would probably be better to have such analysis in a different application from the application you are using to execute from. The Ninjatrader 8 - Jigsaw combination is perfect for it. Too bad ninjatrader doesn't have MBO data.
Unfortunately, I learned "the hard way" that Ninja does not have a setup for a Rithmic Data Feed. You must take the entire Rithmic Order Routing and Data Feed package, and that invalidates your usage of their CQG broker.
Of course, nothing stops you from coding your own C# to the Rithmic API and feeding that data into your Indicator(s) but it would not be "natural" through the Ninja Framework for datafeed only.
Yes, they market their Kinetick feed as a "feed only" option. But that's a "business decision" and they have no such feed only arrangement with Rithmic.
By using the Rithmic API, no doubt you could get "deeper" into things like MBO (whatever that is...) but unfortunately that could not be integrated as an "officially supported" NinjaTrader Connection adapter; as they simply do not support such a thing; and you'd have to Beg, Borrow, Bribe or Steal the code which could be used to write a proper Connection "snap in" to NinjaTrader 8... <speculation>
I decided to start a thread to provide some samples of historical market depth and MBO data to consolidate a solution for different questions on execution quality, data integrity and latency. My main goal is to encourage more latency transparency and …
I started my journey of return to Futures with the ATAS fully programmable platform
that allows for unrestricted C# usage. (I am a Java programmer with some C#
experience, and I can quickly adapt my code).
ATAS is a great concept, but it is poorly supported; and was simply frustratingly
unable to hold on to the Rithmic feed and Orders connection; and this is from
a dedicated system hosted in a data center, so...
I had to move; and my buddy is fairly non-technical but really saw the potential
of the Ninja platform; so the only platform I could find with any hope of being
able to host (adapted versions of) my C# code... was NinjaTrader.
Since using NinjaTrader 8 for a while; and especially after the nearly unsupported
ATAS platform (sorry to say) I am also a NinjaTrader ADMIRER !!!
So I adapted, and hosted evernthing in C# in Ninja; and will be writing "Unmanaged"
multi-threaded Order control panels, etc.
SO, THERE IS NO BETTER PLATFORM THAN NINJATRADER 8 (or maybe 7) and
so there's nowhere to go Why would I want to leave such a powerful
platform; over a minor issue like this Rithmic feed issue; especially when there
is a resolution to my issues, even though it's slightly different from what I
was planning? NO REASON.