I see no real discussion on the async vs sync topic....
I suppose ... Its not really that much important...
thanks guys
I suppose ... Its not really that much important...
thanks guys
How do you handle asynchronous nature of IB API?
- Thread starter Chronos.Phenomena
- Start date
I am amazed the issue of thread management didn't surface in this discussion. It's the one aspect of HFT that really is difficult to implement and maintain.
Finally, it's really been of interest lately with the advent of multi-core processors and now video processors as well.
Very complex subject.
Finally, it's really been of interest lately with the advent of multi-core processors and now video processors as well.
Very complex subject.
Hi syswizard,
Yes â exactly. These issues belong together since they are made to use the power of current multicore CPUâs, but I do not want to 'hijack' the thread. I can only speak for the âWindows-worldâ (as I use and see it). The latest MS-compiler (VS2010) offers great functions to use more than one core without the need of Intelâs TBB or OpenMP. Itâs called the Concurrency Runtime and is part of the MSVCRT100. You can use it on XP-SP3 and later OS. If you use it in the correct environment it will give the app a great performance push. Right now I work with some people from NJ running some colocated HFT-pairs-strategies. For this reason my app uses the CR. I took also a look into the CUDA docs, but right now I have no idea in which cases the power of the graphic-cpuâs can be useful for a trading-app?
Daniel
Yes â exactly. These issues belong together since they are made to use the power of current multicore CPUâs, but I do not want to 'hijack' the thread. I can only speak for the âWindows-worldâ (as I use and see it). The latest MS-compiler (VS2010) offers great functions to use more than one core without the need of Intelâs TBB or OpenMP. Itâs called the Concurrency Runtime and is part of the MSVCRT100. You can use it on XP-SP3 and later OS. If you use it in the correct environment it will give the app a great performance push. Right now I work with some people from NJ running some colocated HFT-pairs-strategies. For this reason my app uses the CR. I took also a look into the CUDA docs, but right now I have no idea in which cases the power of the graphic-cpuâs can be useful for a trading-app?
Daniel
Me too. I was also expecting a discussion on high level applicstion design.... Anyway
Just curious, why not use the NinjaTrader API? I"m not a troll nor am I marketing for them. But I do use the platform, and I see it as a convenient layer for sitting on top of IB's API so I don't need to deal with these issues.
The API is still event-driven for order, but simplifies your workload substantially. I'm interested in hearing the devil's advocate argument against it, thanks.
The API is still event-driven for order, but simplifies your workload substantially. I'm interested in hearing the devil's advocate argument against it, thanks.
Ninja's architecture has not passed the "test" IMHO.
It's taken them more than 24 months to get version 7.0 to production status. One must ask this question: Why ?
Ninja must look at mature programmable platforms like Tradestation to learn all of the required "features" for a robust auto-trading platform. The fact they missed built-in circular buffers was just such a "tell".
One comparison was done for a strategy:
Tradestation+Easylanguage: 50 lines of code
Ninja 6.5+C#: over 500 lines of code.
Case closed.
Never considered... In fairness never heard that ninja supports API....
Are there some Apis for IB on higher level than order.... I.E. positions... All I need is open position, close position so start with... The higher level API should take care of orders... My idea is then to have positions of baskets of instruments... But same should apply here... I do not want to care about order level events... Only positions
Thoughts?
Are there some Apis for IB on higher level than order.... I.E. positions... All I need is open position, close position so start with... The higher level API should take care of orders... My idea is then to have positions of baskets of instruments... But same should apply here... I do not want to care about order level events... Only positions
Thoughts?
syswizard,
Thanks for your thoughts. Not looking to change any minds, just wondering what others were thinking on this topic.
I haven't migrated over to Ninja 7.0 for precisely the reasons that you stated. I'm using Ninja 6.5 still, and I have to say it's working pretty reliable for me. There are still occasional race conditions in their API which leads to wrong quantities on orders... but it's 99.95% very good.
I for one also like the multi-broker support. If you're trading equities, your code transfers over with minimal effort to TDA. If you're trading futures, same is true when moving over to ZenFire/Rithmic/TT. I've done that transition multiple times over the last 2-3 years.
Chronos,
I only use NT for the API. I don't use any of their DOM/charting/trading front end.
Thanks for your thoughts. Not looking to change any minds, just wondering what others were thinking on this topic.
I haven't migrated over to Ninja 7.0 for precisely the reasons that you stated. I'm using Ninja 6.5 still, and I have to say it's working pretty reliable for me. There are still occasional race conditions in their API which leads to wrong quantities on orders... but it's 99.95% very good.
I for one also like the multi-broker support. If you're trading equities, your code transfers over with minimal effort to TDA. If you're trading futures, same is true when moving over to ZenFire/Rithmic/TT. I've done that transition multiple times over the last 2-3 years.
Chronos,
I only use NT for the API. I don't use any of their DOM/charting/trading front end.
Maestro,
Can you be a little bit more specific? I have No expirience with fix?
Thanks
Can you be a little bit more specific? I have No expirience with fix?
Thanks