View source for Talk:RoboRumble
Sub-pages: /Archive20130317
RoboRumble history
April 27 2005 - The RoboRumble@Home server is now moved to Pulsar's machine. See /TemporaryServerUp for the RR@H settings files to use and some more details. The only difference you should note is that the flag-less bots no longer have the Jolly Roger flag. This is temporary and will be fixed soon. Huge thanks to Pulsar for carrying the burden (reponsibility-wise) a while with this. I'll sleep tighter now when I don't need to worry if my WinXP Home PC (yes, it was hosted in such an environment before!) is awake and responsive. -- PEZ
October 28 2005 - The RoboRumble@Home server will be down for several hours for upgrades tomorrow (Saturday Octber 29). As a side effect this will solve the issues some people have with port 8080. --Pulsar
October 29 2005 - The RoboRumble@Home server is going down shortly and will be up and running again within 12hours hopefully. -- Pulsar
October 29 2005 - The RoboRumble@Home server is up and running. Updates are needed for RoboRumble@Home clients. -- Pulsar
February 18 2006 - The RoboRumble@Home server connection might experience some downtime the following hours as I will reorganize the firewall setup. --Pulsar
March 7 2006 - The firewall switch over has now finally been done, and everything seems to be working. Some people might experience a short delay until DNS records have been updated around the world (though they were and are set to a very short "time to live" to minimize this). RoboRumble@Home clients need to be restarted as Java by default caches DNS lookups. --Pulsar
- [View source↑]
- [History↑]
Contents
Thread title | Replies | Last modified |
---|---|---|
Problems with JollyNinja | 2 | 15:25, 18 May 2024 |
USER variable not being used | 1 | 21:54, 7 April 2024 |
Publishing of scala robot | 4 | 16:46, 24 May 2021 |
Adding a new flag | 2 | 15:35, 31 October 2020 |
RoboRumble ranking unstable | 1 | 15:32, 13 July 2019 |
1.9.3.5 Could not load properties file: ./roborumble/roborumble.txt | 2 | 13:33, 24 March 2019 |
Upgrade client version | 36 | 11:02, 7 November 2018 |
Huge battle results file? | 7 | 11:39, 8 July 2018 |
Bots that aren't removed | 2 | 02:05, 5 July 2018 |
ThreadDeath problem | 29 | 16:14, 15 January 2018 |
Thousands of duplicated battles??? | 7 | 18:38, 23 October 2017 |
Script to fixup rotten participant jar file links | 0 | 05:01, 8 September 2017 |
ThreadDeath problem and large amount of skipped turns | 3 | 23:20, 7 September 2017 |
First page |
Previous page |
Next page |
Last page |
I noticed that JollyNinja is getting unusually bad results in the latest battles it has run (it currently votes for Quantum, which it really shouldn't be!)
JollyNinja's results on LiteRumble
When I run battles locally I get the following warnings:
SYSTEM: Warning: sgp.JollyNinja uses static reference to a robot with the following field(s):
sgp.JollyNinja.instance, which points to a sgp.JollyNinja
sgp.Environment.robot, which points to a robocode.AdvancedRobot
SYSTEM: Static references to robots can cause unwanted behaviour with the robot using these.
SYSTEM: Please change static robot references to non-static references and recompile the robot.
When I run battles on a 1.9.4.2 client I see the poor performance seen in the rumble but with 1.9.5.2 the performance looks to be okay.
Hey good catch. I guess we should upgrade the rumble to 1.9.5.2?
I'm using a shared computer (MacOS) to run battles and have set the USER variable in roborumble/meleerumble.txt to David414 however when the results are uploaded that username isn't used. This wasn't a problem when I mistakenly tried to use the 1.9.5.2 client. Does anybody know what I need to patch to fix this?
I decide to write robocode bot on scala to learn scala.
But there're a little problem - to run battles with them, you need download scala and add some libraries to rc classpath.
It's ok for me, if only my clients will run my bot. But will whole community agree, if i publish bot, which is not runnable in usual environment?
We shouldn't have bots in the rumble that can only be run on some clients. It's not really fair, and it makes us dependent on a few (or one) clients to get complete pairings for new bots.
There have been discussions about Scala in Robocode before and I think the current state is that we can't officially support it because it requires some insecure stuff disallowed by Robocode sandbox (like Reflection). See Talk:Other JVM Languages and this robocode-developers thread. Maybe we can revisit this discussion, but we'd need input from Pavel or Fnl, and possibly some Scala guru.
I'm also interested in Scala, and it might help us attract the edgy young functional programmers of the world if Robocode supported it. So it would be cool if we could. But I don't really know the details of how to do it right.
Edgy young functional programmers, eh? I must admit I am pretty interested in Scala too and that was one of the main things keeping me from giving it a real try.
It's a pity... But i write robot on scala anyway. I will return to this question when take crown in my local tests:)
Would like to add India's flag and link it to the code IND in the RoboRumble/Country Flagslist. I don't have a GIF. Help appreciated.
Welcome! I've added the flag, you should be good to go!
For unknown reason, the RoboRumble ranking has lost a lot of pairings. MiniRumble and smaller seem not effected. So it will take a while for it to stabelize as there are lots of bots that are missing 1-40 pairings.
That may be caused by a design flaw of the rumble client, which I didn't verify though. If the rumble cannot read robowiki's participants list, it will load a local cache instead. However, if that cache is outdated, it may cause the rumble to loose pairings, and recovering takes much longer. But this seems not to be the case losing 40 pairings.
Another possibility may be that the rumble client got a truncated participant list due to network issues, for this case, I may modify the client to check some flag to make sure the loaded participants list is full.
Hi all, has anybody had the same issue? When I start roborumble.sh, it says "Could not load properties file: ./roborumble/roborumble.txt", and the execution stops right after initiating Iteration 0. In 1.9.3.4, everything seems to work.
I never ever experienced the same thing. And the code change from 1.9.3.4 is kept minimal that I couldn’t come up with whatever change could cause this to happen.
Anyway have you ever tried to have a clean install? Or maybe the path containing robocode contains some weird char that prevents robocode from processing (e.g. space, this bug is known)
Hi all
I've been thinking of upgrading the accepted client version. What are your thoughts on the matter? Have any of you tested extensively with the latest releases locally? Are there any changes in scores (or any changes that might affect scores) that we should do more extensive testing of first?
Finally 1.9.3.3 released, with RoboRumble battle duplicating fix, and with shorter participants list check period from 1.9.3.1 as well. It’s time to do a test and discuss to upgrade.
Question, what kind of tests should be done in local? Should we run a literumble locally and see whether it yields the same score as the main rumble? (which gives the best result but takes monthes). Or just using roborunner with a few robots (both 1v1 and melee certainly), and see their score is unaffected.
Just roborunner and a few bots should be fine. At some point it would be good to reset the meleerumble as well, since old bots get biased downwards by excessive battles against new (good) bots.
I've been always thinking about the pairing systems of meleerumble.
Once every combination of 10 bots had a run, the score is unbiased, which takes N = n! / (10! * (n - 10)!) ≈ 10^19 battles in current settings (n is the total of participants).
However we should get approximate score with feasible battles via monte carlo method. In current settings, ~10000 battles already gives a somewhat stable score (for the new participant).
Let each bot gets m battles, randomly selected from all (N / n) 10-bot combinations containing that bot, then the probability of meeting another specific bot in a battle is (N / n / (n - 1)) / (N / n) = 1 / (n - 1).
Assume that when a new bot is released, every battle contains that bot, then the probability of meeting that bot is 1 instead of 1 / (n - 1), which is highly biased.
To fix this, we have two options — mutate our current pairing systems to get unbiased score online, or to reset the entire meleerumble periodically.
Since the score of new bots are unbiased, all we need to do for an unbiased score is to ignore (n - 2) / (n - 1) biased battles randomly when calculating the score of an old bot. However this approach takes much more battles.
A more practical way is is, when bot A is added, for each battle, select another bot B randomly, and run melee battles containing those two bots as usual. A battle containing A, B and other 8 bots should yield 45 pairings, but only those matching (A, *) or (B, *) is taken into account. This produces 17 parings.
This scheme does not affect the pairings of the new bot itself at all, which is already unbiased; And for an old bot, the probability of being chosen as B is 1 / (n - 1), therefore the probability of a battle with A present being taken into account for old bots is 1 / (n - 1), the same as the unbiased one.
Your second approach seems good, it will need patches on the client side so that if a priority pairing needs to happen it only uploads the battles which contain one of the priority bots. This filter will work fine for the 1v1 rumble as well.
Why don't we wait to update the client until this can be fixed too?
The only reason for upgrading earlier is that those two bugs are very annoying when running rumble client 7/24.
And it generally takes monthes for fnl to release a new version in normal cycle ;(
Anyway, since those two fixes are unrelated to robocode engine, one should expect no performance difference if we cherry pick the fix back to 1.9.2.5.
Maybe we could release a special version of 1.9.2.5 for those running rumble 7/24, before the melee pairing fix is released.
Or, we may just ask fnl whether he could please release 1.9.3.4 soon after the meleerumble patch is applied.
In literumble stats I see that one of my rumble client has stopped working for a few days — and once I had a look, it shows
929073875 Jul 2 21:40 resultsmelee.txt
the resultsmelee.txt grows so large that even the JVM gets killed when processing the file (887M)
and the content of the file is just one line which gets duplicated all the time (which grows exponentially).
Not sure whether this bug is fixed in the newest version, or how can I send pull request to robocode base? the github code seems to be mirror only.
I would suggest making a bug on Sourceforge and attaching a patch if you have a fix.
Btw, is literumble affected by duplicated uploads? Will it remove duplicated battles automatically?
Literumble will reject battles older than 24 hours, so any broken battles have a limited window of problems.
Thousands of duplicated battles could be generated within only a few minutes due to the fact of exponential growth. Thankfully this only happens to bots with multiple weight classes. If literumble is not removing duplicates, then this could answer why some bots get 2x or 5x more battles than other bots. And for those bots, their battle result is mainly determined by those duplicated record which causes inaccurate score ;(
Hope fnl should react sooner this time (instead of half a year)
Only that pairing will have lots of battles - it won't affect the score that much, since it doesn't affect all the other battles. Also, pairings are weighted with a rolling average so roughly only the last 40 battles actually contribute. So once some more battles happen it won't matter.
This isn't a crucial problem but when I have two computers running the client at the same time bots that should be retired aren't removed.
I usually restart robocode client to get updated list from the wiki. Otherwise it takes several hours to stop running battles with retired bots. I think it improved in the latest version of robocode, but littlerumble server does not accept this version yet.
I’m running roborumble on 3 computers/servers, and restarting them manually all the time is already annoying. Once we migrate to the newest version of roborumble, running roborumbe as a service may be eaiser, and I could run roborumble on even more servers (50+ roborumbe clients in total!).
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page.
Return to Thread:Talk:RoboRumble/ThreadDeath problem.
Would you try modifing the source of robocode to make it ouput the result of checkSkippedTurn? I think the bug may be whether the skipped turns are counted incorrectly or some skipped turns are not logged to console.
Skipped turns are logged (and SkippedTurnEvents happens) only when the Robocode regains control over the execution of the thread. Since there is an unhandled exception being thrown right during the skipped turn checking, it makes sense that the skipped turns are not logged. I'm pretty sure you are skipping too many turns, Thread.stop() is being called as it is supposed to be (by looking at Robocode source), the exception is being thrown (because Thread.stop() is deprecated) and for some reason it's not being handled.
So, the error message is pretty much "you have skipped too many turns, I tried to stop your thread but for this I called a deprecated function which throws an error". The bot punishment for skipping too many turns is correct. The correct questions are: this should really happen? not the error, but the "too many skipped turns" thing. Does it happen when locking to 1000 FPS? If it was a "fair" turn skipping, it should happen while locked to 1000 FPS as well? If yes, why it's behaving differently when on full speed? Can others reproduce the same issue? (pick Roborio vs Neuromancer, for example, and go full speed). Why it's more likely to happen when a slow bot is against a fast bot? And so on.
Does you guys have any other interesting observations on that?
Ok. Roborio also fall into ThreadDeath in the battle:
rsalesc.roborio.Roborio 1.2.7 vs penguin.Joker .611wr
It does not happens at 1000 FPS, only if I push the slider to max.
I also see DrussGT falling into ThreadDeath in the battle:
jk.mega.DrussGT 3.2.1 vs penguin.Joker .611wr
It seems that in a pair of bots the most CPU demanding gets the exception.
I looked at the internals. The difference between desired 1000 TPS and max is that in the later case the Thread.sleep is called (actually if you have more than 0.5 ms to spare). I am guessing that probabilistically Thread.Sleep is called couple times per round.
I do not know what java does when thread is asleep, but I would imagine that the garbage collector and other gizmos kick in during the sleep. While at max TPS the java chooses as it wishes when to run GC and if you are the unlucky one, the GC time will be counted against your bot. This would explain sporadic super long executions in my bot time profiling.
I must be very distracted, the skipped turns should be logged, right?
They are logged before the piece of code which calls the thread stopping procedure. It's logged if the bot is still alive. That means that the bots which are getting the ThreadError are not alive at all?
Yes, that's very strange. And that's why I think hack into robocode source code and make it output some useful information in checkSkippedTurn would help.
This would help us find out 1. why skipped turns are getting greater than 30 eventually. 2. why there is no output before at all (is it still alive? )
I'm also thinking about the possibility that the main thread of robocode is also skipping turns itself ;p
I cannot remember how I get this knowledge but I recall that the logic is following. Robocode let you consume as much time as you want per tic (see the exception below), than if you exceed time quota, it will force you to skip as many turns as you excess time over permited time per tic. That is why you often see skipped turns in succession (though, not in my log above).
However, if a bot have a glitch and never returns control back to the robocode (let's say there is an infinite loop), then robocode have a way to force stop such bot. I would not be surprised that it first kill the bot and then executes checkSkippedTurn. In this case a bot will see nothing in console.
For your questions:
- I/O robots (bots that read/write from the data directory) get 240 skipped turns. Apparently a robot can get marked as an I/O robot just by calling
getDataDirectory()
. - This is where things stop making sense. The stacktrace shows
RobotPeer.checkSkippedTurn()
callingBasicRobotProxy.forceStopThread()
, but the code shows that it can't happen without going throughprintln("SYSTEM: ...")
, there literally is no other code path. Areprintln()
calls getting silently dropped? - The Robocode main thread can't "skip turns" because it controls the turn counter.
Relevant code:
public void checkSkippedTurn() {
// Store last and current execution time for detecting skipped turns
lastExecutionTime = currentExecutionTime;
currentExecutionTime = battle.getTime();
int numSkippedTurns = (currentExecutionTime - lastExecutionTime) - 1;
if (numSkippedTurns >= 1) {
events.get().clear(false);
if (isAlive()) {
for (int skippedTurn = lastExecutionTime + 1; skippedTurn < currentExecutionTime; skippedTurn++) {
addEvent(new SkippedTurnEvent(skippedTurn));
println("SYSTEM: " + getShortName() + " skipped turn " + skippedTurn);
}
}
if ((!isIORobot && (numSkippedTurns > MAX_SKIPPED_TURNS))
|| (isIORobot && (numSkippedTurns > MAX_SKIPPED_TURNS_WITH_IO))) {
println("SYSTEM: " + getShortName() + " has not performed any actions in a reasonable amount of time.");
println("SYSTEM: No score will be generated.");
setHalt(true);
waitWakeupNoWait();
punishBadBehavior(BadBehavior.SKIPPED_TOO_MANY_TURNS);
robotProxy.forceStopThread();
}
}
}
Here is my current best guess.
Note that Beaming's stacktrace includes:
... at net.sf.robocode.host.proxies.BasicRobotProxy.forceStopThread(BasicRobotProxy.java:44) at net.sf.robocode.battle.peer.RobotPeer.checkSkippedTurn(RobotPeer.java:649) ...
Therefore, RobotPeer.checkSkippedTurn()
called BasicRobotProxy.forceStopThread()
The source code of RobotPeer.checkSkippedTurn()
shows one and only one possible call to BasicRobotProxy.forceStopThread()
:
public void checkSkippedTurn() {
// ...
if (/* snip */) {
println("SYSTEM: " + getShortName() + " has not performed any actions in a reasonable amount of time.");
println("SYSTEM: No score will be generated.");
/* snip */
robotProxy.forceStopThread();
}
}
Therefore, control flow must have passed through this path.
Note that this code sequence includes a println("SYSTEM: <Bot> has not performed any actions...")
call, which must have been executed, yet no such SYSTEM message is present in Beaming's log.
The source code of the println()
method:
public void println(String s) {
synchronized (proxyText) {
battleText.append(s);
battleText.append("\n");
}
}
Note the following:
- Robocode is multithreaded. Heavy multithreading causes race conditions.
- The variable
battleText
is aStringBuilder
, which is not thread-safe (unlike aStringBuffer
), which is. - The code modifies
battleText
, but only synchronizes againstproxyText
.
Therefore, EvBotNG is skipping turns, but no log messages (from either Robocode or the bot) are printed, because they are silently dropped due to race conditions in the println()
method. The only thing you ultimately see is the ThreadDeath exception caused by Thread.stop()
forcibly terminating the thread.
Presumably, this occurs because of unlucky interaction between RobotPeer.println()
and RobotPeer.readOutText()
.
readOutText() | println() ============================================= | =============================== final String robotText = | battleText.toString() + proxyText.toString(); | | battleText.append(s); | battleText.append("\n"); battleText.setLength(0); | proxyText.setLength(0); | return robotText; |
Therefore, the solution is to add synchronized(battleText) {
guards around readOutText()
and println()
.
Or maybe I'm way off track.
Just looked at those functions showing in error stack, in checkSkippedTurn(), it says: SYSTEM: No score will be generated. before the thread is killed. Therefore the good news is that these errors should not affect your scores.
And oracle says An instance of ThreadDeath is thrown in the victim thread when the Thread.stop() method is invoked. and The top-level error handler does not print out a message if ThreadDeath is never caught.
therefore the error message you see in the console could simply because robocode caught that error to make some clean-ups.
actually robocode kills your thread when you are skipping 30 turns in a row (or if you have file access, this will be increased to 240).
Searching on my system and old backups I was able to find Robocode versions for 1.7.4.2, 1.8.1.0. I was also able to download 1.8.0.0 and 1.9.0.0. So I ran some experiments using Neuromaner vs RaikoMicro. Note, dev version of Neuromancer I'm using here prints out each time it gets a SkippedTurnEvent.
- I can't reproduce it in at all 1.7.4.2. All output looks perfect - every round has printed SYSTEM lines either saying win or death, and Neuromancer correctly gets win/death events. Neuromancer doesn't skip any turns.
- I can't reproduce it at all in 1.8.0.0 - not even "SYSTEM: Neuromancer 5.4 has not performed any actions in a reasonable amount of time." However there are some rounds where nothing is printed, which is very suspicious. Still no skipped turn events.
- In 1.8.1.0 I can sometimes get a "SYSTEM: Neuromancer 5.4 has not performed any actions in a reasonable amount of time.". I saw this 3 times out of 10+ battles. There are also the occasional suspicious blank rounds where Neuromancer prints nothing, and SYSTEM prints nothing. Still no skipped turn events.
- In 1.9.0.0 I can reproduce ThreadDeath exceptions. On average 1 per battle, but sometimes 0 and max I saw was 4. Average of 3 skipped turn events per battle.
To note: all of them had similar CPU constants (between 5.3ms and 5.4ms).
Other things I tried:
- Changing the GC algorithm doesn't affect the number of ThreadDeaths in 1.9.0.0
- Doing a single getDataDirectory() at the beginning of each round doesn't affect the number of ThreadDeaths in 1.9.0.0
This makes me think it is a Robocode bug - possibly multiple bugs, since we have very different behaviors here over the different versions. It also greatly worries me that bots which were fine in 1.7.4.2 have problems in new versions.
Hi Skilgannon,
Isolating robocode issues from jdk version. Would it be correct to assume that you ran everything with openjdk-8?
Yes, all OpenJDK 8
openjdk version "1.8.0_131" OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-2ubuntu1.16.04.3-b11) OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)
Here is the old installs I used to do these tests, I'd appreciate if someone could try them on Windows as well.
Tying into what Beaming said about the sleep in the internals not happening when set to max, perhaps this has been changed since earlier versions of Robocode. However there are more things that may be an issue as well, I don't think that is the total of what is buggy here. The missing prints in a round particularly concerns me (and yes, this still happens in recent versions).
After my Roborumble@Home experienced some network error, and when the network finally recovered —
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 9ms OK. MyFirstJuniorRobot vs PingPong added to queue in 7ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 20ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 25ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 13ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 37ms OK. MyFirstJuniorRobot vs PingPong added to queue in 41ms OK. MyFirstJuniorRobot vs PingPong added to queue in 28ms OK. MyFirstJuniorRobot vs PingPong added to queue in 6ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 12ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 18ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 27ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 6ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 7ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 10ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 43ms OK. MyFirstJuniorRobot vs PingPong added to queue in 16ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 24ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 6ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 7ms OK. MyFirstJuniorRobot vs PingPong added to queue in 6ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 6ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 11ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 6ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 6ms OK. MyFirstJuniorRobot vs PingPong added to queue in 13ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 6ms OK. MyFirstJuniorRobot vs PingPong added to queue in 11ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 6ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 72ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 81ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 44ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 19ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 7ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 37ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 6ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 6ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 47ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 6ms OK. MyFirstJuniorRobot vs PingPong added to queue in 79ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 84ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 6ms OK. MyFirstJuniorRobot vs PingPong added to queue in 11ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
there are thousands of similar logs, but when I searched the history, there are only one battle of "MyFirstJuniorRobot vs PingPong", which failed to upload and got doubled each time it failed again.
I think this must be some bug in Roborumble@Home, since the network is broken. And I see similar things quite often, although not that huge. It seems that each time a battle fails to upload, it doubles, and then two battles of the same fails to upload, it doubled again, and it grows like crazy.
Since such battles are timestamped, it would not be a problem for the sever to remove duplicates with same timestamp, uploader and pairings before adding this to queue. But what I see is that the queue got full after thousands of uploads and the battles are logged, e.g. in BottomUp's page, SuperCrazy has 160 battles, which is significantly more than anything else.
This has happened to me too. I fixed it when I changed my computer.=)
Do you mean by using another computer, it won't submit duplicated battles after network error? Are you still using mac on the new computer?
Yes,I still use a mac. It happened when I stopped a client before it finishes the whole iteration and then change the version.
Sorry for not being clear. I was meaning the robocode version but I'm not sure.
I cooked up a script to fix rotten link FixingParticipantLinks please use it from time to time
This continuation of problem investigation mentioned at Thread:Talk:RoboRumble/Client java version and Thread:Talk:RoboRumble/ThreadDeath problem.
After Skilgannon patch, I can see some useful debugging info. In particular, I added output for the number of skipped turns which triggers ThreadDeath call.
I see that as many as 100 or even more skips are detected. This is when TPS slider at max. Move it to 1000 and everything is handy dandy. Note that 1000 TPS is unrealistic with my CPU constant of 6 ms. I.e. per second I can get 1/0.006 about 170 tics. So the system have no time to go to the idle state in either case. On top of it, 160 skipped turns (times 6ms), i.e. about 1 seconds of inactivity, would be noticeable with a naked eye watching the battle. I see no freeze there. So something does not add up.
Here I need the experts help. I look at the source, and the only timing mechanism I see is that within allocated time the thread must report isSleeping. But I see no time checks anywhere, i.e. no one calls for nanoTime. So how the robocode decides that the timeout is exceeded?
Could it be that java calls to robocode waitSleeping are not done correctly.
Here is one more strange thing. I switched debug=true, than I have about 300*cpuConstant to finish a tic, and I time profiled everything. My time per tic is consistently shorter with debug=true, then with debug=false (default). I know it probabilistic but ... Also, in either case my inner methods never report times exceeding 25mS, which is 5 skipped ticks at most. So how do I end up with 100 skipped tics penalty.
Also, I cannot get to ThreadDeath when I play against HawkOnFire. This is very simple and fast bot, but how does it help my bot to avoid the skipped turn penalty?
It's interesting, I actually see considerable speed difference between running at 1000TPS and max, even though my CPU constant is 5.3ms. I think this is because many ticks have much less than 1ms of calculations, and these cause a sleep in 1000TPS mode. Also, just to confirm, I also only see the ThreadDeath issues when running at max, and never at 1000TPS.
From what I remember the engine works something like this:
- Engine triggers condition variable to release bot thread
- Engine goes to sleep for up to CPU_CONSTANT milliseconds
- Bot thread runs
- Bot thread finishes, triggers interrupts to wake up engine thread early
- Engine thread wakes up, and checks time. If time exceeded, divide time taken by CPU_CONSTANT milliseconds, subtract 1, say bot skipped this many turns, if exceeds 30 kill bot. Otherwise continue as normal.
So I'm wondering if maybe there is another thread that is delaying the engine thread from waking up, perhaps to do some maintenance (garbage collection, JIT compiler swapping out methods with optimized versions, etc). There are probably heuristics that say it is a good time to do maintenance, when switching between threads, if nothing else is available. When in 1000TPS mode these actions would happen when the sleep happens (ie. nicely scheduled, not interfering with bot timing etc), since the heuristics say it is better to work in a sleep than to not switch between threads quickly.
In my mind, the easiest way to fix this would be by also doing timing in the bot thread, and only checking the timing in the engine thread if the bot thread hasn't finished yet.
Thoughts? Does anybody see issues with my thinking here?
It does not look that item 5 is performed the way which would be reasonable (i.e. how you describe).
Have a look checkSkippedTurn() where decision about penalty is done (I believe it is actually your code :). It does not check CPU time, it makes comparison based on the internal robocode Ticks.
int numSkippedTurns = (currentExecutionTime - lastExecutionTime) - 1;
Robocode should call something to increase time (tic) inside of robot peer. If it does not do so for a bot, that bot will be punished. I still cannot find the part of the code where time++
logic is executed. These threads drive me nuts.
So, I like your proposal to time the bot inside its thread.
Hmm, there is still a problem with my idea, robocode will still kill the thread if it doesn't respond in time.
I see two different ways to combat this:
- Put a turnState enum with states {START, RUNNING, FINISHED} which can be polled to know if the bot thread is finished, combine this with timing in the bot thread, and then if it is finished we know it is not the bot causing the delay, so we don't kill the thread.
- Put some small sleeps every ~100 ticks to give the JVM time to perform optimizations and cleanup without interfering with the bot threads.
These could be combined, since they attack the problem from different sides.
First page |
Previous page |
Next page |
Last page |