Martin on the SF loss on time

Discussion of anything and everything relating to chess playing software and machines.

Moderators: hgm, Rebel, chrisw

Modern Times
Posts: 3546
Joined: Thu Jun 07, 2012 11:02 pm

Re: Martin on the SF loss on time

Post by Modern Times »

hgm wrote:I must admit I was surprised to read how Martin decidedly rejected the idea of just increasing this lag parameter. It seemed the natural thing to do (and in fact not setting it to a safer value was a mistake in the first place)..
Indeed. In the past, Martin has changed Komodo's default contempt parameter on request from the Komodo team hasn't he ? I thnk that is the case, but I could be mistaken. Perhaps he has changed the rules sicne then.
syzygy
Posts: 5563
Joined: Tue Feb 28, 2012 11:56 pm

Re: Martin on the SF loss on time

Post by syzygy »

Modern Times wrote:
hgm wrote:I must admit I was surprised to read how Martin decidedly rejected the idea of just increasing this lag parameter. It seemed the natural thing to do (and in fact not setting it to a safer value was a mistake in the first place)..
Indeed. In the past, Martin has changed Komodo's default contempt parameter on request from the Komodo team hasn't he ? I thnk that is the case, but I could be mistaken. Perhaps he has changed the rules sicne then.
You are mistaken. And not setting the lag parameter to a safer value was indeed a mistake, but not one that Martin made.
User avatar
hgm
Posts: 27795
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: Martin on the SF loss on time

Post by hgm »

syzygy wrote:And not setting the lag parameter to a safer value was indeed a mistake, but not one that Martin made.
Sure, it was a mistake of the Stockfish team. But it doesn't seem one worth spilling blood over, and adjusting it to a more realistic value seems a lot less drastic action then changing to a completely different version.

I don't know how much testing time they got on the actual TCEC hardware before the stage started, but if it wasn't very much it seems a bit harsh to say "you overestimated the speed of my machine a little, and I am going to make you pay deerly for that". If during the testing on the TCEC machine no problems occurred, then Stockfish must have been extremely unlucky to encounter it twice now, and there really wouldn't be much reason to change anything at all, as it would be unlikely to happen again.
Psyck
Posts: 4
Joined: Tue Sep 17, 2013 8:17 pm

Re: Martin on the SF loss on time

Post by Psyck »

There is probably a couple of days of testing before the season and an even shorter period of testing between stages. These blitz tests are probably meant to be more of a sanity check as you cannot expect them to be tested at the time controls that the games are actually run at.

Not finding an issue in these tests obviously does not guarantee anything as there have been several crashes and other defects showing up during that games that were not detected in testing.
There is a chasm; between carbon and silicon; that the software cannot bridge.
User avatar
hgm
Posts: 27795
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: Martin on the SF loss on time

Post by hgm »

Well, if participants are allowed to replace their engine between stages, the replacements deserve to be tested as thoroughly as the initialentries. Note that testing at ast TC would be expected to reveal bugs like using too much time for stopping, if they were done at a TC where you are always close to being flagged. (Like 10 sec + 1 sec/move.)
Norm Pollock
Posts: 1056
Joined: Thu Mar 09, 2006 4:15 pm
Location: Long Island, NY, USA

Re: Martin on the SF loss on time

Post by Norm Pollock »

SF team put in a substantially different version for Stage 3 than they did for Stage 2.

It probably had more "housekeeping" chores with regard to running the new SMP on 20 cores. Closing down 20 cores each using tbs (in endgame situations where the time losses occurred) after each move probably used more housekeeping than the previous version.

If that is the case, they did not anticipate the difference, or give the engine enough error slack. If they left the time management the same, they were negligent.
syzygy
Posts: 5563
Joined: Tue Feb 28, 2012 11:56 pm

Re: Martin on the SF loss on time

Post by syzygy »

hgm wrote:
syzygy wrote:And not setting the lag parameter to a safer value was indeed a mistake, but not one that Martin made.
Sure, it was a mistake of the Stockfish team. But it doesn't seem one worth spilling blood over, and adjusting it to a more realistic value seems a lot less drastic action then changing to a completely different version.
I agree that it would have been better not to make an exception just because it's SF. Either consider this a play limiting bug and let the SF team provide a fix as per the rules (i.e. increase the lag parameter), or let SF continue with the current version and parameter settings until the end of the stage.

Actually, I wonder why reverting to the previous version should eliminate the problem if the lag parameter is not increased at the same time. Maybe there is a technical reason for this, but the mere fact that this problem occurred only in the current stage and twice at that could just be a matter of good luck in the previous stages and of bad luck in the current stage.
I don't know how much testing time they got on the actual TCEC hardware before the stage started, but if it wasn't very much it seems a bit harsh to say "you overestimated the speed of my machine a little, and I am going to make you pay deerly for that".
It seems more a case of underestimating the time lost in stopping threads (and/or suboptimally handling this). At any rate it should have been clear that 10ms is nothing on an OS that still counts time in 1/60ths of a second. (But I would not rely on such a tiny safety margin on Linux either.)
BubbaTough
Posts: 1154
Joined: Fri Jun 23, 2006 5:18 am

Re: Martin on the SF loss on time

Post by BubbaTough »

Modern Times wrote:
hgm wrote:I must admit I was surprised to read how Martin decidedly rejected the idea of just increasing this lag parameter. It seemed the natural thing to do (and in fact not setting it to a safer value was a mistake in the first place)..
Indeed. In the past, Martin has changed Komodo's default contempt parameter on request from the Komodo team hasn't he ? I thnk that is the case, but I could be mistaken. Perhaps he has changed the rules sicne then.
My understanding is that the lag parameter was broken and being ignored, so changing the parameter would not help.

-Sam
syzygy
Posts: 5563
Joined: Tue Feb 28, 2012 11:56 pm

Re: Martin on the SF loss on time

Post by syzygy »

BubbaTough wrote:My understanding is that the lag parameter was broken and being ignored, so changing the parameter would not help.

-Sam
Who told you?
mcostalba wrote:Strictly speaking we didn't get the chance to fix any bug although that was possible simply changing an UCI parameter default value (it is a time management parameter): we have asked TCEC to set a different UCI parameter value before the game, but this was not accepted, and I think tournament managers have for sure a point in not accepting it...but then unilateral reverting to a version _they_ choose is does not seem to me a natural consequence.
It seems more likely that reverting to the previous version will not really fix the problem.

If the participants voted based on misinformation, that seems unfortunate. (However, I might not be aware of all the details of this case myself.)
User avatar
Graham Banks
Posts: 41424
Joined: Sun Feb 26, 2006 10:52 am
Location: Auckland, NZ

Re: Martin on the SF loss on time

Post by Graham Banks »

TCEC now seems to be a commercial enterprise, so it was no real surprise that they'd find a way to ensure that there would be the expected Stockfish v Komodo final.
gbanksnz at gmail.com