Time usage of winboard engines

[Kirill Kryukov]

Hi all! I have a question for Winboard specialists. I noticed strange time usage with some engines that I test. A self-explanatory screenshot is below:



I first noticed this with "EXchess 5.01 beta 64-bit JA", in repeated time control. It plays normally until move 40, then it suddenly starts taking very long time for each move, for about 5 moves. After that it is in time trouble and has to play fast till the next control at move 80. At move 80 the pattern repeats.

I first thought it's EXchess own issue, but now there is one more engines with the same behavior - Resp 0.19 64-bit JA.

In the example screenshot above you can see that Resp case is more severe, it uses almost all its time for a few moves after move 40. In this particular game Resp had advantage before move 40, but lost the game because of time trouble.

Have you seen anything similar? Is it an engine issue, or my setup, or may be it's a 64-bit compile problem? Any ideas will be appreciated!

[Gábor Szots]

I first noticed this with "EXchess 5.01 beta 64-bit JA", in repeated time control. It plays normally until move 40, then it suddenly starts taking very long time for each move, for about 5 moves. After that it is in time trouble and has to play fast till the next control at move 80. At move 80 the pattern repeats.

I first thought it's EXchess own issue, but now there is one more engines with the same behavior - Resp 0.19 64-bit JA.

In the example screenshot above you can see that Resp case is more severe, it uses almost all its time for a few moves after move 40. In this particular game Resp had advantage before move 40, but lost the game because of time trouble.

Have you seen anything similar? Is it an engine issue, or my setup, or may be it's a 64-bit compile problem? Any ideas will be appreciated!

Hi Kirill,

I have seen this behaviour with the Hungarian chess engine Merlin. In fact this is the reason why Merlin (multiple Hungarian champion) has not yet been tested for CCRL. I reported the issue to its author but he apparently does not have the time to investigate the matter.

It has to be noted that under WinBoard everything goes normally. Only under Arena and Shredder (and now under CB) is the behaviour as you described.

[H.G.Muller]

Many WB engines suffer from this when you play from an external opening book.
They then receive the go command later in the game, (say at move 5), and start counting
the moves only from there. So when they reach move 40, to them it is only move 35.
The extra time on their clock that the GUI reports to them then comes as a complete surprise
to them, which they happily exploit during the remaining 5 moves, so that they have used up
nearly all time at move 45 (which they think is move 40). It then comes again as a complete
surprise (this time an unpleasant one) that they do not receive the expected new time
quota after this move, so that in fact they have to play the remaining 35 moves of the second
session in the few seconds that were left on their clock after move 45 (which they thought
to be 40). On move 75/80 the whole thing repeats. They thus play the first 5 moves of any
session except the first in the full time for the session, and the other 35 moves in just a few
seconds. Of course this means they usually do not survive upto the third session...

In principle this behavior also occurs under WinBoard. But the more book moves you have,
the less obvious the effect is. This because most engines manage their time such that they
normally do leave a safety margin of about 7 moves before any time-control point. This
because a move in a difficult position can easily take 5 times as long as an average move.
So if you had 24 moves in book, the engine realizes its error only on move 64, (at 40/40),
and then have to do the remaining 16 moves before it gets new time in 7 min, which is not
extremely much faster than normal, and usually interpreted as that the engine speeds up
in the end-game under time pressure.
has to do 16 moves

That this is so common is due to a very unclear sn confusing description of the clock issue in
the WB protocol document on Tim Mann's website. I tried to clarify it in the protocol definitin
here, based on how WB did actually manage the clocks. There is no easy work-around for engines
that suffer from this, other than play them with external book at incremental time controls
only.

[Graham Banks]

I first thought it's EXchess own issue

Strangely enough, I haven't had this problem with EXchess, perhaps because I use the wb2uci adapters, even under Arena or ChessGUI. Seems to be safer and less troublefree than installing as a WB engine. Doesn't work for all engines though, eg, Butcher and Wing.

[Kirill Kryukov]

Thanks H.G., Gabor and Graham! Particularly H.G. for a great explanation! Does Winboard interface have any magic to work around this, or it happens there too?

I wonder what would be the best solution to still test those engines in 40/4 time control. The choices I see: 1. Let broken engines play without any book. 2. Let broken engines play with their own book. 3. Using 1/0.1 time control, or time control with increment.

Also, as these two particular engines are open source, may be someone could fix them? (Jim?) This would be an ideal solution.

[Kirill Kryukov]

Strangely enough, I haven't had this problem with EXchess, perhaps because I use the wb2uci adapters, even under Arena or ChessGUI. Seems to be safer and less troublefree than installing as a WB engine. Doesn't work for all engines though, eg, Butcher and Wing.

Since I use Chessbase GUI, I also have to use WB2UCI adapter with both of these engines. Though, if your one works fine, could you please upload your EXchess with configured WB2UCI somewhere for me to try?

[H.G.Muller]

Thanks H.G., Gabor and Graham! Particularly H.G. for a great explanation! Does Winboard interface have any magic to work around this, or it happens there too?

It happens there too. Of course WinBoard did not use to support a GUI book (this will be new in 4.3.15), but I did get the same effect with some engines when I would play from a loadGameFile (with opening moves in PGN).

Of course I could put in a work-around, by adding an option to let the WinBoard clock management conform to what these engines expect (i.e. count moves starting at the last go command), but is seems bad policy to cater to broken engines.

[Kirill Kryukov]

I have an idea. How about setting book position in force mode instead of using setboard command? (not sure the terminology is correct). This way an engine will count every move, so it should work? I think WB2UCI can be configured this way?

[Guenther Simon]

Many WB engines suffer from this when you play from an external opening book.
They then receive the go command later in the game, (say at move 5), and start counting
the moves only from there. So when they reach move 40, to them it is only move 35.
The extra time on their clock that the GUI reports to them then comes as a complete surprise
to them, which they happily exploit during the remaining 5 moves, so that they have used up
nearly all time at move 45 (which they think is move 40). It then comes again as a complete
surprise (this time an unpleasant one) that they do not receive the expected new time
quota after this move, so that in fact they have to play the remaining 35 moves of the second
session in the few seconds that were left on their clock after move 45 (which they thought
to be 40). On move 75/80 the whole thing repeats. They thus play the first 5 moves of any
session except the first in the full time for the session, and the other 35 moves in just a few
seconds. Of course this means they usually do not survive upto the third session...

In principle this behavior also occurs under WinBoard. But the more book moves you have,
the less obvious the effect is. This because most engines manage their time such that they
normally do leave a safety margin of about 7 moves before any time-control point. This
because a move in a difficult position can easily take 5 times as long as an average move.
So if you had 24 moves in book, the engine realizes its error only on move 64, (at 40/40),
and then have to do the remaining 16 moves before it gets new time in 7 min, which is not
extremely much faster than normal, and usually interpreted as that the engine speeds up
in the end-game under time pressure.
has to do 16 moves

That this is so common is due to a very unclear sn confusing description of the clock issue in
the WB protocol document on Tim Mann's website. I tried to clarify it in the protocol definitin
here, based on how WB did actually manage the clocks. There is no easy work-around for engines
that suffer from this, other than play them with external book at incremental time controls
only.

I want to add a few other points to that behaviour too.
There are some engines which independent from book voluntarily
distribute their time like that e.g. Knightcap(which doesn't use a book
at all).
There are others even with own book which obviously don't count
own book moves, e.g. Cheese 1.3 as WB engine.
(I wonder though why Cheese 1.1b doesnt behave like that?)

Guenther

[H.G.Muller]

I have an idea. How about setting book position in force mode instead of using setboard command? (not sure the terminology is correct). This way an engine will count every move, so it should work? I think WB2UCI can be configured this way?

I assumed this was already done when an external (GUI) book was used? At least it is how WinBoard 4.3.15 handles the GUI book, or earlier WinBoards when they used the loadGameFile: the engine just follows in force mode. The problem is that some engines simply do not count moves in force mode, (perhaps because they consider them opponent moves?).

If you start from a position given by setboard (by using the loadPositionFile option in WinBoard), then even WinBoard loses track of move counting. WinBoard ignores the move number in FENs. I guess most engines do this too, so it poses no problems.

The main problem is a serious design flaw in WB protocol: it does send the remaining time with every move, but WB does not tell the engine how many moves are left to do in this time. It would have been much better if it would always send both. But it only sends the number of move in the level command, and the engine has to count down all by itsef from there, hoping it accurately tracks the WB counter.

This does suggest a possible fix: I could make an option that forces WB to send a level command before every move, in stead of the time command. This would then send remaining minutes and remaining moves as the GUI thinks they are, so that engine and GUI can never get out of phase, no matter how the game started. Multi-session time controls would then automatically work as well. I am considering anyway to implement multi-session TC by having WB send a new level command at the instant it knows that the engine has the wrong idea (based on an earlier level command) of the number of moves in the upcoming session, i.e. at the beginning of each session that has a dfferent number of moves as the previous.

There is no way to know if existing engines would properly understand this, though. (Although itis likely they do.) The WB protocol descrption used to be rather vague here: it id not exactly specify ho to handle a level command during a game, but it did not gurantee that such a command could only be send at the begining of a game either...

[Sven Schüle]

I see 1) problems with that "send 'level' instead of 'time' at every move" idea, and I also have 2) a different opinion about the move counting issue that is being discussed here. This finally leads me to 3) my proposal how to solve the issue.

Let's address one after another.

1) Sending "level" as a replacement for "time" would not be a good solution IMO due to the following problem:

"time" and "otim" do send the time in centiseconds while "level" sends either minutes or minutes:seconds, so the resolution is different. You can't change this anymore unless you change the "level" spec again into something like minutes[:seconds[:centiseconds]]. But even then many existing engines would not recognize the centiseconds part, causing them probably to play slightly too fast since on average they would believe to have 0.5 seconds fewer than the "exact" remaining time that WB would have told them with the "time" command. This would mean that they would use about 20 seconds less per 40 moves than they could use. Also, "ultra-fast" time control would become pointless then.

Furthermore I would expect that existing engines would show quite different reactions on receiving more than one "level" command per game, for instance:

a) ignore it;

b) reject it;

c) get confused by it, i.e. get into an inconsistent state;

d) understand it and adjust their time control settings such that the "moves per session" number starts counting at the initial position of the game - which would be one of two possible interpretations of the original (Tim Mann's) description of the "level" command;

e) understand it and adjust their time control settings such that the "moves per session" number means "number of moves remaining from now until next time control" - which would be according to HGM's extended "level" description (see chapter 11 in http://www.open-aurec.com/wbforum/WinBoard/engine-intf.html where HGM added a paragraph starting with "The number of moves given ..." which is unfortunately not coloured in green, unlike other changes ).

At least the differences in behavior regarding d) vs. e) would be substantial.

It would of course be interesting to find out what the current engines really do in this case but I'm afraid there will be no clear majority. So I would really prefer to stick with the "time" approach, even if the new behavior would only be switched on by a command line option to the engine. The problem with the command line option would be that in general you can't know how an engine behaves that does *not* implement that new option but also does *not* reject additional "level" commands, see my list above.


2) Now about move counting. I really consider it a serious bug if a chess engine or a chess GUI does not keep track of the move counter properly in all cases. While handling the standard case (game starting at initial chess position, and moves being made from there) should be safe everywhere, two situations have been mentioned where programs sometimes "lose" the correct value of the move counter:

a) when receiving an FEN (e.g. via "setboard") with a "full move" counter > 0,

b) when moves are made in force mode.

Since both can be implemented correctly with no special effort (just our will to overcome our lazyness ...) I think it would be best just to do it. At least the move counter from an FEN should not be ignored.

I have to admit, though, that my own engine "Surprise" has that serious bug, too, since it ignores the move counter from an FEN Nevertheless I propose to everyone to fix it if possible since it is kind of a trivial issue, which includes also fixing it in WB itself (for the case where the user pastes an FEN with Ctrl-V). I see no compatibility problem when doing this bugfix.


3) So now my conclusion, where most of it has already been said:

- Leave the spec as it is now, with the exception that the implications of multiple "level" commands still are on open point for me (but not within the scope of the problem discussed here).

- Continue using "time" with every move.

- Fix (WB and) engines regarding their move counter handling when receiving "setboard". This would make the discussed problem go away already IMO.

- Accept that the time utilization of engines where that move counter problem can't be fixed or won't be fixed may remain "not optimal", i.e. accept that this is their own problem, not one of the specs (WB/PGN).


Best regards,
Sven

[H.G.Muller]

The problem is that any change we make here should not break compatibility with existing engines. And your proposed solution misses an important point: even if we would fix WinBoard, plus all existing WinBoard engines, it might mean that no WinBoard engine runs correctly under other GUIs that support WB protocol.

Currently WinBoard does transmit its own idea of the move number in the FEN included in the setboard command. It does ignore the move number in input FENs, though: when playing from a loaded position he first move is always considered move number 1, and in classical time controls, the new time quota are awarded accordingly.

It would be easy enough for me to let WB remember the move number of the initial position, and use it as an offset in the decision when to award new time quota, and add it to its internal move number when it sends a setboard to the engine.. (I already implemented a similar thing for the 50-move counter.) This would open up the possibility that a lot of existing engines cease to function properly if they receive a FEN where te move number is different from 1 (as WB currently never does this). But the user can work around that, if needed, by only loading FENs with move number 1 into WB.

But before I change anything, I would want to know how other GUIs handle this situation, as it is better to handle it the wrong but same way as others, than to do it correctly but differently. Engine authos should not be presented with unsolvable incompatibilities. An additional worry is that many existing engines use protocol v1, or v2 with feature setboard=0 (which is perfectly allowed, WB will use the edit command to set up a position in that case). Such engines cannot receive a move number at all.

All this does not solve the force problem, however, and this is by far the more important problem. Usually one plays from a game file, not a position file, and then the moves are forced into the engine. An external opening book has the same effect as a game file.

I do realize the accuracy of the level command is worse than that of the time command, but your calculation is wrong. Except in sub 10-sec games this would almost entirely remain without measurable effects. If on the initial moves the time is rounded down, the engine will play faster because of this. WinBoard does measure the actual time used by the engine in msec, and what the engine saved by playing faster will accumulate on the WB clock until it is more than a second, after which the engine will become aware of it. So an engine will never be short-changed by more than a second for its first TC session, and what it gets too little will be added to its next session. This is far less damaging (even at 40/0:10) than the current behavior of wrongly counting engines.

But the problem can actually be solved entirely by sending the level command immediately before every time command, The precise time given in the latter will then overrule the approximate time given by the former. That this might not work for ever engine is not a valid objection at all. Even if it would work for only a single one, it would be a useful work-around to have available.

[Sven Schüle]

Harm,

you are right when stating that the problem of wrong move counting in force mode is more important than that of ignoring the move counter in an FEN. My proposal is of course to fix both, which includes the more important one. My posting focussed on the FEN part which might have been misleading.

You are also right that my calculation concerning the difference between "level" and "time" may be slightly wrong. Nevertheless the approach of replacing "time" (with centiseconds resolution) by "level" (with seconds resolution) sounded very dubious to me. I don't know whether your new proposal of sending "level" just before each "time" command does any better. In fact it seems to be even more confusing: which one of the two commands tells the engine about the available remaining time, "level" or "time"?

Why not keep everything as simple as it is? Not counting moves correctly is a bug, that's all. My general rule for the kind of software we are dealing with would be here: don't introduce one ugly workaround instead of fixing one bug N times. We are not on industry level.

Also I do not understand your statement about other GUIs. Fixing move counting problems in some engines should not introduce new problems with other GUIs since they obviously deal correctly with engines that do not have that move counting problem. And you would have to show any engine that does *not* ignore the move counter in an FEN but *ceases to work correctly* when given something different from 1 here.

The main problem with your proposal that remains for me is that the reaction of existing engines to receiving multiple "level" commands is unknown yet and may be very different.

So make an experimental WB version that sends this additional "level" command before each "time". Then choose, say, ten arbitrary WB engines by random from the whole spectrum (say, ELO 1600-2500) and test their reaction on that.

Sven

[H.G.Muller]

But why would you send level commands bfore the time commands to engines that work correctly? That is just asking for trouble. Only do it to the engines that need it and like it.

I don't share your worries about which time would prevail, from the level or the later time command. I think it is an extremely safe bet that there is not a single engine in the World that would say, on reception of a time command "hey, let's ignore this, because some time ago I received another time or level command that said I had more time! So I will keep using that old time in stead." The whole idea of the time command is that it forces the engines clock.

I share your doubts about catering too much to defective engines. But there are tournament managers that would go to extreme length to run as many dfferent engines as possible, even buggy ones, and if it helps them to achieve their goals if I add a smple kludge, I do consider it worthwile. If it does not hurt anything else, of course, which does not seem the case here.

Of course th fact that I was already planning to send level commands to engines during a game for the purpose of implementing multi-session time controls mkes me even more willing to consider suc a kludge.

My main point was this: If other GUIs would sent a FEN to the engine with move number 5 (say), but still award new quota at move 45, 85, etc. (in 5/40, say), but WinBoard would would award the time quota at 40, 80, etc. it would not be possible to make an engine that woud run correctly on both, as they would expect to get extra time (greedily using up all the time they had before) at a moment when they will get none, and then have to do 35 moves in near-zero time.

[Sven Schüle]

But why would you send level commands bfore the time commands to engines that work correctly? That is just asking for trouble. Only do it to the engines that need it and like it.

Many would need it but probably only few would like the additional "level" commands, that's my feeling at least. So even if you implement it as an option then some of these engines might get into trouble by that. This is what I wanted you to try: how many engines with the move counting problem could live with it and not run into other problems. Perhaps not by choosing engines by random as I suggested but by choosing those that appear to have that move counting problem.

I don't share your worries about which time would prevail, from the level or the later time command. I think it is an extremely safe bet that there is not a single engine in the World that would say, on reception of a time command "hey, let's ignore this, because some time ago I received another time or level command that said I had more time! So I will keep using that old time in stead." The whole idea of the time command is that it forces the engines clock.

So you say that the time from the "time" command would always prevail. That's fine and what I would expect. But then, what should be the idea of the additional "level" command right before "time"? Only for updating the move counter? Wouldn't that be confusing for programmers?

I share your doubts about catering too much to defective engines. But there are tournament managers that would go to extreme length to run as many dfferent engines as possible, even buggy ones, and if it helps them to achieve their goals if I add a smple kludge, I do consider it worthwile. If it does not hurt anything else, of course, which does not seem the case here.

If an engine plays weaker due to a bug that leads to bad time management but not to time losses, then why should this affect a TD? The problem is not caused by the GUI but by the engine itself, and time management issues and bugs in general are part of the playing strength.

My main point was this: If other GUIs would sent a FEN to the engine with move number 5 (say), but still award new quota at move 45, 85, etc. (in 5/40, say), but WinBoard would would award the time quota at 40, 80, etc. it would not be possible to make an engine that woud run correctly on both, as they would expect to get extra time (greedily using up all the time they had before) at a moment when they will get none, and then have to do 35 moves in near-zero time.

If other GUIs have the same problem and you refuse to be the first GUI that fixes it, why would other GUIs like to be the first ones? So just do it, be the first one, and the others will follow. Fixing such a problem is not expensive at all, not for anyone.

Sven

[H.G.Muller]

Many would need it but probably only few would like the additional "level" commands, that's my feeling at least.

Why do you think that? There are only two obvious wy to implement classical time controls:
The first is a counter (movesLeft) that is initialized at the level MPS parameter, and counting down, ading MPS when it reaches zero, and using a target time per move approximately equal to timeRemaining/movesLeft. Such engines would interpret the intra-game level commands without problems.
The second way is to count move number up starting from zero, and compare it to the next-larger multiple of MPS to know how many moves you still have to do, in order to calculate target time. On such engines the proposed scheme would fail. But to handle those I have added the options /...AccumulateTC (... = first or second). With this option set, the intra-game level commands would not use the moves left in the current session, but in stead send the move number of the next time control, adding the tim of all time controls upto then to use as time parameter. So at move 65 in a 40/5 game they would send level 80 10 0, so the engine would start behaving like it was in an 80/10 game.
I would be surprised if these two modes together would not capture 90%+ of all existing engines.

So even if you implement it as an option then some of these engines might get into trouble by that. This is what I wanted you to try: how many engines with the move counting problem could live with it and not run into other problems. Perhaps not by choosing engines by random as I suggested but by choosing those that appear to have that move counting problem.

I will leave that to others, who have a shorter to-do list...

So you say that the time from the "time" command would always prevail. That's fine and what I would expect. But then, what should be the idea of the additional "level" command right before "time"? Only for updating the move counter? Wouldn't that be confusing for programmers?

Exactly, it would only serve to update the move counter. Programmers cannot possibly be confused, as they are not involved at all. If programmers were involved, they should fix the problem in their engine. The kludge serves only to handle existing programs no longer under development.

Furthermore, I doubt your point: If programmers would be confused by this, they would be confused already: WinBoard always first sends a level command, and then a time command, on the first move. The TC parameter in the level command is totaly redundant!

If an engine plays weaker due to a bug that leads to bad time management but not to time losses, then why should this affect a TD? The problem is not caused by the GUI but by the engine itself, and time management issues and bugs in general are part of the playing strength.

I guess Kiril should answer this...

If other GUIs have the same problem and you refuse to be the first GUI that fixes it, why would other GUIs like to be the first ones? So just do it, be the first one, and the others will follow. Fixing such a problem is not expensive at all, not for anyone.

That is an optimistic view. If the other GUIs and most engines would goof in collusion, people would more likely stop using the one that fixed it. It is extremely difficult to eradicate design rrors that have become de-facto standards. (Like Intel CPUs...)

P.S. WinBoard 4.3.15 does recognize any KBBB...KBBB... with all like B as draws now.

[Sven Schüle]

Many would need it but probably only few would like the additional "level" commands, that's my feeling at least.

Why do you think that? There are only two obvious wy to implement classical time controls:
The first is a counter (movesLeft) that is initialized at the level MPS parameter, and counting down, ading MPS when it reaches zero, and using a target time per move approximately equal to timeRemaining/movesLeft. Such engines would interpret the intra-game level commands without problems.
The second way is to count move number up starting from zero, and compare it to the next-larger multiple of MPS to know how many moves you still have to do, in order to calculate target time. On such engines the proposed scheme would fail. But to handle those I have added the options /...AccumulateTC (... = first or second). With this option set, the intra-game level commands would not use the moves left in the current session, but in stead send the move number of the next time control, adding the tim of all time controls upto then to use as time parameter. So at move 65 in a 40/5 game they would send level 80 10 0, so the engine would start behaving like it was in an 80/10 game.
I would be surprised if these two modes together would not capture 90%+ of all existing engines.

You assume that everyone already follows your new definition of the "level" semantics. I doubt that. In the original definition the first parameter was "moves per session", now you want it to be read as "moves left in this session". And an engine that has a move counting problem in force mode and/or when receiving an FEN will most probably also not update its move counter when receiving an additional "level" command.

Furthermore, I doubt your point: If programmers would be confused by this, they would be confused already: WinBoard always first sends a level command, and then a time command, on the first move. The TC parameter in the level command is totaly redundant!

That's wrong IMO, it is not always redundant. First of all it is optional for engines whether they support "time" or not. Although it may be better to support it, there are some engines that don't. Second, I already mentioned the different resolutions (seconds vs. microseconds).

To be clear: I do not say that the time control part of the WB protocol is near to perfect. But I don't think you improve it by introducing a new complexity with that changed semantics of the "level" command.

P.S. WinBoard 4.3.15 does recognize any KBBB...KBBB... with all like B as draws now.

That lets me believe that you will eventually follow my advice, despite your desperate attempts to avoid it

Sven

[H.G.Muller]

You assume that everyone already follows your new definition of the "level" semantics. I doubt that. In the original definition the first parameter was "moves per session", now you want it to be read as "moves left in this session". And an engine that has a move counting problem in force mode and/or when receiving an FEN will most probably also not update its move counter when receiving an additional "level" command.

I am assuming no such thing, I am just talking about the way an engine handles the level command given at the beginning of each game. What you say is extremely unlikely: it would require that the engine programmer would have added special code in the processing of the level command to test if the game has already started, and treat the level command differently in that case. Why would they do that? What would be their motivation to treat an intra-game level command differently anyway? That it never occurs? The protocol discription does not guarantee or even suggest that anywhere. And if they do realize that it never occurs, why would they still bother? Do you have such special treatment of an intra-game level command in your engine?

That's wrong IMO, it is not always redundant. First of all it is optional for engines whether they support "time" or not. Although it may be better to support it, there are some engines that don't. Second, I already mentioned the different resolutions (seconds vs. microseconds).

Well, the latter point would not make it less redundant, as it has the lower resolution of the two. And because engines might indeed not support the time command I would take care that the TC parameter of the level command is the most accurate approximation of that of the time command that could follow it.

So such engines would have to do with a less accurate estimate of the time left. This is inherent in not supporting the time command, thir own internal clock might be aff too, due to communication or scheduling delays. So it does not matter much if they use ther own internal clock or the time given in the level command.

To be clear: I do not say that the time control part of the WB protocol is near to perfect. But I don't think you improve it by introducing a new complexity with that changed semantics of the "level" command.

IMO the semantics is not changed. What was according to you the old semantics for a level command? I think it has always been: "start playing a game with the specified time control from the current position". The protocol document never specified that it could not be sent during a game.

That lets me believe that you will eventually follow my advice, despite your desperate attempts to avoid it

This is why I mentioned it. For a large part I am just playing Devil's advocate, because I think that any change has to be well though through (or we would get hack upon hack).

But tell me, how would you implement multi-session time controls so that it would work in most existing WinBoard engines? If your answer is "can't be done", than I am likely to think my way of doing it is superior, no matter how many formal objections you briing up against it. Sending a new level command at the beginning of each session (only if it has different MPS from the previous) seems by far the best way to achieve this.

Did you know that WinBoard 4.3.14 already supports multi-session TC in its clock handling? Try running it with the parameters

/movePerSession=20 /timeControl="5+20/1+0:30"

You will then see a first session (with 20 moves) of 5 min, a second session of another 20 moves in 1 min, while the remainder of the game would have to be completed in 30 sec. (Of course the engine will not realize the latter, and think that the 30 sec is also for 20 moves, as I do not send any intra-game level commands yet.

[Sven Schüle]

You assume that everyone already follows your new definition of the "level" semantics. I doubt that. In the original definition the first parameter was "moves per session", now you want it to be read as "moves left in this session". And an engine that has a move counting problem in force mode and/or when receiving an FEN will most probably also not update its move counter when receiving an additional "level" command.

I am assuming no such thing, I am just talking about the way an engine handles the level command given at the beginning of each game. What you say is extremely unlikely: it would require that the engine programmer would have added special code in the processing of the level command to test if the game has already started, and treat the level command differently in that case. Why would they do that? What would be their motivation to treat an intra-game level command differently anyway? That it never occurs? The protocol discription does not guarantee or even suggest that anywhere. And if they do realize that it never occurs, why would they still bother? Do you have such special treatment of an intra-game level command in your engine?

It is the other way round. There is no such special handling of intra-game "level" commands, the handling is always the same: the first of three numbers determines the number of moves per session counted from the beginning of the game. WB engines subtract the number of moves already played from that number to get the number of moves left until next time control. So if they always count the number of moves from ply 0 then this means that they do *not* read the first argument of "level" as number of moves counted from the *current position*. I am pretty sure that this has always been the only intent of the WB protocol specifiers for "level". As an example, I also checked the source code of three native WB engines: Delfi, Crafty, Romichess to verify that they handle it as I expected.

As a consequence, I think the following could happen for example: an engine receives "level 40 40 0", then thinks a minute for its move (let's forget opening books for a moment), then receives "level 39 39 0" which means it has total 39 minutes for total 39 moves from which 1 minute for 1 move has already passed; and so on, until it receives "level 20 20 0" after it has already spent 20 minutes for 20 moves. So what should the engine do now? According to its last info the time control was defined at move 20, so it adds another 20 minutes for the next 20 moves. But is that intended?

To be clear: I do not say that the time control part of the WB protocol is near to perfect. But I don't think you improve it by introducing a new complexity with that changed semantics of the "level" command.

IMO the semantics is not changed. What was according to you the old semantics for a level command? I think it has always been: "start playing a game with the specified time control from the current position". The protocol document never specified that it could not be sent during a game.

See above.

But tell me, how would you implement multi-session time controls so that it would work in most existing WinBoard engines? [...]

The multi-session topic may be related to what we discuss here but at least your proposal to optionally send intra-game "level" commands to some engines is something different from the multi-session feature which is definitely desired to have, so I would prefer to leave it out of this discussion.

Sven

[H.G.Muller]

It is the other way round. There is no such special handling of intra-game "level" commands, the handling is always the same: the first of three numbers determines the number of moves per session counted from the beginning of the game. WB engines subtract the number of moves already played from that number to get the number of moves left until next time control. So if they always count the number of moves from ply 0 then this means that they do *not* read the first argument of "level" as number of moves counted from the *current position*.

So basically you are saying that some engines might nor reset their move counter on receipt of a level command, but do it on a new command. (They must reset it somewhere...) Well, for such engines there is no fix unless WinBoard would explicitly count how many of the moves were forced into it, as the number of moves they will assume they have to do in the remaining time will depend on their own internal idea of the number of moves they have already done.

I am pretty sure that this has always been the only intent of the WB protocol specifiers for "level". As an example, I also checked the source code of three native WB engines: Delfi, Crafty, Romichess to verify that they handle it as I expected.

But these are engines that work correctly. So it is not very relevant how they would react to a command that would only be sent to broken engines.

As a consequence, I think the following could happen for example: an engine receives "level 40 40 0", then thinks a minute for its move (let's forget opening books for a moment), then receives "level 39 39 0" which means it has total 39 minutes for total 39 moves from which 1 minute for 1 move has already passed; and so on, until it receives "level 20 20 0" after it has already spent 20 minutes for 20 moves. So what should the engine do now? According to its last info the time control was defined at move 20, so it adds another 20 minutes for the next 20 moves. But is that intended?

This is indeed not intended. The proper fix here would be to re-send them a level command with the original MPS minus the number of book moves, each time they get out of (the GUI) book. And send a new level command at the beginning of each time control adding all MPS parameters of the previous sessions, and subtracting the book moves. A third tcKludgeMode could work that way.

But I don't understand the logic behind your objections. They seem to be based on the hilosophy: "because it does not work always, we should not do it". This is contrary of my philosophy: "even if it works only once, it might be worth it". The cases for which it doesn't work can perhaps be fixed in another way.

The multi-session topic may be related to what we discuss here but at least your proposal to optionally send intra-game "level" commands to some engines is something different from the multi-session feature which is definitely desired to have, so I would prefer to leave it out of this discussion.

But we can't, as it is identically the same problem: You have to make the engine aware that it has to last on the current time on its clock for a different number of moves than it is currently thinking. Discuss one, and you are discussing the other. Anyway, for the engines you describe the /%sAccumulateTC would result in the desired effect: By sending the sum of all earlier sessions including the immediately following one would reset their internal MPS notion in such a way that they expect the next time quota at the move where it will indeed come.