Possible time management issues

[mcostalba]

Ronald reports on talkchess:

But after a more in depth look at the code, I can only conclude it is totally broken at time controls like 60 moves per 2 hours. For example, at move 52 it might use all of the remaining time except for 100ms Move Overhead. It will then try not to touch that remaining 100ms in the last 8 moves before the increment. So if it does not get flagged, it will blunder anyway.

I still didin't check the code against this example. I write here as a reminder and for interested people to further check and confirm the above claim.

[AlexandreMasta]

I said the current TM is broken some weeks ago.

[snicolet]

There are two separate bugs with the current time management:

A) the losses on time in x/y time controls, as reported by many people on Talkchess and Ronald in the fishcooking forum. This is basically related to the fact that the "ratio" variable in lines 48-53 of timeman.cpp can go higher than 1.0 too easily.

        ratio = (type == OptimumTime ? 1.0 : 6.0) / std::min(50, movesToGo);

        if (moveNum <= 40)
            ratio *= 1.1 - 0.001 * (moveNum - 20) * (moveNum - 20);
        else
            ratio *= 1.5;

Then in line 64 we have this, which caps ratio to 1.0:

int time = int(std::min(1.0, ratio) * std::max(0, myTime - moveOverhead));

this means that SF will happily allocate all her remaining time (minus the moveOverhead latency margin) for each move !

---

B) Another bug is the premature allocation of increment time when there are increments (so in x+y time controls).

Here the problem are in lines 55 and 61, which read:

  ratio *= 1 + inc / (myTime * 8.5);
   ...
  ratio = somevalue * (k + inc / myTime);

I claim this is a bug, because this code suppose that we will get the time increment before sending our answer to the GUI, and so this code acts as if we had already been allocated the next increment.

For instance, if increment is large compared to the time we have on our clock, the 'ratio' variable can again get larger that 1.0

Example white time = 2 white increment = 100

then line 61 will again put a ratio much bigger than 1.0

[Edit] I was probably wrong for B. See https://github.com/official-stockfish/Stockfish/pull/1274#issuecomment-337083047

[AlexandreMasta]

Take this Lucas -> https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/alexandre|sort:date/fishcooking/5wAi1lTDNx0/AG3-5yP0BgAJ

I said the truth! I already reported the issue some weeks ago. So... take your pill and chill.

[xoto10]

Was this fixed with the release on October 15th? We now have a new issue for fixed time controls Removing Slow Mover is a mistake I guess we only need one of these 2 to be open?

[mcostalba]

I'd like to listen the opinion of Ivan on this because he is the author of current code, so he should have the right to reply.

If Ivan does not show up then I have to consider current time management code unmaintained.

[anshulongithub]

Ivan Ivec could you please respond to @mcostalba's question here, I also heard on TCEC that SF is choosing weaker moves when less time is left, please respond..

[MichaelB7]

The time management code with base plus increment is fine and it appears to actually gain elo in all my testing. It is the sudden death (SD) time control - say game in xx that is really much worse than before ( about 20 Elo worse). Did not do any testing with 40 moves in xx time control - but that is how CCRL run their games and i have not seen any issues there with asmfish 051117- so the only evidence i have seen is in game in xx time control (sudden death time control), that needs be fixed. Note: With the base plus increment tc , there are more time forfeits, but that is more than offset by more wins. Currently in my testing with base plus inc , time forfeits are running about 1/600 games , prior to the time management change , it was only 1/18000 games - but the one lost in 600 games are being made up by more wins with the more aggressive time usage earlier in the games.

[namebrandon]

Per - https://github.com/official-stockfish/Stockfish/issues/1336

Please re-introduce "SlowMover" uci option. This was really valuable for those of us running the engine remotely where the executable is on a different system than the UI. MoveOverhead is also valuable, but itself alone is not enough to counteract severe latency (2500+ms) additional protocols (SSH) and network overhead introduce, especially at very fast time controls. I would be happy to explain the use case in more detail.

[mcostalba]

If Ivan does not show up in the next days I will be forced to revert to old time management because new one is unmaintained.

[ianfab]

Since people are waiting for his response, I think it would be good to mention @IIvec here so that he gets a notification.

[IIvec]

@mcostalba: Quick answer: This issue was solved by this patch https://github.com/official-stockfish/Stockfish/pull/1273

More detailed answer: I'm willing to work on time management (x/y time controls are indeed waiting for improvements, although not for bug fixes any more), but it would be good to have clear rules about time management patches. Namely, I understand that some changes require additional tests, and not only standard STC and LTC, but most of the comments to the new time management code were in the spirit:

"Stockfish can't find a winning move in this position..."

Most of patches in chess engines behave statistically, and there will always be positions where new patch (even if decent Elo gainer) behave as bad. I expect from Stockfish community to learn that time management is not exception to this rule.

Recommendation: Before going any further it would be maybe good to see a test between old and new time management code on some longer time control than standard LTC, and maybe also with more threads like 3. If new code can't handle that, there is nothing to maintain, and revert is essential.

But if it can handle those tests, than maybe more people will become more interested to submit some tests... The simplicity is reason for some "ugly" things in new code, that simplicity is calling for improvements, and not only for criticism.

[Vizvezdenec]

Just my 2 cents - since TM tweaks are dealing with increasing/decreasing amount of timelosses, current fishtest solves this problem quite badly since workers with big amount of time losses get autopurged. But huge amount of timelosses in case of TM tweaks can be caused not only because of overloaded machine but because some code is wrong.

[IIvec]

@Vizvezdenec : and there is a third possibility, when code is not wrong, but simply uses time agressively, producing both an Elo gain and some amount of time losses. And it seems to me that we have a problem with consensus about this third possibility, not about two you mentioned.

[Vizvezdenec]

@IIvec I'm not talking about this partucular case but about general case of patches that touch time management - results can be corrupted because workers with high amount of time losses will most likely get purged.

[IIvec]

@Vizvezdenec I'm also not convinced that purging results with high residual is a good thing - in general, not only about time losses.

[IIvec]

And here is my response to https://github.com/official-stockfish/Stockfish/issues/1336

Simple increase of Move Overhead (if needed on some machines) should work much better in sudden death case than changing a Slow Mover (in terms of Elo gain). New time management was much better in sudden death case in the framework. So, even if some value of Slow Mover works better in sudden death case, it is not a default value from an old time management code, but a value from some experiments of some users for their personal needs.

To be brief: I'll make my own tests with 5 minutes per game and report here.

[Ipmanchess]

Sorry IIvec..it doesn't work better from 170817 ,version where slow mover is removed..from then on all dev's tested and ended lower.. from the moment slow mover reverted ,stockfish back where he should be..and back first on my 3 systems. I have never get time losses in my 5min.games ,with both versions! Move overhead is usefull when you get losses on time..but that's not the case here! TM has break something for these sudden death games.. Slow mover back problem solved. So why you put on Ultimaiq these reverted compiles then?! must be a reason.

Looking forward to see your 5min. games what i do for many years ;)

[IIvec]

Hi Ipmanchess,

if you don't have time losses with both versions, and if you didn't change default values of UCI parameters, then your results show that new time management is worse in 5 minutes games, although it was 10-15 Elo stronger in 15 seconds games.

This is a problem of scalability, and a clear sign that at least important patches should be tested on VLTC.

But this has nothing to do with Slow Mover...

As I said, I'll try to test and confirm this.

[Ipmanchess]

Never compare 15sec. with 5min.games and single core with multi core..completly different world! It's 10-15Elo weaker now.

scalability was very bad in Stockfish..was much lower with 1core then with smp ..Houdini was inverse ,but thanks to my testings and give my findings to these programmers this is fixed! So Stockfish has no problems at all anymore and ..it can only improved.

You will see the difference..told also many times testframe should use much longer TC! You didn't tell the reason why Ultimaiq has compiles with Slow Mover reverted?!

[Vizvezdenec]

Your result is statistically insignifficant and thus can't be relied on. And your arguement about "much longer TC" is flatout what fishtest can't afford unless you are willing to donate it 1000 cores for tests.

[Ipmanchess]

Just stay out..you don't know what you talking about! Try playing a few 100.000games @5.min. like i have done!! Show me your data..still nothing seen from you.. ;)

[lp--]

@IIvec: why don't you just run LTC(60+0) sudden death on fishtest? As far as I know LTC was run only for incremental TC 60+0.6, but no LTC has been run for sudden death and xx/yy TC.

[MichaelB7]

@Ipmanchess is correct - tc of 5 min/game , 20 min/game etc is horribly broken. You don’t need a hundred thousand games, it is evident after a thousand games. It plays 20 ELO worse at a fixed time control. I have found other time controls with base and increment or 40 moves in xx to be fine (actually better than old management). But game in xx ( what is known as sudden death time control ) is way worse.

[Vizvezdenec]

@lp-- has the point. Probably running smth like 100+0 (since it's sudden death TC it should be roughly the same as usual 60+0.6 LTC) or even higher (maybe 300+0? I know that it's kinda extreme but it's somewhat affordable) SPRT [-3;1] new TC vs old TC should bring up some light if there is any real elo regression in this case. @IIvec

[Ipmanchess]

Yes lp ,asked Marco also for it to run some tests! Thanks..or even 5min. Thanks MichaelB7 ,good to know i'm not alone ;)

@Vizvezdenec ..that i have asked a few weeks ago already ;) i see this behavor starting from Stockfish 170817 where SM is removed! so it means i'm already a time busy with it..and not only 10 or 400games what you only want to see ;)

[IIvec]

I have old time management on my site because I realized that some people miss it very much. I started first local test at 300+0, and I'll start something in the framework tomorrow.

[IIvec]

300+0 test was OK (on 1 core), but SMP test started very badly on my computer. We'll now verify that in the framework.

[snicolet]

@Ipmanchess @MichaelB7

Two questions:

a) When you say that 5min/game is broken and 15-20 Elo worse, is it in monothread or multithread mode? b) What kind of draw adjudication or win adjudication (if any) do you use in your testing?

[IIvec]

Here is the test: http://tests.stockfishchess.org/tests/view/5a460e160ebc590ccbb8c35d

If oldtime wins with at least 1 point advantage, I'll start a pull request with reverting to old time management. I think it is fair after bad experience of some users.

[Ipmanchess]

Hi Stephane.. on both check my lists 1core ,2cores & 8cores any dev. version i tried ends lower..of course they are out my lists.. only when i tested with revert patch SM back.. get all dev's back on top that i have tested till today..last Ultimaiq Stockfish 261217 with Old TM (i call it with SM reverted) goes again great! With new TM i get them around 10-20Elo above Stockish 8 while with SM i get then higher then +40Elo

Thank you IIvec !

[snicolet]

@Ipmanchess Any draw and/or win adjudication rule?

[Ipmanchess]

No adjudication..using FritzGui 5min Blitz. 1core No Tb's ,2cores 5-men syzygy ,8cores 6-men syzygy.

[Ipmanchess]

@IIvec ..i see you use increment : 5000 @ 36+0.05 th 7 Engine act different with increment..they play out with only increment time.. with 0sec. increment engines has to use time differently..there is nothing left anymore..zero is zero. When you test 30s+1s or 5s+1s ..they will use all time and only continue with the +1s increment ,is not the same in sudden death games ,your 30s or 5s finished ,your game has to be finished before!

[IIvec]

@Ipmanchess If the test will be positive for master, I'll start standard LTC for sudden death case.

[Ipmanchess]

@IIvec Thank you for doing this!

[IIvec]

@Ipmanchess But maybe not because similar test is already started: http://tests.stockfishchess.org/tests/view/5a462f4d0ebc590ccbb8c37a

And you are welcome!

[snicolet]

I have pushed a test with 10000 games, no adjudication, sudden death, 5min/game there: http://tests.stockfishchess.org/tests/view/5a462f4d0ebc590ccbb8c37a

[Ipmanchess]

@snicolet i just see it ,Thank you both!

[Ipmanchess]

@IIvec @snicolet are we talking about same patch reverted? i see two different.. and the one i'm talking is from 170817 Time management simplification: https://github.com/official-stockfish/Stockfish/commit/01d97521fd675ed157ff7d61e6057916abbcc56c

[IIvec]

@Ipmanchess Yes, we use the same patches except that Stephane also disables adjudication rules. After 170817 there were also some cosmetic changes included in the master, and all new Stockfish patches are also included in both versions of time management.

[vondele]

I assume this can be closed after https://github.com/official-stockfish/Stockfish/commit/aa88261a8f509fdabfe235042de1c1ea7a39a399