Zenfire and DTN Feed Different?

[SNYP40A1 10]

Anyone know if Zenfire or Rithmic has made any statement about this?

[paolfili 10]

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.

 

 

 

Anyone know if Zenfire or Rithmic has made any statement about this?

[SNYP40A1 10]

I e-mailed two people at Zen-Fire and have not received comment. They both have responded to my queries before. I suspect that they are not saying anything until they have either determined the cause of the issue and/or the fix. I could be wrong, but their silence tells me that they know about the issue and are still working out the solution.

[paolfili 10]

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.

 

 

 

SYN is a TCP session parameter. If you are not using TCP you will be immune to a SYN Flood (as you are not using TCP you will not reply to SYN requests). By not using TCP you will be immune to attacks that rely on TCP protocols.

 

To route you need IP and that's it. Nowadays of course routers do all sorts of higher level 'stateful' stuff and look deep into packets to do higher level 'clever' things. (Like traffic shaping and prioritisation for example). None of that information is needed to route.

 

Why re-invent the wheel? I am certainly not advocating that, it would not make sense for a lot of people. However if you do not require all the bells and whistles provided by TCP (a generic protocol after all) but do require some simple transport control and session management then it might make sense.

 

Still this goes way beyond the discussion here.

[BlowFish 10]

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.

 

You write the code yourself within your application. It's not hard if you know what you are doing.

[SNYP40A1 10]

You write the code yourself within your application. It's not hard if you know what you are doing.

 

Nothing is hard if you know what you are doing...

[BlowFish 10]

Nothing is hard if you know what you are doing...

 

Except maybe trading! Where knowing what you should do and actually doing it often are a metric mile apart!!

[AgeKay 10]

I seem to remember that Globex was one of the exchanges that did not support market orders natively in days gone by. My broker (IB) still simulates them. What Globex now provide (according to the reference guide) is market order with protection. I am not sure when they introduced this order type but think it must be fairy recently. Before this order type was available your broker would simulate a market order by placing a limit order well inside the market. Market order with protection is essentially a limit order (with a wide limit).

 

Market with Protection

Market orders at CME Group are

implemented using a “Market with

Protection” approach. Unlike a

conventional Market order, where

customers are at risk of having their

orders flled at extreme prices, Market

with Protection orders are flled within a

predefned range of prices (the protected

range). The protected range is typically the

current best bid or ofer, plus or minus

50 percent of the product’s No Bust Range.

If the entire order cannot be flled within

the protected range, the unflled quantity

remains on the book as a Limit order at

the limit of the protected range.

 

Sounds like an ordinary limit order placed at the "protective range" to me. Maybe they just had to give it a fancy name to make those traders happy that "need" market orders but don't know they can accomplish the same thing with a limit order.

[AgeKay 10]

Yes.....I have mentioned before that I have verified DTN.IQ feed.....it is the ONLY regular feed that I use and have been able to verify.

 

I do think that CQG probably has exceptional feed too....

 

You say that CQG is an exceptional feed, but have you been able to verify it also, the way you did with IQFeed?

[Rearden Metal 10]

(This is a review of Telvent DTN's $2,500/month NX Core feed)

 

AOL would be easier to cancel!

Beware of Telvent DTN's shady billing & cancellation practices! If you must deal with this company, be aware that they will use petty fine print trickery in attempt to extend your contract beyond the agreed upon period and squeeze every possible cent of revenue out you. You will become an asset to be exploited to the fullest possible extent of the law (and beyond). You contract isn't over until THEY say it's over. If you don't like it, they'll even threaten your credit score. Is this really the kind of company you want to do business with?

[diablo272 10]

(This is a review of Telvent DTN's $2,500/month NX Core feed)

 

AOL would be easier to cancel!

Beware of Telvent DTN's shady billing & cancellation practices! If you must deal with this company, be aware that they will use petty fine print trickery in attempt to extend your contract beyond the agreed upon period and squeeze every possible cent of revenue out you. You will become an asset to be exploited to the fullest possible extent of the law (and beyond). You contract isn't over until THEY say it's over. If you don't like it, they'll even threaten your credit score. Is this really the kind of company you want to do business with?

 

Can you elaborate upon your experience with this feed/company?

[BlowFish 10]

(This is a review of Telvent DTN's $2,500/month NX Core feed)

 

AOL would be easier to cancel!

Beware of Telvent DTN's shady billing & cancellation practices! If you must deal with this company, be aware that they will use petty fine print trickery in attempt to extend your contract beyond the agreed upon period and squeeze every possible cent of revenue out you.

 

I had issues with them in the past (a long time ago now) that sound pretty similar. Not with fine print trickery simply billing after the contract had been cancelled (and confirmed as cancelled). Then they tried to sue me for the 'outstanding' amount. Funny and mildly irritating at the same time. That is one reason I am reticent about using them again.

[AgeKay 10]

Just use a credit card. If they charge you after you've cancelled then your bank will just refund it. Try that with PayPal...I love credit cards.

[BlowFish 10]

Just use a credit card. If they charge you after you've cancelled then your bank will just refund it. Try that with PayPal...I love credit cards.

 

Yeah I was fine but they still started court proceedings to try and recover this fictitious 'debt' eek! Maybe I should have filled counter suit and flown to the USA to fight it.

 

Good point about PayPal..... I use it often (probably too often) as it is so convenient. Worth remembering (and to keep remembering) that CC's afford much more protection.

[FulcrumTrader 10]

You say that CQG is an exceptional feed, but have you been able to verify it also, the way you did with IQFeed?

Tested it twice in the past 6 months and all was good. CQG has a BID/ASK differential TFlow product, so they have to provide clean BID/ASK data to properly feed the TFlow study.

 

Fortunately I have never had any DTN billing problems as mentioned by others.....billing games are a pain in the butt and the last thing I ever want to waste time dealing with.

[quertrader 10]

The main difference between ZenFire(Rithmic)/DTN.iq feed framework is the quantity of data.

Any Platform (NinjaTrader/Inverstor RT/etc) relies on API from the feed provider.

From what I' ve seen the DTN API can offer only BEST_BID/BEST_ASK, and cumulative VOLUME_BID/VOLUME_ASK.

Zenfire API can offer all level bid/ask change.This is a lot of data (more than DTN).

If the Zenfire book information will be reliable you could explore in very depth way the futures DOM (probably some quants are doing this now).

But probably the "price" for the possibility of this huge amount of data is the UDP design of the feed.

Another possibility is to re-organize the design of the feed.

(Any Zenfire guys hearing ...? )

 

Hello, paolfili! Does that mean, that e.g. NinjaTrader DOM can only show me the best bid and best ask rows of the orderbook? What exactly do you mean by "cumulative volume_bid/volume_ask" - the sum of all (how many) bid/ask rows?

Has anybody experience with DTN@EUREX?

Thanks!

[AgeKay 10]

Eurex data from DTN lags by about 1 second. Sometimes even more.

[quertrader 10]

Thanks for your fast answer AgeKay!

Ok, if that's true, I would guess that DTN doesn't have a data center next to Eurex. This would mean that the data has to pass the distance Europe-USA to their data center, gets the timestamp in the USA and then comes all the way back to my trading desk in Europe.

 

Somebody told me that Zen-Fire has a data center next to Eurex. If that's true, their data should hopefully lag less.

 

I'm also not sure if the UDP "problem" of loosing data is present when receiving only data of contracts with less volume (e.g. DAX)?!

[AgeKay 10]

DTN's problem has nothing to do with the location of the data center (and no they don't have a data center in Europe). That would have added at most 200ms. Their data just lags. They don't even know why.

 

I had no issues with Zen-Fire. It's an excellent feed.

[FulcrumTrader 10]

First of all, zenfire/rithmic data is unusable for proper bid/ask data needs....so trying to use this feed for CME, ICE, EUREX, NYMEX, or any other markets would in the end be a complete waste of time. Second, I traded the DAX heavily this month as I do many months, and I did not have any problems at all with my DTN.IQ feed (while exceeding my monthly profit goals as I have done all year).

 

The bottom line......zenfire/rithmic feed was never built in any fashion to be focused as a bid/ask tracking mechanism (that is just what many retail type traders are trying to make it into). The zenfire/rithmic feed was built for order routing and basic price and total volume information.....this of course does NOT include parsed volume information of the bid/ask differential.

 

DTN.IQ feed was built to be a complete feed (with a proper ticker plant) for many data/charting uses to INCLUDE historical data look back capabilities.......this INCLUDES up to 30 days of very well formated historical BID/ASK data.

[AgeKay 10]

I should have mentioned that I used it in Europe from three different countries. You might not have any issues trading Eurex from the US, but you'll see a lag in Europe.

[quertrader 10]

I should have mentioned that I used it in Europe from three different countries. You might not have any issues trading Eurex from the US, but you'll see a lag in Europe.

 

Ok, so is there an alternative to DTN.IQ feed for traders located in Europe (with ragard to proper bid/ask Eurex data)?

[paolfili 10]

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

 

First of all, zenfire/rithmic data is unusable for proper bid/ask data needs....so trying to use this feed for CME, ICE, EUREX, NYMEX, or any other markets would in the end be a complete waste of time. Second, I traded the DAX heavily this month as I do many months, and I did not have any problems at all with my DTN.IQ feed (while exceeding my monthly profit goals as I have done all year).

 

The bottom line......zenfire/rithmic feed was never built in any fashion to be focused as a bid/ask tracking mechanism (that is just what many retail type traders are trying to make it into). The zenfire/rithmic feed was built for order routing and basic price and total volume information.....this of course does NOT include parsed volume information of the bid/ask differential.

 

DTN.IQ feed was built to be a complete feed (with a proper ticker plant) for many data/charting uses to INCLUDE historical data look back capabilities.......this INCLUDES up to 30 days of very well formated historical BID/ASK data.

[FulcrumTrader 10]

I should have mentioned that I used it in Europe from three different countries. You might not have any issues trading Eurex from the US, but you'll see a lag in Europe.

 

Correct....that may be possible (have no idea what would cause this for EU based traders though). BTW, I know many EU and Dubai based traders using CD trading methods I have developed (with DTN as their feed for CD work), so I will have to talk with all of them Monday to see what they are detecting.

[BlowFish 10]

 

The bottom line......zenfire/rithmic feed was never built in any fashion to be focused as a bid/ask tracking mechanism (that is just what many retail type traders are trying to make it into).

 

However despite this you where recommending it as such up until the recent CME reporting changes. It is certainly not "unusable for proper bid/ask data needs". You are assuming that everyones needs are the same as yours. Sure if you want to do cumulative work it is probably inappropriate and it would make sense to use something like DTN.IQ. However if you are a scalper using relative V@B V@A or if timeliness is of greater concern than completeness then Zen is likely a better choice. Also consider that using 'delta' as a proxy for order flow/inventory is likely to only be around 80% accurate at best anyway.