A ran a quick timing test comparing 32 bit and 64 bit Java 1.6 (running on Ubuntu 64 bit) on some of my own code that implements a trading system genetic optimizer. There was little difference between the two. As with all performance testing caution is needed in interpreting results. I suspect that the performance of this code is heavily dependant on memory/L 2 cache performance of the hardware. 32 or 64 bit is not going to change that, so the result might have been anticipated. Your mileage will vary.
First make absolutely sure that the lag in the application isnt actually due to the feed from the linked server and the bottleneck which is in many cases the IP/internet connection. check those settings and parameters first Next I would strongly suggest before you throw any money at anything to simply do the following.. update to Java 1.6 and clean the registry, especially if your a windows user (32bit) followed by a complete scan of the system using heavy duty scanners like AVG anti-spyweare and the new PC-cillin (not the old) or Adware 2007. (I was surprised to find infections and malware in the registry missed by my existing tools and clearing that up removed all slow Java issues) Lastly, you may need to throw money at the problem in the way of more memory first.... and lastly a new motherboard and dual-core CPUs to run winx64.. because Java applications scale wonderfully with increased CPU power. My experience has shown me though that sometimes the lag isnt actually the software.. its the feed that is lagging or became interrupted and so the app appears to hang waiting to resolve the datastream/reconnect just my 2-ticks....
Youse guys are 'way over my head, but perhaps this is the place (time) to post a question about TWS and time lag. First of all, I use TWS with Booktrader. (I expect to go to NinjaTrader before Christmas). Trader work station has a time indicator at the lower right of the trading screen. It lags my motherboard clock from 12 to 44 seconds, probably about 15-20 most of the time. The clock display is driven by "Clock Tray Skins" ( www.drive-software.com ) which is calibrated from some atomic clock somewhere, somehow. Obviously 15 seconds is an eternity when scalping a symbol with a 45 second round trip cycle. Should I expect better that 15 seconds, and since I am not at 100% CPU cycles, where is the biggest bang for the buck? I've already upgraded to Java 1.6 (Running XP Pro on 1.3 Ghz MB w/eide drives and 1 gig memory.)
Here's how I run TWS, using both Java 6 and the "server vm". Since the "server vm" is not distributed with the client JRE from Sun, its installation is "special". You are unlikely to need anything more than the standard "client vm". IF you wanted to use the server vm (which you CANNOT do without special installation, then "-client" would be replaced by "-server" when the server vm is used, but this file could be used by anyone with the standard client vm to run TWS, rather than the shortcut which is supplied in the installation: My advice: use the standard "client vm" and don't think you're missing anything. This .bat file is located in c:\jts\runtws.bat on my system. The TWS shortcut is changed to "c:\jts\runtws.bat" The contents are: c:\WINDOWS\system32\java.exe -client -Xbatch -Xss128k -Xms174m -Xmx174m -Xnoclassgc -XX:+ForceTimeHighResolution -XX:CompileThreshold=50 -XX:CICompilerCount=2 -XX:ThreadStackSize=128 -XX:+AggressiveOpts -cp jts.jar;pluginsupport.jar;jcommon-1.0.0.jar;jfreechart-1.0.0.jar;jhall.jar;other.jar;rss.jar jclient/LoginFrame c:\jts ALL ON A SINGLE COMMAND LINE; EMAIL FOR A .BAT FILE IF YOU WANT. Standalone TWS is assumed, and Java JRE 6 or higher is assumed. On each TWS upgrade, simply replace their shortcut by the one shown above. Items to note: 1) ms and mx 174m parameters fix the min and max java "heap" size to 174 megabytes. These can be tweaked but should be set at a fixed size. 2) CompileThreshold forces the HotSpot compiler to compile more java code into machine code when only 50 interations are met. This take a bit longer to "warm up" and uses more memory, but is overall faster. I"m something of a performance freak so I run both TWS and my Java platform under the Java Server VM. This is not appropriate, nor necessary for the ordinary user. I am often running 5 Java processes flat out, so I need the scalability. You almost certainly do not need the server vm. Another thing: On Windows XP, using the Java 6 runtime, the DirectX system is used by default. You may note that TWS shortcut sets disables DirectX, because they do not know whether you have a Java 6 VM. This is the first VM on which DirectX works normally. A parameter in the TWS shortcut may say: -Dsun.java2d.noddraw=true THIS MEANS DO NOT USE DIRECT DRAW (DIRECTX) IF, AND ONLY IF, YOU HAVE A JAVA 6 VM, you may set this to false, or simply remove it altogether, so your screen updates may use DirectX for higher performance. So although you may be running Java 6 which, at this writing is not technically supported by TWS development; nevertheless it works fine. It will be using DirectX for more efficient screen updates, unless it is inhibited by noddraw=true. In that case, set noddraw=false TO ALLOW DIRECTX Garbage collection: It is more efficient if it is NOT incremental, but garbage IS collected only when heap is becoming full. Also, the compiler is more efficient compiling Java code to Machine code when it does it as a "batch" operation, rather than concurrently. Anyway, anybody wants to know a bit more there's lots of info on the net, and advanced usage of the server vm is something I might explain by email. FS.
Thanks for sharing FutureScalper! I will test the bat file tomorrow. What have you done in the way of connecting to IB? Are you using DSL? What is round trip ping to IB's servers? Have you been able to improve the default in that regard? Thanks again,
stupid question... will I notice any difference in upgrading to java 1.6 vs 1.5 running TWS. TWS is very slow IMHO I am not sure if it will make it faster... especially when I try to bring up a chart...amn is it slow
A well tuned Java system is very fast. Here are my timings. My raw ping times are about 40 msec round trip NC to ib's gw1.ibllc.com servers. Bumping a live futures limit order on Globex is 120 msec round trip via API client and TWS. That's end-to-end acknowledgement precisely measured by the API client via TWS, so it has to originate in the front-end, through TWS, down the wire and back, to TWS and back to the API client. If ping time is 40msec, then "processing" is 80 msec to bump a live order = 120 msec round trip messaging. I submit that is pretty good for standard DSL, and a system which is not particularly high performance. I don't have multiple procesors or anything exotic. Single Pentium 2.266 mhz; and 1.5 gigabytes RAM, 4 screens, running Windows XP with NO pagefile (RAM only). Front end runs more than 70 threads in each process. 3 front-end instances socket connected to TWS running flat out usually all day long. This extreme performance requirement is the only reason I use the Java Hotspot "server vm". So, when you say TWS is "slow" do you mean 1) slow starting up? or 2) slow and unresponsive when actually running? I can assure you that a well-tuned system is not "slow" but there are many factors affecting a given system's performance. I suggest you do NOT elevate TWS prioroty to Realtime, nor High, but simply "AboveNormal". Ensure your system is well-tuned. FS
Have you looked at ZenFire as an alternative? It seems to be the next step to getting the last bit of performance out of a dsl connection. Are there any other front ends you have looked at that you could consider using? Thanks again!