paolfili

I make a similar kind of analysis with a my custom Ninja indicator on FESX (Eurostoxx) and ES from 3 weeks. Tracking demand/supply response with the orderflow on 1-Range charts with on bid/ask volume and DOM movements . At the moment no evidences (in my undestanding) of High Probability Setup. You have also to consider that Zenfire doesn' t assure a correct bid/ask data even with the recent update of the Ninja7 to offer no more snapshotted DOM data. The only correct feed for Ninja bid/ask tracking seems DTN (or Kinetick). The DOM feed is UDP with Zenfire.How can you assure that your algos are working in correct set of data also in a high traffic period? I appreciate your explaining replies and probably I will ask a Demo contacting George in some days,but in general I think pattern recognition in trading is largely influenced by feeds and MD Trader and Nina * DOM and tick * are really different.

IMHO The best advertising for your product could be a daily journal of your live trades explained,or better a live trading room where anyone can observe your signals. I buy books/products/anything about trading ONLY from people talking/teaching CLEAR methodologies. A Black-Box software is not so interesting for me (and many other). Can you explain in depth what you consider as 'exhaustion'? Can you post some chart/video examples of the last days?

Fulcrum, can you confirm from your experience that,considering the lag from Eurex Exchenge to USA, the **SEQUENCE** of bid/ask is syncronized with the contracts_exchange data so, that the EUREX.DTN data can offer a correct cumulative delta approach? (using i.e. The GomCD indicators for Ninja) Thanks Paolo

Fulcrum, can you confirm that Ninja+DTN.IQ is a good option to track a correct Cumulative Delta? Thanks

First of all Thanks. Not so much traders share methodology and suggestion in such a free way. So,if you, want, let' s focus on an analysis method for the Bund's DOM (and Bobl's DOM). Some questions arise from your statements. Are you sure your bid/ask feed is not aggregated? (i.e. IB aggregate data in 300ms windows) Are you sure your collect all bid/ask data? (i.e. Zenfire UDP feed CAN loose data) I assum the reply will be positive and continue. i)For example, it goes +34, +76, +22, +89, etc. which of which the sum then (surprisingly or not) ends up to be exactly 500, 1000 or 2000 This is a "black box algorithm searching" edge. Despite your (positive) experience an analysis in "Exploratory Data" context is probably useful. ii)On how many months of "good" trading experience is your method based?) ii)Can you detail your trade managment rules (Ex. TP+5/SL-2). iii)Can you add some words on the "big traders plays" you note in the DOM and in particular have you designed a "scanner" software for this plays? Thanks

These are not shown (though in some markets a market maker or specialist can see these) Please,can you say which Market(s) are you talking about?

I see. But there' s no difference between stop orders and market orders. How can you select?

If you have used a 'DOM' or price ladder this is quite easy to visualise. IYO the trades are from 2 bid/ask queues.Limit (visible from DOM) and stop (unvisible from DOM.) Can you explain how visualize from bid/ask/trade flow some limit/stop order execution? (or make some examples)

http://www.traderslaboratory.com/forums/208/zenfire-dtn-feed-different-7301-4.html#post84940

Is there even a feed that guarantees receipt of all data? Do you even want that? X_Trader API doesn't, and there is a good reason for it. They told me that most customers prefer to get the most up-to-date data than all data which might be delayed when there is a lot of data at one point in time. It makes sense if you think about it. You don't want to stale information (e.g. old inside market) even if it is complete. I guess one problem to solve this would be to have 2 feeds, one feed that guarantees the most recent data that you can use for quick decisions and execution (e.g. for MD Trader) and another feed that guarantees that you get all data for processing (e.g. for data analysis). TT also has a FIX API and the FIX server can be configured to your needs so that might be possible there, but I haven't had time to closely look at it. As always, It depends. If your signals/oscillators/edges are based on 1/2 seconds timeframe (and you cannot afford to loose 5 seconds to send the order) you are right. Anyway having ALL the data you can explore(in the ExploratoryDataAnalisys meaning)/backtest/observe what you cannot see in partial data. (The Best Bid/Ask - Trade sync problem of Zenfire is an example). You talk about Book Visualization,but if your Book data are partial the Visualization is based on partial data....probably the data you get is enough for your needs, but always partial. Can you enumerate Zen-Fire's advantages/disadvantages. I thought about using them but there aren't any brokers with decent commissions that offer Zen-Fire. The main disadvantage is (for me) the impossibility to have correct Cumulative Delta. But you have the (partial) data about all levels on the Book if you are interested in book' s tricks.(don' t' know about X_Trader API book). I think it' s fast enough,doesn' t coalesce data,and offer (from API) a microsecond timestamp.The backoffice "chain" (for me) is short enough(double login account etc). On the other side is probably used from a very little group of customers (from the small number of forum' s posts) and the "developer" support is close to 0. On the next weeks probably I 'll can have a deep look to X_Trader API (via TTNET),so any comparision will be more meaningfull.

I've worked with Ninja Trader, IQFeed's API (DTN), X_Trader API and another one that was tied to a specific broker. I've worked so long with the X_Trader API that I thought all of them didn't give me sequential order book updates while I just checked the API documentation of each data feed again and it looks like X_Trader API is the only one that doesn't. I' m working with ZenFire API. You can have the Bid/Ask and Best_Bid/Best_Ask data,but.... But UDP streams can loose data. If you cannot afford a very High quality connection (as the usual Rythmic customers can probably afford) you have not guaranteed sync (and no value from any CumulativeDelta analysis... if you believe in any value about CumulativeDelta analysis...). The same problem is related to any Book Analysis/Visualization process(following Agekay point of view). DTN seems TCP.But from the API documentation I' ve seen there 's the cumulative bid/ask wothout single level analysis. Someone can add something on this matter about TT' s API? Thanks I stopped working with Ninja Trader and IQFeed pretty quickly because Ninja Trader didn't allow access to its data from external applications and I had latency issues with the IQFeed. Can you explain the latency issue between Ninja/IQFeed?

Sorry,but the "real" problem of Zenfire' s API is not the "out of order" (as you have noted in the Zenfire' s forum).You can solve it by re-sorting the timestamps. Sadly to say,but the "real" problem is that UDP gives no guarantee that any packet Zenfire send will arrive.

The thing is a stop is just a market order sitting there waiting to execute at a certain price or better. If a limit comes in and crosses that order it will execute and never display on the order book. Are you sure about it? Is this the correct Exchanges behaviour? Where can I find some (CME,EUREX,etc) explanation on the market dynamics you suggest? (order on trade never displayed on the book) Thanks

If you are using the Zenfire' s API consider also the well know "UDP" problem of the feed...which invalidates many timestamps meaning. Anyway I think that the "correct" sequence (send by the Exchange) can be preserved only by a "Ticker Plant" design platform. Zenfire doesn' t offer this... :-(