CCRL adapted TC to current hardware

[Guenther]

I see it exactly the opposite, usually inc games lead to low quality in the endgame, or even long before, if a game lasts much longer
than 40 or 50 moves. IMO it is ugly to have a game finally decided by the low inc for dozens of moves.

Then, use higher increment, and maybe base time too ? My claim is for equal average time per game, if you just use the repeating base time as the base time for base+inc, you typically shorten significantly the average game duration.

Well, the thread is not about what tc I use, all games I have seen since decades from various sites use much less inc than the average time would have been, probably because some odd formula from the past suggested this.

Repeating time control induce "time scramble" every 40 moves, and you'll find plenty of blunders in moves 30 to 40 that wouldn't have happened with the base+increment TC.

It is much easier to program tc management for not happening this...

[kasinp]

Thanks for the explanations, both of you.

...

My understanding is that CCRL is sticking to the old repeating time control (which at equal total time used leads to lower quality compared to standard increment,
...

I see it exactly the opposite, usually inc games lead to low quality in the endgame, or even long before, if a game lasts much longer
than 40 or 50 moves. IMO it is ugly to have a game finally decided by the low inc for dozens of moves.

I completely agree.

In fact, this is my issue with tournaments like TCEC. Amazing hardware to ensure "highest game quality", but only until engines reach bare increment stage. At that point quality actually falls below what many enthusiasts can afford at home, provied they stick to long time control.
Computer chess needs creative solutions to game adjudication. Today we simply sacrifice engame quality to avoid trolls.

Peter

[Laskos]

Thanks for the explanations, both of you.

...

My understanding is that CCRL is sticking to the old repeating time control (which at equal total time used leads to lower quality compared to standard increment,
...

I see it exactly the opposite, usually inc games lead to low quality in the endgame, or even long before, if a game lasts much longer
than 40 or 50 moves. IMO it is ugly to have a game finally decided by the low inc for dozens of moves.

I completely agree.

In fact, this is my issue with tournaments like TCEC. Amazing hardware to ensure "highest game quality", but only until engines reach bare increment stage. At that point quality actually falls below what many enthusiasts can afford at home, provied they stick to long time control.
Computer chess needs creative solutions to game adjudication. Today we simply sacrifice engame quality to avoid trolls.

Peter

It was studied. For the same amount of total time spent, the strongest TC setting Elo-wise is increment in the form of base + base/100 or even base + base/200. Fixed time per move is the weakest Elo-wise for the same total time spent. And 40/X somewhere in between. The large amount of time spent on moves 41-60 with most engines is partly wasted.

[kasinp]

Thanks for the explanations, both of you.

...

My understanding is that CCRL is sticking to the old repeating time control (which at equal total time used leads to lower quality compared to standard increment,
...

I see it exactly the opposite, usually inc games lead to low quality in the endgame, or even long before, if a game lasts much longer
than 40 or 50 moves. IMO it is ugly to have a game finally decided by the low inc for dozens of moves.

I completely agree.

In fact, this is my issue with tournaments like TCEC. Amazing hardware to ensure "highest game quality", but only until engines reach bare increment stage. At that point quality actually falls below what many enthusiasts can afford at home, provied they stick to long time control.
Computer chess needs creative solutions to game adjudication. Today we simply sacrifice engame quality to avoid trolls.

Peter

It was studied. For the same amount of total time spent, the strongest TC setting Elo-wise is increment in the form of base + base/100 or even base + base/200. Fixed time per move is the weakest Elo-wise for the same total time spent. And 40/X somewhere in between. The large amount of time spent on moves 41-60 with most engines is partly wasted.

Sounds reasonable and I don't doubt it, provided that average game duration is to be kept within a certain limit.

It seems self-evident that engame quality will be lower with bare increment than it would be with a repeating TC. The point of course is that we would have to tolerate games taking longer. That is why I keep hoping for a solution to game adjudication. But seeing a TCEC superfinal game (on monster hardware) take 5-6 hours to reach and be decided on bare increment looks silly to me.

[Graham Banks]

Thanks for the explanations, both of you.

...

My understanding is that CCRL is sticking to the old repeating time control (which at equal total time used leads to lower quality compared to standard increment,
...

I see it exactly the opposite, usually inc games lead to low quality in the endgame, or even long before, if a game lasts much longer
than 40 or 50 moves. IMO it is ugly to have a game finally decided by the low inc for dozens of moves.

Agree with Guenther.
Also, many older engines don't support increments.

[lkaufman]

Thanks for the explanations, both of you.

...

My understanding is that CCRL is sticking to the old repeating time control (which at equal total time used leads to lower quality compared to standard increment,
...

I see it exactly the opposite, usually inc games lead to low quality in the endgame, or even long before, if a game lasts much longer
than 40 or 50 moves. IMO it is ugly to have a game finally decided by the low inc for dozens of moves.

I completely agree.

In fact, this is my issue with tournaments like TCEC. Amazing hardware to ensure "highest game quality", but only until engines reach bare increment stage. At that point quality actually falls below what many enthusiasts can afford at home, provied they stick to long time control.
Computer chess needs creative solutions to game adjudication. Today we simply sacrifice engame quality to avoid trolls.

Peter

It was studied. For the same amount of total time spent, the strongest TC setting Elo-wise is increment in the form of base + base/100 or even base + base/200. Fixed time per move is the weakest Elo-wise for the same total time spent. And 40/X somewhere in between. The large amount of time spent on moves 41-60 with most engines is partly wasted.

Sounds reasonable and I don't doubt it, provided that average game duration is to be kept within a certain limit.

It seems self-evident that engame quality will be lower with bare increment than it would be with a repeating TC. The point of course is that we would have to tolerate games taking longer. That is why I keep hoping for a solution to game adjudication. But seeing a TCEC superfinal game (on monster hardware) take 5-6 hours to reach and be decided on bare increment looks silly to me.

The problem is not with using increment, it is that some events have too high a base to increment ratio. In standard human events the ratio is 180 to 240. Our own testing confirms what Kai said, that the ratio should be between 100 and 200 for optimum strength for a given amount of time per game. For standard events like TCEC, increment should be 30 seconds.
Regarding how the testing groups should proceed, I think they should just switch to the closest increment level (with just 100 to 1 ratio to make it less different than repeating as compared to say 200 to 1), combine the results, and just revert to 40/x for old engines that don't support increment. True, it's mixing two different types of TC, but after a while 99% of the results involving newer engines will just be increment results, and they are already mixing different hardware, not even adjusting in the case of the blitz lists. Maybe the difference between AMD and Intel is just as much as the difference in results at 40/2' vs 2' + 1". Probably in both cases the effect on ratings is limited to around ten elo.

[Ovyron]

combine the results

My suggestion is to just keep testing what has been tested with repeating time controls, while new entities introduced to the list move on to increment levels. This avoids the problem of having to create a new list while being able to use all the results already there for rating calculations, as what we care most about is the ratings of untested engines which would have a valid rating against each other and a consisted rating against already tested engines (which would continue to play at their displayed rating because they're still using repeating time controls.)

[Gabor Szots]

I am very much in favour of incremental clock which in my case (I currently test at 40/2) would be 4+2, with a ratio of 120, while approximately keeping total game time the same.
The problem is that engines without incremental clock capacity cannot be combined (at least for me) with others because none of my GUI's can use different types of TC for the opponents.
And of course we'll have to check each time if an engine is OK with Fischer clock (by looking it up in a list) lest we only notice later that it froze in every game. Somewhat uncomfortable but doable.

With all that said, I wonder if anyone would notice any difference between the quality of the games played under different TC types. I doubt I would, for me the switch would mostly be for the fun of it.

[Guenther]

I am very much in favour of incremental clock which in my case (I currently test at 40/2) would be 4+2, with a ratio of 120, while approximately keeping total game time the same.

...

I guess this was a typo and you meant 2+2 instead of 4+2?

[Laskos]

I am very much in favour of incremental clock which in my case (I currently test at 40/2) would be 4+2, with a ratio of 120, while approximately keeping total game time the same.

...

I guess this was a typo and you meant 2+2 instead of 4+2?

40/2 is similar (just a bit weaker IIRC) compared to 2+1 strength-wise, but 2+1 usually consumes less total time per game. Also, the time usage curve is smoother and more efficient with 2+1.