is rolling your own not an option? i think a 3rd party solution may get you there in the short term, but in the long run there will always be something frustrating that you won't have much control over. when you start to really push your automation, you'll find control and understanding every inch of your code base becomes less of a feature and more of a requirement. from what i've seen, fault tolerance, redundancy, and endless failsafe's rarely make it on the list of features for auto-trade platforms - open or closed source. at a certain size, relying on a non-invested third party to hopefully have taken care of those things for you is one of the biggest underestimations of risk an auto trader can make.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Marketcetera
- Thread starter bluelou
- Start date
propseeker,
Did you write both execution and simulation capabilities on your own? Or, did you use a broker API to get execution only? If so, what are you doing for backtesting/simulation?
Regarding the use of a broker's API, should I anticipate limitations regarding the # of instruments that I'm running or does this somehow become a non-issue? What other limitations should I be aware of?
Did you write both execution and simulation capabilities on your own? Or, did you use a broker API to get execution only? If so, what are you doing for backtesting/simulation?
Regarding the use of a broker's API, should I anticipate limitations regarding the # of instruments that I'm running or does this somehow become a non-issue? What other limitations should I be aware of?
Quote from propseeker:
is rolling your own not an option? i think a 3rd party solution may get you there in the short term, but in the long run there will always be something frustrating that you won't have much control over. when you start to really push your automation, you'll find control and understanding every inch of your code base becomes less of a feature and more of a requirement. from what i've seen, fault tolerance, redundancy, and endless failsafe's rarely make it on the list of features for auto-trade platforms - open or closed source. at a certain size, relying on a non-invested third party to hopefully have taken care of those things for you is one of the biggest underestimations of risk an auto trader can make.
And of course, you're right. if we write it ourselves we have more control. But, nowadays I always look at anything open source first.
Interestingly, you're right about most systems. You hit the nail on the head!
It's because they go after the most sales so they seek to provide so many features to please everybody which means tons of work on discretionary features since they're the biggest market and automation is MUCH smaller user base so it gets less attention.
Interestingly, tickzoom has zero discretionary features. It only does automated trading and historical testing. And all that sensitive logic that you refer to is open source in tickzoom--the part that connects (and reconnects) to the broker.
So you can carefully check fix or change any of that logic.
Why start from scratch when there's good open source?
In fact, TZ's open source is LGPL so you could even take their broker connection to MB TRading (if you use that broker) and I guess do the rest yourself. But might as well use the other open source if it's good. Why reinvent the wheel?
Still, I highly recommend spending the next 6 to 9 months of your life writing your own system.
In the end you'll like it better than anything else out there.
Quote from bluelou:
propseeker,
Did you write both execution and simulation capabilities on your own? Or, did you use a broker API to get execution only? If so, what are you doing for backtesting/simulation?
Regarding the use of a broker's API, should I anticipate limitations regarding the # of instruments that I'm running or does this somehow become a non-issue? What other limitations should I be aware of?
May I chime in too?
The brokers APIs allows you to use any of the instruments they trade.
You just have all the complexity of trading orders.
So when you want to change a limit or stop, you have to cancel the previous one, get the confirmation for it and create the new order.
You have to handle the weird situation when the broker fills your order only partially.
It seems, but not sure, that TZ already handles all that logic in open source code.
Tradelink might have something that helps with it.
I wish there were Java trading project in open source, but I can't find any good ones anywhere.
TL and TZ seem the only good open source options for platforms. There's lots of C++ and C# libraries and stuff around.
Quote from bluelou:
propseeker,
Did you write both execution and simulation capabilities on your own? Or, did you use a broker API to get execution only? If so, what are you doing for backtesting/simulation?
Regarding the use of a broker's API, should I anticipate limitations regarding the # of instruments that I'm running or does this somehow become a non-issue? What other limitations should I be aware of?
yes, i've written both execution and simulation... don't forget data, that's important too.
the number of symbols in and of itself won't be a problem for most brokers, but as a result of running many symbols your order frequency and messages per second can cause major problems. most will either bump you or throttle you. those who don't and don't have the infrastructure to support you will experience the thrill of their mission critical client server go down at the worst time (don't ask me how i know). other limitations? there are too many to list... from 0 ack disconnects, to server downtime, data issues/errors, reg sho auto-handling (or lack thereof), poor risk control, ad infinitum. its cost me low 6 figures a year handling these limitations in real-time and i honestly feel lucky it doesn't cost me more.
so, to answer chaos' question why i don't use open source for trading applications... because when things go wrong (and they will), i like to have some idea of where the problem may lie, and if i wrote every line, i'll have a very good idea. only way i'll use opensource is as someone mentioned at the beginning of the thread, for ideas. otherwise, the entire design must be considered, the structure understood, every line gone over and stress tested and if not then it's a trust gamble. and if i'm going to do a trust gamble with mission critical code... you can bet that dev is going to be VERY well compensated, and there's going to be MAJOR accountability. there's enough chance in trading, this is one area i try and eliminate any i can find.
Quote from propseeker:
yes, i've written both execution and simulation... don't forget data, that's important too.
the number of symbols in and of itself won't be a problem for most brokers, but as a result of running many symbols your order frequency and messages per second can cause major problems. most will either bump you or throttle you. those who don't and don't have the infrastructure to support you will experience the thrill of their mission critical client server go down at the worst time (don't ask me how i know). other limitations? there are too many to list... from 0 ack disconnects, to server downtime, data issues/errors, reg sho auto-handling (or lack thereof), poor risk control, ad infinitum. its cost me low 6 figures a year handling these limitations in real-time and i honestly feel lucky it doesn't cost me more.
so, to answer chaos' question why i don't use open source for trading applications... because when things go wrong (and they will), i like to have some idea of where the problem may lie, and if i wrote every line, i'll have a very good idea. only way i'll use opensource is as someone mentioned at the beginning of the thread, for ideas. otherwise, the entire design must be considered, the structure understood, every line gone over and stress tested and if not then it's a trust gamble. and if i'm going to do a trust gamble with mission critical code... you can bet that dev is going to be VERY well compensated, and there's going to be MAJOR accountability. there's enough chance in trading, this is one area i try and eliminate any i can find.
Wow. You obviously trade a lot of volume. Thanks for sharing your experience!
The fundamental problem you're facing in this industry is secrecy. It seems sad but bloke after bloke writes their own entire system. It's understandable but such a waste reinventing the wheel.
It seems like a small team of automated traders could ban together and pool their resources.
But many sincerely fear sharing their work with competition even beyond the standard NIH attitude.
The hard fact is that anyone who is trading is competing against all the rest. Everyone can't profit from trading.
That makes it difficult to achieve the power of synergy that comes from cooperation.
yes, those points are dead on, especially the conclusion. case in point, i know some very talented autotraders and we've attempted on more than one occasion to try and collaborate development-wise as a group and have never gotten anywhere. the disparities between project goals and contributions is too great when working in a group of any size that either the result is something not exactly what you wanted or there's some sort of subsidy going on that doesn't feel right. 2 person collaborations have worked when there's some equal ground, but outside of that it just gets too lobsided. almost always, open discussion and single implementation is the most efficient model. because the fact of the matter is, in autotrading the architecture is an edge in and of itself, and at the end of the day, i would argue, if done right, THE most important edge you have.
Quote from propseeker:
yes, those points are dead on, especially the conclusion. case in point, i know some very talented autotraders and we've attempted on more than one occasion to try and collaborate development-wise as a group and have never gotten anywhere. the disparities between project goals and contributions is too great when working in a group of any size that either the result is something not exactly what you wanted or there's some sort of subsidy going on that doesn't feel right. 2 person collaborations have worked when there's some equal ground, but outside of that it just gets too lobsided. almost always, open discussion and single implementation is the most efficient model. because the fact of the matter is, in autotrading the architecture is an edge in and of itself, and at the end of the day, i would argue, if done right, THE most important edge you have.
Wow. You see it clearly. It seems that's why the tick zoom folks are restricting access to outsiders. They decided the architecture itself is too powerful to share.
And that's great for all the other platforms since that means another competitor for the retail market is out of the way.
Quote from propseeker:
because the fact of the matter is, in autotrading the architecture is an edge in and of itself, and at the end of the day, i would argue, if done right, THE most important edge you have.
I think it is the first time I have seen anyone openly claim this. And I agree completely. Besides your imagination basically the only thing that limits the possible types of strategies you can execute is the underlying framework (along with the rest of your infrastructure).
At some point it can also be hard to tell where the framework stops and the strategies starts, since in my experience, this is a very iterative process where new trading ideas demands new features in the framework which again sparks new trading ideas.
Quote from chaostheory:
May I chime in too?
The brokers APIs allows you to use any of the instruments they trade.
You just have all the complexity of trading orders.
So when you want to change a limit or stop, you have to cancel the previous one, get the confirmation for it and create the new order.
You have to handle the weird situation when the broker fills your order only partially.
It seems, but not sure, that TZ already handles all that logic in open source code.
Tradelink might have something that helps with it.
I wish there were Java trading project in open source, but I can't find any good ones anywhere.
TL and TZ seem the only good open source options for platforms. There's lots of C++ and C# libraries and stuff around.
http://groups.google.com/group/jsystemtrader