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... :-(

Sorry, I mainly look at the most liquid Futures contracts which almost all use FIFO. The only one of those that I know that doesn't strictly use FIFO is the 2 year Treasury Note which uses 40% FIFO/ 60% Pro-Rata. :confused: Someone can explain me the "Pro-Rata" matter? Thanks

@Paolo: Sorry, I don't understand what you are trying to say with your formulas. You bet that the largest traders win. No.I' m saying only that you have a divergence between price and CumulativeDelta. On this event anyone can have his opinion. I wouldn't worry about these guys. They don't go through the book so they don't affect the market. At least not in the short-term. I' m not so sure about it.I think (as happens in the bigSP & e-mini arena) someone can make some "tricks" selling in one side and buying on another. For a "CumulativeDelta searcher" (as I wan to be) this is a problem ... Originally Posted by paolfili Are a clear instrument to work with (c++) or a ever-changing mess (as someone suggest me)? Sorry, I don't understand. Can you maybe rephrase your question or elaborate? I have no personal experience on TT's API. Someone tell me anyway that there' s a very speed process of revision of APIs (bugs and update). This can be very frustrating....IMO... Anyway... no personal experience...

Regarding time stamps, the most accurate I have seen is TT's API which gives you 100 nanoseconds, it's still not accurate enough and they don't even come from the exchange. Trades will still appear to have occurred at the same time. Even Eurex sells tick data stamped only down to seconds. Why do you believe they are not accurate enough? Surely they don't came directly from Exchanges. The come from Exchanges on a High-Quality Internet connection and are timestamped on the Feeder servers. On the assumption of a reasonable little variance in the delay of the packets arriving from a supposed HQ connection (that I suppose the serious data feeder would have) we can have a reasonable "good rapresentation" of the correct order of the packets containg the bid/ask + trade.From that (in a platfrom design that mantain the sync between data - Ticker Plant) a Cumulative Delta analysis can have some meaning IMO. These indicators are extremely inaccurate even if you have the best data feed in the world based on the fact that its logic is flawed. First see example above how the same trade by two traders can give you opposite results and I give you another example: 200 bid by a smaller trader, 800 offered by a larger trader. Smaller trader buys 600 at the offer, then the larger trader enters a limit order for 1000 to sell on the bid, thereby taking out the bid, so 800 remain on the offer. Another 200 are bid below that by the smaller trader. Now assume the same thing happens again. So now according to the delta indicator 1200 were bought and only 400 sold even though the smaller trader bought 1200 and is willing to buy only another 200 while the larger trader trader sold 1200 and is willing to sell another 800. If you really want to know what's going on then you should watch the order book. i)200-800 (P1-P2) ii)200-200 (P1-P2) +600 iii)x(200)-800 (P1-1tk/P1) +400 --------------------------------------------------- iv) 200-200 (P1-1tk/P1) +1000 v) x(200)-800 (P1-2tk/P1-1tk) +800 ----------------------------------------------------- vi)200-200 (P1-2tk/P1-1tk) +1400 vii)x(200)-200 (P1-3tk/P1-2tk) +1200 ----------------------------------------------------- Price= - 3tick CumulativeDelta= +1200 Divergence between Price and CumulativeDelta.On this event there are different interpretation. Will win the "big" sellers?Will win the (not so) small buyers? Anyway we have more buyers on a discending price.This can say the CumulativeDelta ---------------------------------------------------------------------------------------- Can you add some words on your suggestion about order book reading ? I don't know whether it's only Eurex. All I know that it's definitely possible on Eurex. I know too it's possible on Eurex. :-( I' m searching a market where this kind of "tricks" are not possible... BTW. Have you any experience on TT's API? Are a clear instrument to work with (c++) or a ever-changing mess (as someone suggest me)? Thanks Paolo

Zenfire API provide BID/ASK on microsecond timestamp.(from their server). The match bid/offer on microsecond basis is IMO a very low probability event.

Only EUREX (for block trades out of the book)? Thanks

This is a very interesting point. Can you explain better how can an order be executed before being placed on the book? Can you detail better the entire process of the order execution? I suppose there were 3 distinct step (for non market order): 1)order insertion on the book 2)cross between an arriving order 3)execution information from the Exchange Can the sequence be different in your opinion? (i.e. becouse of different TCP packet delay and late reconstrucion,etc ...)

Fulcrum can you add some words (on your experience) about TT ? From some of your posts I seen you consider the TT Fix adapter a "low quality instrument". 1)From wich perspective? CumulativeDelta analysis only - due probably to Ticker Plant absence and the coalescing of data - or in general (speed,loosing data,etc) ? 2)Have you some experience on TT API (About Cumulative Delta,un-coalescing of data,speed...)? Thanks again for your sharing experience Paolo

How can you syncronize any liable protocol over IP? Authentication,identification,frame reconstruction,etc.... A lot of RFCs (the base of Internet network) explain the pros and also the cons of the TCP (and of a lot of other protocols over IP). Happy to hear about a new Blowfish/IP protocol mentioned as an RFC.

Zen. Yes.No result. We are probably the 1/1000 of the ZenFire customer interested in correct sybc between trade and best_bid/best_ask.

The ubiquitous *DSL is nowadays the standard. Huge data flows (10Mbps) are well beyond the acceptable managing limit of the retail traders,as we are. (also in term of usability). "Packet loss" in the Network Communication Literature (and in the Network community) has another meaning.