Thread history

From Talk:LiteRumble
Viewing a history listing
Jump to navigation Jump to search
Time User Activity Comment
15:10, 29 March 2013 Voidious (talk | contribs) New reply created (Reply to quota reached)
10:17, 29 March 2013 Skilgannon (talk | contribs) New reply created (Reply to quota reached)
09:26, 29 March 2013 Skilgannon (talk | contribs) New reply created (Reply to quota reached)
00:23, 29 March 2013 Voidious (talk | contribs) New reply created (Reply to quota reached)
20:50, 4 August 2012 Skilgannon (talk | contribs) Comment text edited  
20:49, 4 August 2012 Skilgannon (talk | contribs) New reply created (Reply to quota reached)
20:33, 4 August 2012 Voidious (talk | contribs) New reply created (Reply to quota reached)
20:24, 4 August 2012 Skilgannon (talk | contribs) New reply created (Reply to quota reached)
20:05, 4 August 2012 Voidious (talk | contribs) Comment text edited (typo)
20:04, 4 August 2012 Voidious (talk | contribs) New thread created  

quota reached

ERROR WRITING DATA!! QUOTA REACHED?

Oh no! I guess I'll stop my GigaRumble client. =) I've only been one running one slow client on my laptop, and with 30 slow bots it's pretty low volume - I think ~20 minutes per 25-battle iteration, at least.

Voidious20:04, 4 August 2012

Don't worry, I don't think it's you. I have 8 clients running at the moment in my lab, and it seems that they suddenly started producing a whole lot more battles over the last few hours (I'm not sure why). It's quite interesting, on the requests-per-second graph I can see when the latest Diamond was released quite clearly =) Check it out:

Literumble-request-per-second-chart.png

Again, I have no idea why that sudden burst of data came in. Considering it's about triple what I normally get, it would correspond with ~24 clients running regular rumble battles. Very strange. And no wonder I'm out of quota...

Skilgannon20:24, 4 August 2012
 

Hmm. If you have battles per bot 2000, and then they stopped running DrussGT / Diamond battles, I could easily see the battle rate tripling when switching to minibots or random battles.

Voidious20:33, 4 August 2012
 

It shouldn't switch to random battles though, because I've got priority battles going the whole time and the 1.7.3.2+ clients ignore the BATTLESPERBOT if there are priority battles waiting. I think I've identified a bug in the priority battle selection algorithm though, it is giving higher priority to pairings with more battles, rather than less (although that only starts happening once all the pairings are complete, at least).

Also, it hasn't been waiting on Diamond and DrussGT to fill out their battles like Darkcanuck's rumble, because until just now *everybody* was below 2k battles.

Skilgannon20:49, 4 August 2012
 

Ruh roh, my client's hitting this again.

OK. mrm.MightyMoose .2 vs logiblocs.Fire 1.0 received in 365ms
ERROR WRITING DATA!! QUOTA REACHED?
Voidious00:23, 29 March 2013
 

That makes no sense, it is well below hitting anything. There was also an issue with priority battles not having any options because everybody had full pairings, which was some errors, as well as malformed requests which were coming from my university connection, I think they had something to do with the SEACOM cable currently being down.

I've added some logging, so next time it happens I can see exactly what the problem is.

Skilgannon09:26, 29 March 2013

OK, fixed. It was having trouble with a mixture between numpy floats and native Python floats when writing them to the database.

Skilgannon10:17, 29 March 2013
 

Ah, so this was just some other error with the same message? That's a relief. :-) Turned my clients back on.

Voidious15:10, 29 March 2013