Difference between revisions of "Talk:Darkcanuck/RRServer/Updates"
Darkcanuck (talk | contribs) (→Upcoming update: out of luck) |
|||
| Line 10: | Line 10: | ||
: I saw your note elsewhere and it's a client issue, nothing that can be fixed on the server. I think you're stuck until we can use a more recent version of the rumble client. --[[User:Darkcanuck|Darkcanuck]] 07:27, 7 February 2010 (UTC) | : I saw your note elsewhere and it's a client issue, nothing that can be fixed on the server. I think you're stuck until we can use a more recent version of the rumble client. --[[User:Darkcanuck|Darkcanuck]] 07:27, 7 February 2010 (UTC) | ||
| + | :: By the way, Mike, I have a 4-core Windows 7 machine and I am running without issues (mostly). I installed the Roborumble, ran the client once, ran the rumble through one iteration, and then made three copies of the entire folder, named inst1-inst4. I bring a command window for one (shift-right-click on folder in explorer), type roborumble+enter, select the java.exe in the Task Manager, right click and choose Set Affinity, and assign it to one of four CPUs. Then I start and set affinity for the other three, to a different CPU each time. I set the battles/iteration to 50 to make more efficient use of the startup-cost of the robocode.jar. Setting to 100 caused an out of memory error typically around iteration 90ish. I was able to run it overnight and all the next day at 50 with no issues. Let me know if there's something specific you are running into. --[[User:Pedersen|Martin]] 19:07, 7 February 2010 (UTC) | ||
Revision as of 20:07, 7 February 2010
Upcoming update
I'm planning to release a new update today that fixes a major concurrency problem. Database-wise it's a beautiful change since it normalizes things and makes retirement and re-activation a breeze. But I'm a bit concerned about performance because the change will make the worst query in the upload process a bit worse. On my test server everything seems fine but I'll need you guys to keep a sharp eye out for oddities in the live rumble. This update could be very difficult to roll back so if there are any problems we'll need to catch them quickly. Ready? --Darkcanuck 18:20, 6 February 2010 (UTC)
I've got 5 CPU's cranking through battles. Will there be an interruption that requires a restart? --Martin 19:19, 6 February 2010 (UTC)
- There will be an interruption on the server while I make the switch (hopefully not too long), but your clients will keep running and store battles locally until the server is back. --Darkcanuck 19:22, 6 February 2010 (UTC)
FYI - I still cannot run the server with my new Win 7 box and 1.6.1.4 client. Any chance that this may fix that? --Miked0801 07:20, 7 February 2010 (UTC)
- I saw your note elsewhere and it's a client issue, nothing that can be fixed on the server. I think you're stuck until we can use a more recent version of the rumble client. --Darkcanuck 07:27, 7 February 2010 (UTC)
- By the way, Mike, I have a 4-core Windows 7 machine and I am running without issues (mostly). I installed the Roborumble, ran the client once, ran the rumble through one iteration, and then made three copies of the entire folder, named inst1-inst4. I bring a command window for one (shift-right-click on folder in explorer), type roborumble+enter, select the java.exe in the Task Manager, right click and choose Set Affinity, and assign it to one of four CPUs. Then I start and set affinity for the other three, to a different CPU each time. I set the battles/iteration to 50 to make more efficient use of the startup-cost of the robocode.jar. Setting to 100 caused an out of memory error typically around iteration 90ish. I was able to run it overnight and all the next day at 50 with no issues. Let me know if there's something specific you are running into. --Martin 19:07, 7 February 2010 (UTC)
