Software/Hardware needed to trade after the FOMC

Hoi · Feb 5, 2006

IB-feed is build for after FOMC events ! It's extremely efficient while only snapshots and only field-modifications are sent...other-vendors (like eSignal) will very soon lack more than 10 seconds during events like FOMC.
BUT.....IB spoils it all by how TWS processes all this info to the screen...especially drawing routines are designed all wrong...instead of drawing only the modified field in the ticker-page or drawing only the changed bar in the Chart, it draws the WHOLE page and that tens of times per second (during FOMC)...that is the cause of taking 100% CPU..and I have reported it many times to IB-programming that they should redesign their drawing processes (but they don't want to listen..which is a pity because all effort that they put in their great design of an efficient IP-transport is spoilt on the client's PC by drawing it to the screen).

Just minimize TWS to the task bar and see what the huge effect is in task-manager....CPU drops miraculously from 90-100% to 5% only (or less)...and this is what I had to advise to all clients of ButtonTrader >> minimize TWS and you will have an extremely fast system (because ButtonTrader does draw only the fields that are really modified, and uses thereby only 10% for the same data-feed and same presentation).

steve46 · Feb 5, 2006

Robert:

Have you looked into CQG or DTN? I would be interested in your view of the quality of these offerings.

Thanks
Steve

Hoi · Feb 5, 2006

Quote from steve46:

Robert:

Have you looked into CQG or DTN? I would be interested in your view of the quality of these offerings.

Thanks
Steve

Nope...all my time goes to IB...But as far as I know is IB the only snapshot-provider, and is thereby always faster than streaming-providers.
For charting and Time&Sales you need a streaming-provider, for fast scalping during FOMC-events you need a snapshot-provider >> best of both worlds could be made by IB (which is moving towards this).

Moreagr · Feb 5, 2006

I hate to say this but IB's data is lighting fast i have IB and dtn side by side and ib is faster or the same for no charge.

dtn may have more breath tickers but its not cheap if you have to pay alot of exchage fees and want more then equities.

dcraig · Feb 5, 2006

Quote from Hoi:

IB-feed is build for after FOMC events ! It's extremely efficient while only snapshots and only field-modifications are sent...other-vendors (like eSignal) will very soon lack more than 10 seconds during events like FOMC.
BUT.....IB spoils it all by how TWS processes all this info to the screen...especially drawing routines are designed all wrong...instead of drawing only the modified field in the ticker-page or drawing only the changed bar in the Chart, it draws the WHOLE page and that tens of times per second (during FOMC)...that is the cause of taking 100% CPU..and I have reported it many times to IB-programming that they should redesign their drawing processes (but they don't want to listen..which is a pity because all effort that they put in their great design of an efficient IP-transport is spoilt on the client's PC by drawing it to the screen).

Just minimize TWS to the task bar and see what the huge effect is in task-manager....CPU drops miraculously from 90-100% to 5% only (or less)...and this is what I had to advise to all clients of ButtonTrader >> minimize TWS and you will have an extremely fast system (because ButtonTrader does draw only the fields that are really modified, and uses thereby only 10% for the same data-feed and same presentation).

Hoi,

You are definately right about the charts. They should put some work into looking at performance. It's possible to get much better performance from the JFreeChart library. I'm not going into the details here, but I manage to be able to run 50+ real time charts using JFreeChart with my own application without killing system performance.

Are you absolutely certain about what you say about the ticker page ? What do IB support have to say about this ? If this is the case, I'm a bit shocked as it is very easy in Java to just have the changed table cells repainted.

Hoi · Feb 5, 2006

Quote from dcraig:

Are you absolutely certain about what you say about the ticker page ? What do IB support have to say about this ? If this is the case, I'm a bit shocked as it is very easy in Java to just have the changed table cells repainted.

In the past years, I have complained (at IB-programming) about the page-drawing many times (especially because my clients got problems using the API when CPU reaches 90%)...and explained my finding with the hypothesis above (which was not denied nor admitted (so hypothesis is not rejected)).
Further I can very easily compare the ticker-page-drawing: ButtonTrader show exactly the same ticker-pages as TWS. When I put the two side by side on the monitor I can measure with taskmanager the CPU-load, when subsequently minimizing one or the other. This shows huge differences (although, the differences were substantially higher some time ago, so I guess something is done).

I don't know anything of Java-drawing, but the fact that the directdraw-switch should be off (otherwise results are even more shocking), tells me that the procedures used, are not efficient enough for real-time drawing. I have build the drawing-routines in ButtonTrader by myself, and I'm 100% sure that only pixels of the bitmap of one modified field are transported directly to the screen (faster is not possible). This low level drawing is needed for real-time presentations in a highly efficient way.

originalskunk · Feb 5, 2006

Quote from dcraig:

Are you absolutely certain about what you say about the ticker page ? What do IB support have to say about this ? If this is the case, I'm a bit shocked as it is very easy in Java to just have the changed table cells repainted.

Its actually not that easy to write a general purpose updater that scales well. This article is a little dated

http://java.sun.com/products/jfc/tsc/articles/ChristmasTree/

but describes the problems and tradeoffs very well.

j_medved · Feb 5, 2006

Quote from originalskunk:

Its actually not that easy to write a general purpose updater that scales well.

Which is why you shouldn't use a general purpose updater. Write one specifically tuned to your needs. Takes longer, but performance is better.

dcraig · Feb 5, 2006

Quote from originalskunk:

Its actually not that easy to write a general purpose updater that scales well. This article is a little dated

http://java.sun.com/products/jfc/tsc/articles/ChristmasTree/

but describes the problems and tradeoffs very well.

By coincidence I read that article just a couple of days ago. I understand at least some of the issues. What hoi was saying was that he believes that the whole table rather than individual cells is being unnecessarily repainted. On thinking about it a bit more I think thats probably not the case.

alanm · Feb 6, 2006

Quote from dcraig:
You are definately right about the charts. They should put some work into looking at performance. It's possible to get much better performance from the JFreeChart library. I'm not going into the details here, but I manage to be able to run 50+ real time charts using JFreeChart with my own application without killing system performance.

Would you be willing to give IB some guidance about this? I think I recall that they tweaked the library some for performance, but it hasn't seemed to have helped much. I know that all IB users would thank you.