Talk:Darkcanuck/RRServer/KnownIssues

Survival count should total 35

I want to confirm what has already been mentioned: survival count should not necessarily total 35. It appears that when bots die on the same tick, they both get credited with a first place finish. --Simonton 22:49, 27 September 2008 (UTC)

• There was only one unmatching battle (17+14) in the over 5000 results I sent to this server. But indeed, 34 and 36 should be accepted too in my opinion. I think that battles against rambots (used to) have the most chance on getting these non-35 results. --GrubbmGait 23:16, 27 September 2008 (UTC)

The current check is that the survival totals at least 35 should that should take into account ties. But the results that are getting stuck on my clients are for <35 1st place survivals. One client has 24-8 (32 total) for Cephalosporin vs UrChicken2. Two of my clients (not physically here, checked on them yesterday) had about a dozen battles involving RougeDC Classic, also with less than 34. What to do? --Darkcanuck 23:55, 27 September 2008 (UTC)

Well, could you try running the normal Robocode (non rumble) with pairings like you're seeing this with in rumble? If you can't reproduce it that way, than it sounds like it might be a bug in the rumble client, and if you can reproduce it it should become evident what's happening by watching the battles when this happens (perhaps use the replay feature? Not sure how well that works though). I can't seem to see anything at all like that happening here. --Rednaxela 00:02, 28 September 2008 (UTC)

I only see those clients once every few weeks, so it will be awhile. They're running 1.5.4 with the latest version of Java on Windows 2000. It's only ~12 battles out of 1500+, so a very low occurrence. If I turn off the survival check, you'll see them come through... --Darkcanuck 00:19, 28 September 2008 (UTC)

I would not accept results lower than 34 or higher than 40. This check is mainly to intercept results from wrongly setupped clients, as that can be devastating for the rankings. A rare glitch of Robocode or the client can easily be repaired (when noticed). --GrubbmGait 01:16, 28 September 2008 (UTC)

HTTP response code: 503

Hmm, I started getting a bunch of "HTTP response code: 503" errors when uploading results. Anyone know why? --Rednaxela 18:09, 2 December 2008 (UTC)

I've got the same problem, and sometimes downloading rating page --lestofante 19:04, 2 December 2008 (UTC)

Yeah, also when the client tries to download the ratings here too. One thing I've noticed is that when it tries to download the rating pages is that sometimes it's 503 and sometimes it's 500, but it's always 503 for uploading. Anyways right now I'm running my RR client with upload/download disabled in order to build up battles to upload in bulk when uploading is working again. --Rednaxela 21:06, 2 December 2008 (UTC)

Hmm, the server does not look happy -- some sort of high load condition, I'll what I can do. --Darkcanuck 04:04, 3 December 2008 (UTC)

ATTENTION! Someone has a bad participants list -- almost half the bots in the rumble have been removed! This is a very slow operation, especially when other clients are trying to add them back in. I've disabled bot removal for now while I investigate the source... --Darkcanuck 04:43, 3 December 2008 (UTC)

Mea culpa, yesterday I've run for at least 20 minutes 5 hour the rumble with an empty participants list before I see, understood and fixed my client's problem.. next time I will play with his option with Upload flag set to false! Now everything is running and I've over 2000 battle's to upload --lestofante 11:29, 3 December 2008 (UTC)

Ok, I've re-enabled your username + IP so you can upload again. 2000 battles, eh? Just make sure you're using one of the approved clients (1.5.4 or 1.6.0). Participant removals are still disabled just in case since the participant list can't change anyway.

Retired Bots

In details pages like this, bots that are 'retired' like Cunobelin 0.2.1 are showing up (see ELO score 0 bots on details pages). Did this accidentally happen when you disabled removal/retiring of bots temporarily? (Also, would it be possible to make details pages for retired bots viewable with the right URL? :)) --Rednaxela 16:52, 3 December 2008 (UTC)

Thanks for pointing that out -- I was trying to figure out why the rumble pairings weren't going back to normal. I'm not quite sure how those bots got reactivated, need to think on that a bit. (Could be the economic crisis has affected their retirement plans?) It doesn't look like any rumble clients are trying to remove them though -- probably due to the failure to download the participants list. I'll see what I can do to remove them. --Darkcanuck 02:31, 4 December 2008 (UTC)

Hm, I think its a bug in the reactivation process... if both participants in a pairing have been retired, reactivating either also reactivates the pairing, ugh. --Darkcanuck 02:48, 4 December 2008 (UTC)

Performance

I'm uploading many battle I've run off-line, but the server is too slow. in 29 minutes I've uploaded only 262 battles, about 9 for minute!! Maybe are you updating all scoring system at every battle upload?--lestofante 13:30, 4 December 2008 (UTC)

The scoring is calculated for each upload yes. If it wasn't the results page and such wouldn't be nice and live and such. Apparently Darkcanuck is planning some things that may improve performance such as getting rid of table locking in favor of transactions, but really, I do think the roughly 2 seconds per battle that you describe is very acceptable. After all, running a battle takes considerably longer than 2 seconds in almost all cases, so it's not like it's that huge an impact on the total number of battles uploaded. --Rednaxela 13:47, 4 December 2008 (UTC)

I think the scoring system have to be updated only when requested the scoring page or similia.. so we have to update only WHAT we need WHEN we need, saving many time and resources. Pay attention: the upload relay is about 60sec/9battle=6sec/battle, not 2... acceptable? lets see.

1. 1 execute of roborumble.sh = 1 iteration
2. 1 iteration = 10 battle
3. 6sec/battle * 10 battle = 60second of upload time for iteration
4. 150-200 seconds = 1 iteration on amd64 x2 4000+, ubuntu OS, openJDK as virtual machine, UPLOAD=NOT,DOWNLOAD=NOT + roborumble loading time

Result: upload time is about 1/3 of my rumble running time in the worst case... and IMHO it's not acceptable --lestofante 14:30, 4 December 2008 (UTC)