Coordination of Time Controls

[beneficii]

Sometimes, when my engine plays computer chess, its time control becomes disconnected from WinBoard's time control and that causes the engine to make bad decisions. What are the best ways to protect against this?

[H.G.Muller]

I really have no idea what you are doing, (e.g. ICS zippy play, human-engine, engine-engine) and what your exact problem is. Is "bad decisions" that it forfeits on time? How can WinBoard's clock and that of the engine get 'disconnected' if they read the same system clock?

[beneficii]

I really have no idea what you are doing, (e.g. ICS zippy play, human-engine, engine-engine) and what your exact problem is. Is "bad decisions" that it forfeits on time? How can WinBoard's clock and that of the engine get 'disconnected' if they read the same system clock?

Good questions. This is for engine-engine. As for the disconnect, I saw it occur most of the time when the computer goes to sleep while the engines are playing, and only once where one engine took too long to move.

[H.G.Muller]

With "to sleep" you mean things like suspend or hibernate? Things cannot be expected to work in such modes. All programs are stopped then, but the clocks keep running, because WinBoard reads wall-clock time.

[beneficii]

With "to sleep" you mean things like suspend or hibernate? Things cannot be expected to work in such modes. All programs are stopped then, but the clocks keep running, because WinBoard reads wall-clock time.

Thanks. Yes. That's when you leave the laptop running without moving the mouse and it goes to like a power save mode. I find that the clock disconnects happen the most. I can notice it in the time controls that are displayed in WinBoard. I use the time control where every x moves the original time is added back to the clock, and the engines use 1/x * time - small value to make their move, so under normal conditions after black moves and before the clock starts for white, white and black will have the exact same amount of time left. But after the laptop goes into power save mode, I notice on the WinBoard time controls displayed in the GUI that one engine has a lot more time left than another engine, but apparently at least one of the instances of my engine does not agree with WinBoard about how much time is left and its flag ends up dropping because it thinks it has more time than WinBoard says it has.

Is there some way to restore the coordination in these circumstances, such as having the engine request after each move that WinBoard sends it the updated time?

[H.G.Muller]

Well, WinBoard send the time the engine still has on its clock before every move it sends. (The time command.) If your engine would pay attention to that, the problem you sketch should not occur.

The engine should also be able to see it himself, for the move it is working on when it gets suspended. Just be sure that to ask the system how long italready has been thinking it asks for the wall-clock time (e.g. GetTickCount), and not for CPU time.

[beneficii]

Well, WinBoard send the time the engine still has on its clock before every move it sends. (The time command.) If your engine would pay attention to that, the problem you sketch should not occur.

The engine should also be able to see it himself, for the move it is working on when it gets suspended. Just be sure that to ask the system how long italready has been thinking it asks for the wall-clock time (e.g. GetTickCount), and not for CPU time.

Duh. That was my bad.

My engine does use GetTickCount() and it does respond respond to the time and otim commands by setting the appropriate time control.

To provide context, only once where the computer did not go to sleep did I have a problem with the time control; every other time the computer did not go to sleep, and this is probably dozens of times, the engine worked fine with WinBoard. It's just those random pieces.

Perhaps, I should better organize my time control class, and use a more object-oriented techinque for keeping track of the time to minimize errors and to better handle overflow of GetTickCount() (i.e. when it wraps back around)? My time controls already handle it, but the style I used was to rewrite the code over and over again.

I shall do that and return.

Thanks.

[H.G.Muller]

In my engines I always use (GetTickcount() - startTickCount) to compare against the pre-calculated thinking-time limits (rather than calculating absolute time targets). This should intrinsically be insenstive to tick-count wrap-around, as the width of the tick count isthe same as that of int.