Difference between revisions of "Talk:WeeksOnEnd"
Jump to navigation
Jump to search
(→OutOfMemory errors: anyone else?) |
Darkcanuck (talk | contribs) (→OutOfMemory errors: 512M?) |
||
(9 intermediate revisions by 6 users not shown) | |||
Line 2: | Line 2: | ||
Anyone else had issues with any of [[User:Simonton|Simonton]]'s bots lately? Last night, 3 of my 4 clients were hung with "java.lang.OutOfMemoryError: Java heap space" from [[WeeksOnEnd]] 1.10.4 battles, and I've had it happen with another of his bots recently, too ([[LifelongObsession]] maybe?). And, sadly, my 4th client hung with the same error from [[RougeDC]] willow. =( --[[User:Voidious|Voidious]] 13:03, 9 September 2009 (UTC) | Anyone else had issues with any of [[User:Simonton|Simonton]]'s bots lately? Last night, 3 of my 4 clients were hung with "java.lang.OutOfMemoryError: Java heap space" from [[WeeksOnEnd]] 1.10.4 battles, and I've had it happen with another of his bots recently, too ([[LifelongObsession]] maybe?). And, sadly, my 4th client hung with the same error from [[RougeDC]] willow. =( --[[User:Voidious|Voidious]] 13:03, 9 September 2009 (UTC) | ||
+ | |||
+ | I used to get those, but they stopped when I changed from iterating within roborumble (ie. ITERATE=YES in roborumble.txt) to iterating in a shell script instead (ie. <code>while sleep 1; do ./roborumble.sh; done</code>). I suspect Robocode still isn't releasing all the memory from bots. --[[User:Skilgannon|Skilgannon]] 13:10, 9 September 2009 (UTC) | ||
+ | |||
+ | : Hmm, I'll have to switch if that solves the problem... The issue with that is that it doesn't seem to recognize priority battles as well on the first iteration, at least that's what I've seen. The first iteration, it just seems to look at the BATTLESPERBOT, while on successive iterations, it tries to fill all pairings. I'll tinker with it later though. Thanks! --[[User:Voidious|Voidious]] 13:12, 9 September 2009 (UTC) | ||
+ | |||
+ | :: I don't use ITERATE=YES because my cpu overheats when I do, and what I think happens to priority battles is that it fights about two battles against each bot instead of one, but that is just hunch, there has been no investagation to support it. --[[User:Zyx|zyx]] 13:52, 9 September 2009 (UTC) | ||
+ | |||
+ | :: There shouldn't be any difference with priority battles whether you're iterating within RoboRumble or using a shell script. Each time your client uploads results, the server sends back priority battles which get saved in a file for the next iteration. What battles you get is determined by what you uploaded. My client doesn't use the iterate flag and is constantly filling out pairings... --[[User:Darkcanuck|Darkcanuck]] 15:22, 9 September 2009 (UTC) | ||
+ | |||
+ | ::: Ok, that's good to hear. However, without a doubt, the first iteration always has a mix of bots getting matches, while successive iterations focus on one bot for the whole iteration. I also remember an issue with exclusions not working when I looped via shell script, like they would work on the first instance and not on the rest. (Of course, that makes no sense, but it is what I remember encountering.) I'll play with it tonight - thanks for the info, guys. --[[User:Voidious|Voidious]] 15:26, 9 September 2009 (UTC) | ||
+ | |||
+ | :::: Does your shell script clean up any files in the roborumble dir? If so, that would certainly wipe out priority battles. --[[User:Darkcanuck|Darkcanuck]] 15:42, 9 September 2009 (UTC) | ||
+ | |||
+ | :::: Nope, I just put the usual command from roborumble.sh inside a "while [true]" loop... --[[User:Voidious|Voidious]] 15:45, 9 September 2009 (UTC) | ||
+ | |||
+ | :: I'm using a second .bat file that calls the original xxrumble.bat. That one calls the second batchfile after one iteration (ITERATE=NOT, 25 battles). That way I when I rename that second batchfile, the client is stopped after the number of battles fought without ctrl-break. I occasionally have such an OutOfMemory error (always in one-on-one), I don't recall any specific bot fighting the last battle though. Sometimes the battles are focussed on one competitor (filling pairings?) mostly the battles are mixed between the bots needing battles. --[[User:GrubbmGait|GrubbmGait]] 22:56, 9 September 2009 (UTC) | ||
+ | |||
+ | :: I'm seeing OOM errors even with a looping shell script, always on WeeksOnEnd. It's definitely specific to certain bots. « [[User:AaronR|AaronR]] « [[User talk:AaronR|Talk]] « 23:07, 9 September 2009 (UTC) | ||
+ | |||
+ | ::: OOM errors always hang my rumble client, which hasn't happened in quite a while. How much memory do you allow? The default in 1.6.1.4 (256M) is set too low, it should be 512M, in case you haven't already changed it. --[[User:Darkcanuck|Darkcanuck]] 01:38, 10 September 2009 (UTC) |
Latest revision as of 02:38, 10 September 2009
OutOfMemory errors
Anyone else had issues with any of Simonton's bots lately? Last night, 3 of my 4 clients were hung with "java.lang.OutOfMemoryError: Java heap space" from WeeksOnEnd 1.10.4 battles, and I've had it happen with another of his bots recently, too (LifelongObsession maybe?). And, sadly, my 4th client hung with the same error from RougeDC willow. =( --Voidious 13:03, 9 September 2009 (UTC)
I used to get those, but they stopped when I changed from iterating within roborumble (ie. ITERATE=YES in roborumble.txt) to iterating in a shell script instead (ie. while sleep 1; do ./roborumble.sh; done
). I suspect Robocode still isn't releasing all the memory from bots. --Skilgannon 13:10, 9 September 2009 (UTC)
- Hmm, I'll have to switch if that solves the problem... The issue with that is that it doesn't seem to recognize priority battles as well on the first iteration, at least that's what I've seen. The first iteration, it just seems to look at the BATTLESPERBOT, while on successive iterations, it tries to fill all pairings. I'll tinker with it later though. Thanks! --Voidious 13:12, 9 September 2009 (UTC)
- I don't use ITERATE=YES because my cpu overheats when I do, and what I think happens to priority battles is that it fights about two battles against each bot instead of one, but that is just hunch, there has been no investagation to support it. --zyx 13:52, 9 September 2009 (UTC)
- There shouldn't be any difference with priority battles whether you're iterating within RoboRumble or using a shell script. Each time your client uploads results, the server sends back priority battles which get saved in a file for the next iteration. What battles you get is determined by what you uploaded. My client doesn't use the iterate flag and is constantly filling out pairings... --Darkcanuck 15:22, 9 September 2009 (UTC)
- Ok, that's good to hear. However, without a doubt, the first iteration always has a mix of bots getting matches, while successive iterations focus on one bot for the whole iteration. I also remember an issue with exclusions not working when I looped via shell script, like they would work on the first instance and not on the rest. (Of course, that makes no sense, but it is what I remember encountering.) I'll play with it tonight - thanks for the info, guys. --Voidious 15:26, 9 September 2009 (UTC)
- Does your shell script clean up any files in the roborumble dir? If so, that would certainly wipe out priority battles. --Darkcanuck 15:42, 9 September 2009 (UTC)
- Nope, I just put the usual command from roborumble.sh inside a "while [true]" loop... --Voidious 15:45, 9 September 2009 (UTC)
- I'm using a second .bat file that calls the original xxrumble.bat. That one calls the second batchfile after one iteration (ITERATE=NOT, 25 battles). That way I when I rename that second batchfile, the client is stopped after the number of battles fought without ctrl-break. I occasionally have such an OutOfMemory error (always in one-on-one), I don't recall any specific bot fighting the last battle though. Sometimes the battles are focussed on one competitor (filling pairings?) mostly the battles are mixed between the bots needing battles. --GrubbmGait 22:56, 9 September 2009 (UTC)
- OOM errors always hang my rumble client, which hasn't happened in quite a while. How much memory do you allow? The default in 1.6.1.4 (256M) is set too low, it should be 512M, in case you haven't already changed it. --Darkcanuck 01:38, 10 September 2009 (UTC)