I'm hoping Ray from NinjaTrader is monitoring this and can reply. And/or I'm hoping this forums sponsor, Trading Technologies, is monitoring this and can reply. I'm currently using NT with Zen-fire and have started experimenting with TT (Trading Technologies) to achieve lower commissions. My TT Clearing firm has informed me that the NinjaTrader implementation of TT does not support either the Brent North Sea Crude Oil contract from the ICE exchange nor the Dollar Index contract from the ICE exchange. The only ICE contract supported by NinjaTrader using the TT connection is the Russell 2000 contract. Other platforms, such as Sierra Chart's implementation of TT, do support the Brent and Dollar Index contracts from ICE. Also, NinjaTrader using other connection providers do support the Brent and Dollar Index contracts from ICE. I've contacted NinjaTrader support and they have confirmed this. So far I have not had much success approaching this problem from the NinjaTrader support side so I though I might try a more public approach here. Some background on the Brent contract for those not familiar with it. By midday, the Russell 2000 contract (TF) trades about 50,000 contracts whereas the Brent contact has traded about 200,000 contracts, typically more that NQ. The Brent crude oil price is approaching $100 per barrel. If and when it does, this already high volume will probably multiply. I realize there are other platforms other than NinjaTrader that support TT and properly support Brent and the Dollar Index. I've tried several and they donât compare to NinjaTrader 7, plus I already have a large programming commitment to the NinjaTrader platform. To me, one of NinjaTraders great strengths is it's connection flexibility however it is falling short here. What is the best way to proceed to solve this problem between NT and TT ? I have emailed TT support, but I'm not an actual direct customer to them. My clearing firm is and they aren't that fired up to tackle this problem yet. No email reply from TT yet. From where I sit, having written code in the past to several of the market api's out there, it looks like the problem is on the NT side. For some reason, perhaps it's a dot net interop thing (just guessing) NT is not able to implement, at least part of, the TT.api correctly or completely. thanks, cT
Yes, the problem is definitely on the NT side. Supposedly TT has a different API for the ICE (other than TF) instruments, and Ninja never followed through on necessary implementation and conformance. Ray looked at this for me almost two years ago, and decided he couldn't find time to do the work, especially since it required some modification of old, core code... Since Ninja 7 was their priority. Now that NT7 is gold, it'd be great if they found the time.
Well, it looks like this avenue (Elite Trader) is no helping to solve this problem. It's amazing, one of the highest volume futures contracts doesn't work in NinjaTrader when the Trading Technologies connection is used. cT
Hey charlie, How much of a difference between Zenfire and TT in comms? And what is your opinion on the difference (if any) in quality of their data?
TT basically charges the clearing firm $0.05 per side per transaction. Your broker/clearing firm will factor that into their overall commission charge. That fee, by the way, is one of the smallest inputs into the overall commission charge. I don't know what Zen-fire charges. I'm pretty sure its more. Comparing performance is a little more difficult. It is my understanding there is one Zen-fire which is operated by Dorman. However, each clearing firm that offering TT has their own implementation of TT. I believe Zen-fire's performance in consistent and my past experience has been that Zen-fire is fast and reliable. I'm still evaluating my clearing firms implementation of TT. So far so good. There are other things to consider that perhaps justifies Zen-fires higher prices. I'm guessing Zen-fire probably has a more robust redundancy that any particular TT setup. I'm also guessing, based on some experience, that Zen-fire has a faster, more responsive order desk, should and when you need it. Other issues that I've experienced using TT instead of Zen-fire involve NinjaTrader. As I'm documenting in this thread, NT with the TT connection does not support the symbols BRN and DX. NT with Zen-fire does. Also I've been having some other issues with NT/TT that I would rather not discuss here. My guess is, because of the popularity of Zen-fire, the NT/Zen-fire combination has been tested, refined and polished more that the NT/TT combination. Ideally, a trader should expect NT to have the same functionality, features, markets, performance and reliability, at the NT software level, with TT and Zen-fire. My experience, sadly has been that NT works more reliably with Zen-fire that TT. The responses that I have gotten from NT support does not give me much confidence they (NT) really care that the NT/TT combination is limited (no BRN and DX) and is less reliable that the NT/Zen-fire combination. cT
ZenFire is in reality operated by Mirus, which clears with either Dorman or RCG. ZenFire is a licensed copy of Rithmic's system. Rithmic makes their own hosted solution available with a number of other FCMs, including Vision. There were some pretty disturbing stories about ZF availability last Fall. I've had better luck with Rithmic's hosted service than ZF, to be honest. As far as comparison with TT.... TT is a much larger firm, and their solution/server is supported by basically every FCM under the sun. That probably has its pluses and minuses. On the plus side, TT's solution is going to be more "institutional". It's been around for far longer, and it's really been more tested and used than Rithmic/ZF. That's just a fact. On the minus side, I imagine it's a much larger bureaucracy, and I suspect every FCM is responsible for its own TT server configuration/setup. This means if anything actually goes wrong, you're looking at multiple layers before you get to anyone who knows what they're talking about. I'd appreciate it if you could give me some insight on the other issues you're having. I'm planning to at least have TT as a backup to my current Ninja + Rithmic platform, but am very interested in your experience.
I don't mean to be argumentative here, just conversing. I haven't done exhaustive research on this, perhaps you have. Aren't there a lot of different brokers offering Zenfire. Don't these brokers all compete with Mirus. So are the various brokers offering Rithmic all offering the same Rythmic. In other words, is there one Rythmic server or group of servers sitting out there somewhere that everyone receives quotes from and executes orders thru. In my opinion, how a particular server is run, is more important than the name of the technology - ie TT/Zenfire/Rythmic. I'm sorry, as I said above, I'd rather not discuss that here. For a backup, TT is probably plenty good. cT
I asked Ray/TT about this a while back too. ICE is not a different API. The underlying issue is that NT does not support the G1 account type and ICE requires all trades to be give-ups. Seems like a pretty trivial change on NT. I ended up writing my own app to talk to TT since I wanted access to the ICE OTC markets.
Ray has responded to me privately about this. According to Ray, myself and heech are the only two individuals on the planet who have requested any ICE support beyond TF. Though he didn't give me a specific number, he implied that several hundred folks would have to request BRN or DX for the TT connection before he would allocate any of his precious programming resources to it. Just as x_diver has said, I have started down the path of writing my own app to talk to TT to work around the current limitations and problems with NT and the TT connection. As I currently understand it, TT uses the FIX protocol to communicate with "all" the exchanges. The whole purpose of FIX is to establish a consistent communication protocol for all the exchanges. Therefore I'm currently having difficulty understanding why NT cannot fully support the ICE exchange with the TT connection. Perhaps after I get into the minutia of coding for the TT FIX adapter, I will understand. But from the spirit of the FIX protocal, I don't. cT