Archive for category: Ninja Boot Camp

[box style=”rounded”]

[iconbox title=”Updated: It’s all in the details” icon=”process-stop.png”]If you’re a continuous contract user, what needs to be done at rollover is a perennial source of confusion. So it’s critical to know which type of continuous contract you are using – provider adjusted or not provider adjusted.

It could be either depending on how you have your account connection set up. But you only need to take the steps below if you are using a continuous contract that is back-adjusted by your provider. If you’re using a dated contract or a non-adjusted continuous contract, there’s nothing to see here. Just go ahead and keep right on truckin’. ;-}

Want to know how to configure your connection for provider back-adjustment? Click the link in the first paragraph below.[/iconbox]

[/box]

If you trade futures you probably already know about contract rollovers. But if you use a back-adjusted continuous contract (it will end in ##-## instead of a date) did you know you need to take one extra step after the close on rollover day?

What is that extra step? You need to delete all your stored data and refresh it using Ninja’s Historical Data Manager. Why? Because the new adjusted price affects all previous prices for all previous contracts.

Sound scary? It’s really not.

Here’s how to do it:

1. Disconnect from your data provider
2. In the Ninja Control Center, click Tools > Historical Data Manager…
3. Click the Edit tab
4. Find your contract in the list, then right-click on the symbol
5. Click Delete
6. Reconnect to your data provider

Historical Data Manager

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…