Anyone tried Java 1.6 on 64 bit OS and JTrader?
How to improve Java app efficiencies?
- Thread starter Lawrence Chan
- Start date
Anyone tried Java 1.6 on 64 bit OS and JTrader?
Cannot do that because I have other real-time apps running.
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.
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....
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.)
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.
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.
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
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