Open source Auto Trading for IB TWS

Discussion in 'Automated Trading' started by james2hunt, Dec 18, 2012.

  1. Here's the latest update to this open source platform. 2.8_08 with new video's and blog. Scroll down the home page to see screen shots. App handles Stocks/Forex/Commodities.

    James :)
  2. Interesting. Any developers on ET who works on Trade-manager?
    please PM me.
  3. Not this latest update, but i have tried the previous one.
    it is some sincere hard work. Though the product is far from a finished product.
    (no offense please.)

    I am not sure what your goals are, as this is a open source product.
    It is java on windows right?

    I would consider joint development if there is anything like c++ on linux.

    anyway, I think this thread (as well the product) is some sincere hard work. unfortunately, no replies of fellow traders. if you post about moving average strategy and how to make million based on that, you will get thousand replies.

    suggestions if I may:

    1. add functionality as COM interface, so plugins in C++ or other languages should be possible.
    2. multi threading support in the program for backtesting or real time scanning.
    3. ability to work on tick data (real time streaming) and should be able to start a new thread for a single strategy/single instrument. e.g. strategy based on markov.

    PM me if you want to discuss it in private.
  4. Please read the Home page. Its Java and has been tested on Linux and Windows.

    All strategies, data, app run their own threads i.e. there is a data thread, a thread for indicators, each strategy is running in its own thread, then the app is running as the main thread.

    This applies to live and back testing. Back testing is throttle to a max of 3o+ threads through the use of SwingWorker (has a thread stack of 10 so 10 back testers run concurrently + upt0 20 strategies + main + aux swing threads) this keeps the DB load in check max 50 connections.

    If you want to use C++ just create a JNI interface that calls the Abstract Strategy Class (all Strategies inherit from this class).

  5. tzheng


    I appreciate your work very much. Seems to be working, and with some decent capability. Wonder why this did not get more attention.
  6. hftvol


    which thread manager are you running in Java? I am asking because obviously you do not have sufficient threads to handle a number strategies, indicators, each on its own thread. In the end you are still subject to scheduling. I wonder how you handle that part?

  7. For back testing I do throttle the threads using the SwingWorker that limits threads to 10 so the Whole app is runing around 25 total threads when back testing.

    When trading live the threads are not limited. So if you are trading 10 symbols app is running a thread for each strategy, the main thread, 10 more for the indicators and a few for DB connection pools, timers e.t.c .e.t.c so not to many.

    I've tried running some back tests on different hardware and found when I run on a 3MHz dual cpu with no DB it takes 1400 seconds to run 2000+ strategies if I run the same test on an i7 cpu machine its 10X faster.

    Note performance is not an issue as this app is designed for strategies that are based on 1 minute bars and up. Hence the use of JFreeCharts e.t.c

    Release 2.11 now supports FA account Groups/Profile & orders.

    I am working on a new UI that will remove swing and use Java FX. (Swing replacement) so UI will be supper fast.

  8. hftvol


    you do not have more than 8 threads at your disposal unless you run on a duo CPU machine. What you mean is that you schedule your work to be run concurrently among the 8 or so threads your system has at its disposal.

  9. Does anyone still have a single cpu pc ? anyone who is a serious trader well anyone really is running multi cpu machine usually 4-8.

    Thread limitation is becoming a mute point. That coupled with the use of SSD drives has made performance a thing of the past.

    As I'm not trading on timeframes < 1min performance not an issue. Software developers these days focus more on comms/DB issues where performance is still an issue but usually outside the control of the developer.

    i.e. nothing I can do about the speed of my network connection or that latency of MQue on IB servers and my SQL is well tuned.

    I have tuned the code and see no blocked threads or objects not getting gc. Big one here are the collections hanging onto objects.

    With UI updates (charts and observable table fields) limited to 5sec. Paint of graphics not an issue. But Java FX will greatly improve this.

    #10     Mar 8, 2013