Rumble Client

Jump to navigation Jump to search

Hi Skilgannon,

There is nothing special. Rumble clients runs with a stock config, where only user name is set and I exclude Lo_Ian.Gandalf_V4*, since it seems to halt on my side. This 6 CPU machine, but only 2 are heavily used for roborumble and meleerumble clients, though last week I left It unattended and firefox start to consume a lot of load, so may be it somehow skewed CPU constant of the client.

If you have some ideas what could it be, I will be happy to investigate.

Beaming (talk)18:34, 8 February 2014

You do not have permission to edit this page, for the following reasons:

  • The action you have requested is limited to users in the group: Users.
  • You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

You can view and copy the source of this page.

Return to Thread:User talk:Beaming/Rumble Client/reply (2).

I am not sure about CPU scaling. This is what ever Debian does to relatively modern AMD CPU. As for the swap, I am 99.99% sure it is not used. This machine has 16GB out of which only about 6 is used. If I look at memory usage, I seen only 3MB of swap used which is way to small for JAVA. May be the problem with linux scheduler, which constantly move application from one CPU to another.

There is one strange thing though, I notice that my meleerumble client usually crash within couple days, but roborumble is not. But this is true for another computer of mine as well.

Beaming (talk)21:27, 8 February 2014

FWIW I don't think anybody's measured the effect of dynamic clock speed on skipped turns, only speculated that it should have an effect. For all I know, the timings coming from Java on modern CPUs could have so much variance that the dynamic clock speed doesn't increase the number of skipped turns that much.

Voidious (talk)22:11, 8 February 2014

Here I run a single client with blank config for a while so it calculates CPU speed alone, before dynamic clock kicks in. Then I copy config to all clients and run them in parallel.

The effect is they assume a worst case in CPU speed and skipped turns occurs less often than it should. Which I think is better than occurring more often than it should.

MN (talk)05:03, 10 February 2014
 
 
 

Thanks for the offer. Could you test DrussGT 3.2.1 vs. Garm, Shadow, Hydra and Gilgalad? Functionally, 3.2.1 should be almost equivalent to 2.8.16 (3.2 has 3-series bullet shielding disabled), but as this comparison shows they are getting very different scores.

There are also a few bots DrussGT now gets 100% against - this worries me, as it points to them crashing.

Skilgannon (talk)07:28, 9 February 2014

What should be the setting on a client to perform such test? Or should I use RoboRunner?

Also my observation showed that sometimes short test set shows drastically (1% APS) higher scores. I was fulled by it couple times thinking that my older bot is more superior to a new version. They end up to have the same score or even reversed as I keep waiting for stats accumulation.

Beaming (talk)21:36, 9 February 2014

I compared DrussGT Version 2.8.16 to DrussGT 3.2.1 And 2.8.16 was way better http://www.2shared.com/photo/bKABJFb4/2816_vs_321.html

Tmservo (talk)00:10, 10 February 2014