News about Rebel or Chess System Tal ?

Chris Whittington wrote:

Dio wrote:

Are there any news regarding the current development of Rebel and Chess System Tal ?

Any "speculations" whether Niemann has cheated or not have not much to do with computer chess in my opinion.

I would be especially happy to test the new chess engine from Chris. I hope that this will be the case sometime.

Chess System Tal is pretty much ready to go, we decided to release Rebel 16 first and are just finalising that now.

CSTal is planned for release to rating list testers about a fortnight on from Rebel16 and to users about a week later.

very glad to hear you're well again; is this version from this post something we can check out early

Question for Dio, Ipman and Stefan

I assume all 3 of you use cutechess with -concurrency.

When you test, what's the formula of how many threads you use?

Say your PC has 16 cores and 32 threads, how many threads do you define with -concurrency ?

I am asking because we are struggling with time forfeits on busy PC's, for instance when 28 of the 32 threads are used.

Admin wrote:

Question for Dio, Ipman and Stefan

I assume all 3 of you use cutechess with -concurrency.

When you test, what's the formula of how many threads you use?

Say your PC has 16 cores and 32 threads, how many threads do you define with -concurrency ?

I am asking because we are struggling with time forfeits on busy PC's, for instance when 28 of the 32 threads are used.

I use 12core Ryzen CPUs and concurrency 20 and never had any problems with timelosses. But perhaps you use a too small number for the timemargin-parameter of cutechess-cli?
I use timemargin=2000 (2000 milliseconds) and never had any problems with timelosses... IMO timemargin should be set to 2x size of the increment of your thinking-time (I am testing with 180+1).

My test machine has 12 threads, of which I use 8 threads for testing.

As far as the UCI parameter is available, I set a move-overhead of 500 (500 ms) for the engines.
For the time control I also use the timemargin-parameter.

Dio wrote:

My test machine has 12 threads, of which I use 8 threads for testing.

As far as the UCI parameter is available, I set a move-overhead of 500 (500 ms) for the engines.
For the time control I also use the timemargin-parameter.

timemargin is the same as move-overhead, but located in the GUI, not in the engine. So, if timemargin is set to a high value, there is no need for setting any move overhead as an UCI-option in any engine.

Admin wrote:

Question for Dio, Ipman and Stefan

I assume all 3 of you use cutechess with -concurrency.

When you test, what's the formula of how many threads you use?

Say your PC has 16 cores and 32 threads, how many threads do you define with -concurrency ?

I am asking because we are struggling with time forfeits on busy PC's, for instance when 28 of the 32 threads are used.

I think you just need to monitor Task Manager CPU utilisation, and keep it below 100%. CPU utilisation against Concurrency varies across engines.

pohl4711 wrote:

Dio wrote:

My test machine has 12 threads, of which I use 8 threads for testing.

As far as the UCI parameter is available, I set a move-overhead of 500 (500 ms) for the engines.
For the time control I also use the timemargin-parameter.

timemargin is the same as move-overhead, but located in the GUI, not in the engine. So, if timemargin is set to a high value, there is no need for setting any move overhead as an UCI-option in any engine.

This makes a lot of sense. It's not for the engine to second guess how much allowance it has to make for the range of possible GUIs

Chris Whittington wrote:

pohl4711 wrote:

Dio wrote:

My test machine has 12 threads, of which I use 8 threads for testing.

As far as the UCI parameter is available, I set a move-overhead of 500 (500 ms) for the engines.
For the time control I also use the timemargin-parameter.

timemargin is the same as move-overhead, but located in the GUI, not in the engine. So, if timemargin is set to a high value, there is no need for setting any move overhead as an UCI-option in any engine.

This makes a lot of sense. It's not for the engine to second guess how much allowance it has to make for the range of possible GUIs

I have always been able to used 16 cores, of my 16 cores / 32 logical cores cores when testing on my Threadripper with zero issues. I have had the test running for weeks, and even had them broadcasted here.

I always make sure my testing computers rest start is about 1% CPU usage, with nothing taking CPU in the background.

It could be possible because Threadripper is a sever grade CPU, with more CPU memory, and memory channels, and is designed for this kind of load, over a desktop grade CPU.


So you can test 32 engines at the same time with ponder off, and 16 engines with ponder on.

Dio wrote:

My test machine has 12 threads, of which I use 8 threads for testing.

As far as the UCI parameter is available, I set a move-overhead of 500 (500 ms) for the engines.
For the time control I also use the timemargin-parameter.

And of which value do you set the -timemargin ?

Admin wrote:

Dio wrote:

My test machine has 12 threads, of which I use 8 threads for testing.

As far as the UCI parameter is available, I set a move-overhead of 500 (500 ms) for the engines.
For the time control I also use the timemargin-parameter.

And of which value do you set the -timemargin ?

If you are concerned set it to 5 seconds. But default is fine, I never change my move overhead.

If you are having issues with time losses above the default setting. Your computer is just letting you
know. You have having some kind of slowing issues on your system.

my setting for timemargin is 1000 ms, I am playing with TC 4min + 2sec. There are no timelosses.

Dio wrote:

my setting for timemargin is 1000 ms, I am playing with TC 4min + 2sec. There are no timelosses.

Great.

I turned timemargin off because I thought it was not in use by testers

My bad..............

Cutechess hint - to test for crashes I use a high timemargin of 90 seconds, when there are forfeits check the PGN and the last move will show a time use of ~90 seconds.

I have 4 threads but just use 1 with 128 or 1024 (out of 16384) mb hash for consistency

mwyoung wrote:

Chris Whittington wrote:

pohl4711 wrote:

Dio wrote:

My test machine has 12 threads, of which I use 8 threads for testing.

As far as the UCI parameter is available, I set a move-overhead of 500 (500 ms) for the engines.
For the time control I also use the timemargin-parameter.

timemargin is the same as move-overhead, but located in the GUI, not in the engine. So, if timemargin is set to a high value, there is no need for setting any move overhead as an UCI-option in any engine.

This makes a lot of sense. It's not for the engine to second guess how much allowance it has to make for the range of possible GUIs

I have always been able to used 16 cores, of my 16 cores / 32 logical cores cores when testing on my Threadripper with zero issues. I have had the test running for weeks, and even had them broadcasted here.

I always make sure my testing computers rest start is about 1% CPU usage, with nothing taking CPU in the background.

It could be possible because Threadripper is a sever grade CPU, with more CPU memory, and memory channels, and is designed for this kind of load, over a desktop grade CPU.


So you can test 32 engines at the same time with ponder off, and 16 engines with ponder on.

I've 64x threadripper and that can get flaky with threads > 54 (-ish). It seems to be a combination of Windows OS, thread count and the engine type, some engines are less flaky that others. Disc activity can be a killer if too much at once.

Chris Whittington wrote:

mwyoung wrote:

Chris Whittington wrote:

pohl4711 wrote:

Dio wrote:

My test machine has 12 threads, of which I use 8 threads for testing.

As far as the UCI parameter is available, I set a move-overhead of 500 (500 ms) for the engines.
For the time control I also use the timemargin-parameter.

timemargin is the same as move-overhead, but located in the GUI, not in the engine. So, if timemargin is set to a high value, there is no need for setting any move overhead as an UCI-option in any engine.

This makes a lot of sense. It's not for the engine to second guess how much allowance it has to make for the range of possible GUIs

I have always been able to used 16 cores, of my 16 cores / 32 logical cores cores when testing on my Threadripper with zero issues. I have had the test running for weeks, and even had them broadcasted here.

I always make sure my testing computers rest start is about 1% CPU usage, with nothing taking CPU in the background.

It could be possible because Threadripper is a sever grade CPU, with more CPU memory, and memory channels, and is designed for this kind of load, over a desktop grade CPU.


So you can test 32 engines at the same time with ponder off, and 16 engines with ponder on.

I've 64x threadripper and that can get flaky with threads > 54 (-ish). It seems to be a combination of Windows OS, thread count and the engine type, some engines are less flaky that others. Disc activity can be a killer if too much at once.

Disc activity will be a killer is you do not have a M.2. If you mean disc activity = Tablebase reads.

mwyoung wrote:

Chris Whittington wrote:

mwyoung wrote:

Chris Whittington wrote:

pohl4711 wrote:

Dio wrote:

My test machine has 12 threads, of which I use 8 threads for testing.

As far as the UCI parameter is available, I set a move-overhead of 500 (500 ms) for the engines.
For the time control I also use the timemargin-parameter.

timemargin is the same as move-overhead, but located in the GUI, not in the engine. So, if timemargin is set to a high value, there is no need for setting any move overhead as an UCI-option in any engine.

This makes a lot of sense. It's not for the engine to second guess how much allowance it has to make for the range of possible GUIs

I have always been able to used 16 cores, of my 16 cores / 32 logical cores cores when testing on my Threadripper with zero issues. I have had the test running for weeks, and even had them broadcasted here.

I always make sure my testing computers rest start is about 1% CPU usage, with nothing taking CPU in the background.

It could be possible because Threadripper is a sever grade CPU, with more CPU memory, and memory channels, and is designed for this kind of load, over a desktop grade CPU.


So you can test 32 engines at the same time with ponder off, and 16 engines with ponder on.

I've 64x threadripper and that can get flaky with threads > 54 (-ish). It seems to be a combination of Windows OS, thread count and the engine type, some engines are less flaky that others. Disc activity can be a killer if too much at once.

Disc activity will be a killer is you do not have a M.2. If you mean disc activity = Tablebase reads.

Actually I meant NNUE loading at program start. Asking 64 threads to load humungous of NB weights each fails hopelessly. Which is why NNUE weights are part of the .exe, windows is fine with serially loading bulky exe’s.

timemargin set to 1000ms, played 2000 games, busy PC on purpose, 10 of 12 threads, tc 15+0.1, no single forfeit.

Hurray.

Small update, we are still not fully satisfied with the new time control written from scratch by Chris. It requires a lot of testing but one thing I can tell already, the weak point of Rebel 16 (as many of you know) was the time sudden death time control. Rebel-16a was a major improvement but still not good enough to our taste.

We have now reached a point that sudden death time control performs ~20 elo better than Rebel-16a. And of course all the energy spend on this will also make CSTAL even stronger.

Just to say the (long) wait will be worth for it.

Admin wrote:

timemargin set to 1000ms, played 2000 games, busy PC on purpose, 10 of 12 threads, tc 15+0.1, no single forfeit.

Hurray.

10,000 games 40/10, free of forfeits so far, timemargin=1000

Chris Whittington wrote:

Admin wrote:

timemargin set to 1000ms, played 2000 games, busy PC on purpose, 10 of 12 threads, tc 15+0.1, no single forfeit.

Hurray.

10,000 games 40/10, free of forfeits so far, timemargin=1000

Same good results here, mission accomplished, great job Chris.

I will try to release Rebel 16.1 tomorrow if the last tests are good. Features -

1. A somewhat improved engine. Hard to say how much elo since it only has been tested at 40/10 (bullet) level.
2. Updated time control, especially for the game in x levels.
3. Added permanent brain.

Thus, basically a small update.

1. Much improved time control, especially the game in x levels.

2. Added permanent brain, also known as pondering.

3. The engine has increased somewhat in strength. We estimate an overall increase of 5-15 elo but on game in x levels 20-30 elo.

http://rebel13.nl/windows/rebel-16.html

Hello all,

Something is wrong with the latest engine 16.1. I did some small engine tournaments (5min, no book, no ponder, no endgame base, under the Fritz GUI, Ryzen 9 5950x 32 threads) and it crashes very often. 11 times out of 20... 16a was stable, this one is not unfortunately.

Greets Raymond

On my system with ponder on i had time forfeits. But maybe this is similar bug because it crashed (and the GUI then adjudicates as time forfeit).

Ryzen9 8 cores each, 40 moves in 3'
Pb on

there were first tests by CEGT. The GUI used was the Banksia GUI. This GUI has no timemargin setting. In 100 games (TC: 4 Minutes + 2 Seconds) against Ethereal 13.75 there were 16 time losses.