Discussion in 'Automated Trading' started by Maharaja, Nov 3, 2009.

  1. Working with the TWS API in java I have noticed that my processing of market data in making a trading decision is fairly quick (few millis). But actually creating an IB order and placing it is taking much longer, around 3-20 millis. Has anyone experienced this type of behavior? What I mean is instantiating a new Order object and then sending the order in via EClientSocket is taking a long time. How can this be sped up? Can it be sped up?

    Also, does anyone have any suggestions as to how to increase performance of both the trader workstation and custom application that makes use of the TWS API? Are there any jvm settings that can be made that optimize performance? Any specific linux settings or networking settings that can help with performance?

    I've been playing around with the "nice"-ness (in linux) of the two applications but I haven't really measured the performance gains. I just assumed there would be... :)

    On another note, how fast is the IB market data compared to other vendors? How does the latency compare?

    Thanks in advance for any suggestions...
  2. Hi Maharaja,

    I have not recognized any new lag in speed of the TWS, but I use C++ to access the TWS interface. To speed up the over-all-performance I have put the complete communication from and to the TWS in a separate thread with non-blocking read and write access to the socket. This turns out to be the right way since I never run into any speed problems related to the interface to the TWS. Since IB provides only 'snapshots' of the market the latency is not a big issue. The number of quotes to transfer will not increase that much as it does for other providers in fast markets.

  3. I think you misunderstand what nice is intended to do. It really means "be nice to others". ie if you have a process that is hogging CPU increase the nice value so that other processes get more of a fair go.

    As for Java performance, you might try a server JVM. I think that they are more inclined to do the JIT thing after fewer code iterations than the workstation variant. Garbage collection is significantly different though.

    In any case does 10ms really make much of a difference? It is likely to be swamped by internet latencies, broker latencies (margin checking, order routing etc) and exchange processing etc.
  4. rwk


  5. Is this what you are talking about?


    "If an API application intends to make historical data requests that return more than 1000 bars, it is recommended that TWS be configured to increase the sizes of the API socket buffer. This can be done in the "tws.xml” file in the user’s Jts directory. It is important that TWS not be running when its tws.xml file is manually modified. In the XML element, the elements can be used for this purpose. Modifying that entry in the element in tws.xml ..."
  6. rwk


  7. From "info nice":

    "A niceness should not be confused with a scheduling priority, which lets applications determine the order in which threads are scheduled to run. Unlike a priority, a niceness is merely advice to the scheduler, which the scheduler is free to ignore."

    I guess it doesn't hurt to turn the nice value negative through right?

    I can try the server thing and maybe even experiment with some GC settings.

    The funny thing is you are right. 10ms doesn't make a huge difference, it's merely an obsession thing. I want the program to be the best I can make it, nothing less.
  8. Is there a configuration or setting somewhere to dictate the snapshot frequency? Do you know where IB describes the details of how it is taking and forwarding these snapshots on through the API?
  9. There is no setting - you have to take what they give.
  10. If I might ask, what editors are available to edit that xml file?
    #10     Nov 4, 2009