Ib Tws Problem??

Interested to know if anyone else has experienced the problem of IB's java workstation slowing down other applications. I'm on WIndows XP with lots of RAM, and when the workstation is open my other apps just begin to drag. Overall slow operations, even opening web pages, updating other data sources, etc.

Any solutions or possible sources of the problem would be appreciated.

 

Try this:

Download and install the latest Java Runtime Environment from Sun.

Change the target of the your TWS shortcut to the following:

"C:\Program Files\Java\j2re1.4.2_03\bin\javaw.exe" -Dsun.java2d.noddraw=true -jar C:\jts\jts.jar C:\jts

Having the latest Java RE, and using the nodraw=true option, may make a difference for you.

-- MMM

P.S. j2re1.4.2_03 should be the latest version of JRE

 

lindq
How many monitors are you running? I once had a problem similiar to what you describe and moving tws solved the problem.

 

The nodraw option should be helpful in multimonitor configurations, from what I have heard.

 

Thanks, that seems to have helped. Any idea, in simple terms, what the change accomplished?

 

You are now definitely running the latest Java environment. Previously, you might not have been, even if you had installed it, depending on where your TWS shortcut was pointing.

The nodraw option helped fix a similar problem that I was experiencing between ButtonTrader and TWS -- slow order execution.

TWS seemed to tie up a lot of CPU cycles. The nodraw option somehow speeds it up.

-- M

 

Okay, thanks for the fix. It's a good one.

 

What it does is to disable java's use of the DirectDraw API to draw on the screen, instead probably using the older/slower but more stable GDI API. There's some bug apparently with some multi-monitor video drivers in combination with DirectDraw and the way that java uses it.

 

Basically, part of the performance enhancements involved moving from java 1.3 to 1.4 involved using direct draw to output to the screen instead of the standard GDI calls. Unfortunately, neither microsoft nor javasoft seem to have tested just how poorly directx performs on the typical trader system which usually have multiple high resolution displays.

While it might be faster to write directly into the display adapter memory in a game, it turns out that having to lock multiple megabytes of display memory (the entire screen!!!) every time a cell changes in the tws grid is expensive.

Installing an up to date display driver and experimenting with the amount of hardware acceleration, and making sure that directx is up to date helps.

If you find that adding the -Dsun.java2d.noddraw=true option helps, you might try experimenting with the following flag instead:

-Dswing.volatileImageBufferEnabled=false

It only disables some of the performance "enhancements".

In the end it depends on what hardware you have installed and the quality of the drivers.