PDA

View Full Version : D2OL Teaking?


magnav0x
02-05-2004, 05:10 PM
Any of you guys have any tips or tricks you'd like to share to obtain optimal output from this client? Maybe using a specific JRE or SDK?
rshepard
02-05-2004, 06:22 PM
I don't know that the Java version is critical, as long as it's fairly current. I seem to recall a discussion some time back that suggeted that using Sun's Java was slightly better than using the Microsoft JVM; don't know if that's still true. I just installed the client- with-Java version, figured that way was most likely to work.

Other than that, it's mostly the stuff you'd expect-- Run it without any of the graphics enabled, either with the controller:cli option or the controller:file option. It doesn't recognize dual-procs as far as i know, so I made two installations per box.

One thing that threw me-- On linux, it wants to run at normal priority instead of idle. You can renice the Gridwin and Dockwin processes, but they'll revert to 0 when they start a new conformer. You have to start the D2OL process with the nice value you want, then the other processes will inherit the values properly.
magnav0x
02-05-2004, 06:40 PM
I'm wondering if using the Server Virtual Machine that's in the Sun 1.4.2 SDK will make it run faster like it did for DHEP. I'll test it out soon and let you know
magnav0x
02-05-2004, 08:31 PM
Not sure how this compares with others or with a normal JRE, but I went with the virtual server (1.4.2 jdk) and I completed 5 canidates in the past 50 minutes with a Athalon XP 1800. Guess I should have measured the speed previous to making the change :bang:
matrix_fan
02-05-2004, 09:48 PM
as Homer Simpson says, "doh"
rshepard
02-05-2004, 09:50 PM
After poking around in the D2OL forum a bit, I found this in the new FAQ just released:


Q: Why Java?
A: Java is only used for the front end Graphical User Interface. The docking of the candidates is done with C++.

This suggests to me that the Java version is irrelevant if the client is being run from either
the command line or in the background. It appears to me that even under those conditions
the client "spins up" the Java processes, but that they are more or less on hold until you invoke the GUI.