This horse just never seems to die, no matter how many times it gets kicked.
As many of you know, when it comes to evaluating buying and selling pressure (aka volume deltas), I am a die-hard up/downtick kind of guy. I really don’t use the bid and ask at all.
I’ve gone on ad nauseum on the rationale behind this, especially in the early posts of the price vs volume series. Well I was poking around the Ninja support forums a while ago looking for something completely unrelated when I ran across this quote from ZenFire, posted by Ray from NinjaTrader, which reiterates what I’ve been going on about for oh-so-long.
In my opinion, it’s a less than stellar idea for someone with a retail data feed to rely on the bid and ask for evaluating buy and sell pressure. Why? Because the bid, ask and last are actually separate, asynchronous feeds. Many traders assume these three (bid, ask & last) components are all synchronized and are therefore “reliable.”
They are reliable, but certainly not synchronized.
The bid and ask components of the stream can – depending on how your feed is connected near/at the exchange – lag in times of heavy trading in order to make room for the actual trades (or “last” as it’s called). Again, from ZenFire quoted by Ray:
There are different connect points that may throttle the update of the bid/ask in order to make room for all the trade updates. For colocated machines and in special cases we may give a trader direct connect points knowing they won’t buffer and get behind. Internet users can’t typically keep up and their last trade price becomes stale if they try to pull in the market depth updates. With little importance being placed on the market depth and focus on the last trade, more users can keep up with volatile conditions.
The actual thread is here if you want to read it.
By the way, this is not a ZenFire issue. No Internet-streamed retail data feed consumer is colocated (meaning your trading machine is physically at the exchange) and therefore
might will at times suffer lag in market depth. This is just how the whole system is designed. When needed it tries to ensure timely reporting of the last component of the feed by throttling, buffering or filtering of the bid & ask components (market depth). If you understand this, it can be a strength and you can use it to your advantage. Or at least allow it disadvantage you as little as possible.
The fundamental issue is that you’ll never know for sure how much lag you’re experiencing (or not experiencing) without a deeply technical investigation. You simply won’t be able to tell just by watching. And it may be pretty darn hard to know for sure which “connect point” your particular feed has been given – or get a definitive answer from your data provider on this subject. Not trying to assassinate any data feed characters here. Just saying there are known unknowns and they should be respected.
Trade ’em accordingly (and well) this week, amigos…