Suggestion for GUI developers

[Jose Carlos]

First of all, if this feature already exsist, I apologize for asking it, and would thank if you could tell me what GUI implements it.

The idea: some engines do lose on time some games, specially in fast time controls. One old program of me (which source code I lost) has this problem, and I can't fix it. My proposal is that the GUIs implement an option to send a "move now" command when time is almost finished (it could be 1 tenth of a second, or something the user could configure). Some games would still be lost on time due to polling frecuency, but I guess the number would reduce dramatically.

Is this idea interesting for anyone else? Is it hard to implement in current chess GUIs?

Thanks in advance.

[Don]

First of all, if this feature already exsist, I apologize for asking it, and would thank if you could tell me what GUI implements it.

The idea: some engines do lose on time some games, specially in fast time controls. One old program of me (which source code I lost) has this problem, and I can't fix it. My proposal is that the GUIs implement an option to send a "move now" command when time is almost finished (it could be 1 tenth of a second, or something the user could configure). Some games would still be lost on time due to polling frecuency, but I guess the number would reduce dramatically.

Is this idea interesting for anyone else? Is it hard to implement in current chess GUIs?

Thanks in advance.

I cannot think of any reason for this to happen except by some sort of communication overhead issues - in which case I don't think you can solve it with a move now command.

The faster the time control, the more often I see time losses from all the common programs. If you are playing game in 5 seconds, you get down to some fraction of a second but you can never get down beyond the resolution of the communication between the engine and interface and every program has a start-up cost. For Komodo it is the time required to generate a set of moves and do a one ply search plus a very brief initialization of a couple of small data structures.

Imagine however that some background process temporarily causes few millisecond delay - at game in 5 seconds it might be the equivalent of a 10 second delay at tournament time controls.

My tester is capable of playing several games per second on several cores, but there are still a few critical sections that can cause slight delays which get charged against the program.

Even if you trust the time reported by the program itself (which opens up another can of worms) you have the same problem.

There is something that an interface could do to minimize the problem - something I do in my go server cgos. I have a configurable "time gift" which is a very small amount of time that is added to each programs clock to compensate for network lag. It's not fair nor does it pretend to be because a program running on a faster network will benefit more from it - but it does help avoid time losses - programs that play instantly were losing on time anyway simply because the connection was slow.

The time added is not Fischer time, if you are granted 1/10 of a second as a "gift" and play instantly you are not credited. You only get credited once the time you take plus the gift subtracted is zero or more, so the first N milliseconds are free.

[Jose Carlos]

First of all, if this feature already exsist, I apologize for asking it, and would thank if you could tell me what GUI implements it.

The idea: some engines do lose on time some games, specially in fast time controls. One old program of me (which source code I lost) has this problem, and I can't fix it. My proposal is that the GUIs implement an option to send a "move now" command when time is almost finished (it could be 1 tenth of a second, or something the user could configure). Some games would still be lost on time due to polling frecuency, but I guess the number would reduce dramatically.

Is this idea interesting for anyone else? Is it hard to implement in current chess GUIs?

Thanks in advance.

I cannot think of any reason for this to happen except by some sort of communication overhead issues - in which case I don't think you can solve it with a move now command.

The faster the time control, the more often I see time losses from all the common programs. If you are playing game in 5 seconds, you get down to some fraction of a second but you can never get down beyond the resolution of the communication between the engine and interface and every program has a start-up cost. For Komodo it is the time required to generate a set of moves and do a one ply search plus a very brief initialization of a couple of small data structures.

Imagine however that some background process temporarily causes few millisecond delay - at game in 5 seconds it might be the equivalent of a 10 second delay at tournament time controls.

My tester is capable of playing several games per second on several cores, but there are still a few critical sections that can cause slight delays which get charged against the program.

Even if you trust the time reported by the program itself (which opens up another can of worms) you have the same problem.

There is something that an interface could do to minimize the problem - something I do in my go server cgos. I have a configurable "time gift" which is a very small amount of time that is added to each programs clock to compensate for network lag. It's not fair nor does it pretend to be because a program running on a faster network will benefit more from it - but it does help avoid time losses - programs that play instantly were losing on time anyway simply because the connection was slow.

The time added is not Fischer time, if you are granted 1/10 of a second as a "gift" and play instantly you are not credited. You only get credited once the time you take plus the gift subtracted is zero or more, so the first N milliseconds are free.

I think the source of problems of my old program is the way it measures time, probably not the best/accurate. In this case (I guess) my old program thinks it still has some time when it does not. That's why I figured out the idea of the GUI giving a helping hand by saying "hey, you; time is up, move now!".

As I write this, I also think of a mixture of your idea and mine: once the GUI has issued the "move now" command, it might stop its internal clock in the understanding that the time it takes the answer to return from the engine is nothing but a communication delay.

I don't know if this also happens to other programs. Don't forget I'm not speaking of top programs like yours, perfectly debugged, but about amateur programs with lots of little bugs that show up from time to time.

[Don]

I don't know if this also happens to other programs. Don't forget I'm not speaking of top programs like yours, perfectly debugged,

You must be talking about someone else's program

... but about amateur programs with lots of little bugs that show up from time to time.

With "time" there is always going to be some inconsistencies to deal with.

[hgm]

It seems completely pointless to me. Polling for input is not any faster than reading the clock. If your program does not read the clock in time to prevent a time loss, it would not notice the 'move now' command either.

WinBoard offers a mode where the engine is responsible for the time measurements. (I.e., the clock is decreased by the amount of time the engine reports it has been thinking, which is supposed to be CPU time in that case.) This seems a better solution. But of course it allows large-scale cheating.

[Jose Carlos]

It seems completely pointless to me. Polling for input is not any faster than reading the clock. If your program does not read the clock in time to prevent a time loss, it would not notice the 'move now' command either.

WinBoard offers a mode where the engine is responsible for the time measurements. (I.e., the clock is decreased by the amount of time the engine reports it has been thinking, which is supposed to be CPU time in that case.) This seems a better solution. But of course it allows large-scale cheating.

Cheating is no problem in the context I'm thinking about (own testing at home). I'll try that wb option you mention.

If Don and you both consider it pointless, you must be right, but I still think it makes sense, at least with the modification I comment in my response to Don: the GUI sends "move now" when the time is about to run out; then, the GUI stops its internal clock and waits for the engine to answer, assuming that time will be communication delay. If it takes too much time for the engine to answer, it must be hung or something.

Of course, this opens the door for more cheating, but that's not what I have in mind...

[hgm]

If you are prepared to stop the clock to prevent the engine from losing on time, you might as well switch auto-flag off...

[Don]

It seems completely pointless to me. Polling for input is not any faster than reading the clock. If your program does not read the clock in time to prevent a time loss, it would not notice the 'move now' command either.

WinBoard offers a mode where the engine is responsible for the time measurements. (I.e., the clock is decreased by the amount of time the engine reports it has been thinking, which is supposed to be CPU time in that case.) This seems a better solution. But of course it allows large-scale cheating.

Cheating is no problem in the context I'm thinking about (own testing at home). I'll try that wb option you mention.

If Don and you both consider it pointless, you must be right, but I still think it makes sense, at least with the modification I comment in my response to Don: the GUI sends "move now" when the time is about to run out; then, the GUI stops its internal clock and waits for the engine to answer, assuming that time will be communication delay. If it takes too much time for the engine to answer, it must be hung or something.

But you should consider that your solution just disguises another more serious problem. If you make the program play immediately just to avoid losing on the clock, it will probably lose due to poor time control management anyway and you still haven't really solved the issue of internal and unpredictable overheads which could cause you to lose anyway!

Of course, this opens the door for more cheating, but that's not what I have in mind...