Rumble Client

Jump to navigation Jump to search

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:

  1. 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)
  2. If the system in question has high memory usage such that it goes into swap space.
Rednaxela (talk)21:09, 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 (3).

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