Rumble Client
Things often brought up in rumble client discrepancy cases are which OS is in use, and what exact version of Java is in use.
Also, other possible relevant factors are:
- If CPU frequency scaling is enabled, as it is by default on most newer machines (this can cause problems for robocode's CPU time limiting being fair)
- If the system in question has high memory usage such that it goes into swap space.
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.
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page.
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.