User talk:Bwbaugh

From Robowiki
Jump to navigation Jump to search


Question: Number of Client Instances

If I have computers that are multicore (some dual some quad), is there a way to safely run multiple instances of the RoboRumble client without causing skipped turns? Would I need to set the affinity of each instance to separate CPUs? I'm a bit new to this, and my parallel computing class doesn't start until the Fall. =) --bwbaugh 10:05, 8 June 2011 (UTC)

Welcome to the wiki, glad you are contributing to the rumble =) If you're worried about causing skipped turns first open up robocode and reset the CPU constant, then close robocode and open up the config/ file with notepad. Manually increase the CPU constant there to something you feel would account for anything like cache thrashing, possible external logins etc (I'd say just double it...) and save the file. Make sure you run each instance of roborumble from a different install, otherwise there will be issues with all of them saving to or uploading from the same file concurrently. Hope this helps! --Skilgannon 10:28, 8 June 2011 (UTC)

Personally, in addition to boosting the CPU constant, I prefer to run one fewer robocode instance than the number of CPUs on the system. This is because robocode seems to use some processor power outside it's handling it a separate thread than the robots run in (perhaps the Java GC? Perhaps part of the robocode engine itself? I'm not sure). About setting affinity, I doubt it would make much difference. Robocode is already alternating between running each robot, which I'd expect to limit how long-lived things are in the cpu cache, which I'd expect to mean that affinity probably wouldn't help much. That's just a guess though, it's not like I've tested. --Rednaxela 13:57, 8 June 2011 (UTC)

Agree with everything these guys said. About the affinity, I think this may depend on OS. I know on Mac, and I think on Linux, it will just work running one instance per core. I recall some people on Windows (XP days?) having to set affinity. FYI, RoboResearch is a great tool to leverage multiple cores for development. And yes, welcome and great to see you already contributing to the rumble. :-) Good luck! --Voidious 14:33, 8 June 2011 (UTC)

I personally used to run two RoboRumble clients (1v1 and melee) on Dual Core machine (Core 2 Duo P8400 2.26GHz) with about 1.1x increased cpu constants without trouble (I've checked the result on the server). I have also run two RoboRumble clients (1v1 and melee) on my Core 2 Quad 2.4GHz server without increased cpu constants without any trouble too. (but my server do esnot do anything other than consuming power when not explicitly used, it host my class' online judge system) --Nat Pavasant 14:40, 8 June 2011 (UTC)

Thank you all for the replies and information! I went ahead and configured 40 of my workstations to run 2 instances of RoboRumble each. Unfortunately, I noticed that after processing the battles, the upload process was much slower than it was during the past two days. In addition, the web interface for the rumble server was very slow to respond. So, it appears that the rumble server can't accept that many connections / uploads at once. I therefore reduced the number of stations running from 40 to 22, still running 2 instances each, and may reduce it further if it still seems to be overloading the rumble server. I wonder if there is a way to scale up the server to accept more simultaneous uploads... --bwbaugh 15:20, 8 June 2011 (UTC)

Holy cow. In one or two nights, you've managed to contribute more power than just about everyone one else this year. Wow and thanks! --Miked0801 15:31, 8 June 2011 (UTC)

You're welcome! Though, I am missing a small number of bots due to the Robocode Repository currently being inaccessible. Maybe I'll have to get a copy of the bots I'm missing from one of you sometime. =) --bwbaugh 15:44, 8 June 2011 (UTC)
I zipped up all the bots in my RoboRumble dir recently, it probably has whatever you're missing: (69 MB). It also has lots of versions of lots of bots, so I'd just cherry pick what you need. --Voidious 17:58, 8 June 2011 (UTC)
Thanks! Got the 18 bots I was missing. I'll have to re-package the distro that I use tomorrow. About to turn off the farm for the night. --bwbaugh 04:48, 9 June 2011 (UTC)

Here I set above normal priority (START /WAIT /B /ABOVENORMAL java ...) to protect the client instance from being affected by other processes. Also running 1 fewer client than the amount of cores. --MN 13:02, 11 January 2012 (UTC)

Genetic Algorithms

Does anyone have experience with genetic algorithms and robocode, whether it be RobocodeJGAP or otherwise? As you can see from the RoboRumble contributors list, I have quite a bit of processing power available, and was curious if I could use that to my advantage. I tried downloading the JGAP but could not get it to run (gave an error about not being able to compile the generated file), and no matter what security policy permissions I tried giving to it, it did not want to run. There was also mention on their website about the future possibility of using a grid. Obviously any sort of distributed computing would be a big plus, but not a requirement. Thanks for any pointers in the right direction! --bwbaugh 11:04, 12 June 2011 (UTC)

RobocodeJGAP is largely outdated. I believe you could perform the same thing via Robocode API. There is an article about genetic algorithm here: [1], but it didn't speak of the integration with Robocode API. ---Nat Pavasant 14:28, 12 June 2011 (UTC)

I have worked with genetic algorithms a bit recently, but only with WaveSim to evaluate fitness, not directly with Robocode. I wrote a small framework to do the GA stuff instead of using JGAP or another existing framework. I could share that if you want, but need to get permission from work first (signed over my soul, etc, but should be np). You might be thinking Genetic Programming, though - evolving code for a robot, as opposed to evolving a bit string that's interpreted by other code. And yes, my mouth waters a bit with the thought of all that CPU power for my GA runs. =) --Voidious 16:19, 12 June 2011 (UTC)

With the way LBB works, it could really use this kind of power to work through all its possible string combinations :) --Miked0801 17:17, 12 June 2011 (UTC)


Thread titleRepliesLast modified
Battle Farm Active (for the next 12.5 hours)623:15, 15 January 2012
Melee Battle Farm Active (for the next 16 hours)302:28, 12 January 2012
Lots of 'Could not load robot' Errors217:55, 3 November 2011

Battle Farm Active (for the next 12.5 hours)

For those that might want to be active with submissions to the roborumble, I'm currently running 1v1 battles for the next 12.5 hours (until 6:00 AM CST 1/11/2012). The current rate appears to be about 840 battles per minute, so you'll likely be able to make a couple of submissions. (Note it may a little time for newly added bots to be downloaded).

bwbaugh01:32, 11 January 2012

Could you contribute a bit of that huge CPU power to meleerumble? It is the slowest league to stabilize, taking about 2 days with me alone contributing.

MN14:22, 11 January 2012

Sure! I think there will be some free time today that can be used for the melee.

bwbaugh18:05, 11 January 2012

Wow, my bot jumped from 7k battles to 13k... now APS is matching the PL rank.

MN02:34, 12 January 2012

Unfortunately, I´ll only have time to improve my bot again in the weekend.

MN02:37, 12 January 2012

Melee active till 6:00 AM Mon 1/16/2012. ITERATE = ON, so expect max 2 hr delay, and due to one of the bots being unavailable for download (via the participant's URL) they are not participating.

bwbaugh19:33, 14 January 2012

Over 60 battles per pairing in melee. O.o´ And I uploaded the bot yesterday. :)

...and 1v1 is like 7-8 battles per pairing. Maybe you could split the farm half 1v1/half melee?

MN23:15, 15 January 2012

Melee Battle Farm Active (for the next 16 hours)

Currently running melee battles for the next 16 hours (until 6:00 AM CST 1/12/2012), unless another project requires diversion. The current rate appears to be about 36 battles per minute (2,195 uploads per minute). This also appears to be the close to the limit that the roborumble server can handle (the upload speeds are just starting to slow at this point), even though only using 30% capacity.

bwbaugh21:52, 11 January 2012

How often is the participant list updated for melee battles when ITERATE = TRUE ?

I added a bot the the melee participant list, waited, but it didn't get picked up. So, I restarted a single client, and thus far I haven't seen the other clients pick it up still.

Do I have to turn ITERATE off, and instead use a BAT-file loop? Any thoughts would be appreciated!

bwbaugh22:52, 11 January 2012

Just needed to wait a little bit longer ... the other clients are picking up the new participant now!

bwbaugh23:14, 11 January 2012

Participants list is updated every 2 hours with ITERATE=TRUE as I remember. But I am using a bat-file loop in all leagues.

MN02:28, 12 January 2012

Lots of 'Could not load robot' Errors

Is anyone else getting a lot of these errors?

Could not load robot: Skipping battle because can't load robots:,

I looked at the RoboRumble battle history for the bots, and even a few days ago I have battles uploaded for these bots, so I don't really know what the issue is. It could be that from trying to keep the ZIP distribution up to date, somehow the bots got corrupted, but I don't know about that.

Has anyone else had this or a similar issue before?

The bots I'm getting errors on include: pkdeken.Paladin: java.lang.ClassNotFoundException ... bayen.UbaRamLT aetos.AetosFirstBot lancel.Lynx bayen.nut.Squirrel yk.JahRoslav ... the list goes on and on, roughly 70% of the attempted battles.

--bwbaugh 05:18, 3 November 2011 (UTC)

bwbaugh07:18, 3 November 2011

Have you moved your roborumble directory or your robots directory? In that case you have to delete the '.data' dir and robot.database file from the robots directory.

GrubbmGait14:00, 3 November 2011

As I was falling asleep I figured it was that (I ran it once outside of the normal directory before repackaging).

Thanks! Should be fixed for the next execution cycle.

bwbaugh17:55, 3 November 2011