problematic time management

[flok]

Hi,

I'm trying to get my engine run on H.G. Muller's ics server.
Most of the time it works, but occasionally I get:

Code: Select all

DeepBrutePos forfeits on time

which is strange as for example after moving the last move I got back from xboard:

Code: Select all

>ICS: kibitz !!! -15.55/9 (1.11 sec, 29126 nodes, 26 knps) PV=E8-D8\012

and if I interprete this correctly, this means that I had 1.11 seconds left?
So what is happening?
Is there maybe an extra time-limit?

[bob]

Hi,

I'm trying to get my engine run on H.G. Muller's ics server.
Most of the time it works, but occasionally I get:

Code: Select all

DeepBrutePos forfeits on time

which is strange as for example after moving the last move I got back from xboard:

Code: Select all

>ICS: kibitz !!! -15.55/9 (1.11 sec, 29126 nodes, 26 knps) PV=E8-D8\012

and if I interprete this correctly, this means that I had 1.11 seconds left?
So what is happening?
Is there maybe an extra time-limit?

That means you TOOK 1.11 seconds to make your move...

[flok]

I'm trying to get my engine run on H.G. Muller's ics server. Most of the time it works, but occasionally I get:

Code: Select all

DeepBrutePos forfeits on time

which is strange as for example after moving the last move I got back from xboard:

Code: Select all

>ICS: kibitz !!! -15.55/9 (1.11 sec, 29126 nodes, 26 knps) PV=E8-D8\012

and if I interprete this correctly, this means that I had 1.11 seconds left?
So what is happening?
Is there maybe an extra time-limit?

That means you TOOK 1.11 seconds to make your move...

That's...odd. Because on the screen I see xboard counting from 12 to 0 and in my logging I see it calculating for 11.838 seconds?

Is it possible to loose when it tells you you have 12 seconds to calculate (TIME 12 send by xboard) and you use 12,1 seconds?
Or does this "forfeits on time" mean your total time for the whole game is up?

[bob]

I'm trying to get my engine run on H.G. Muller's ics server. Most of the time it works, but occasionally I get:

Code: Select all

DeepBrutePos forfeits on time

which is strange as for example after moving the last move I got back from xboard:

Code: Select all

>ICS: kibitz !!! -15.55/9 (1.11 sec, 29126 nodes, 26 knps) PV=E8-D8\012

and if I interprete this correctly, this means that I had 1.11 seconds left?
So what is happening?
Is there maybe an extra time-limit?

That means you TOOK 1.11 seconds to make your move...

That's...odd. Because on the screen I see xboard counting from 12 to 0 and in my logging I see it calculating for 11.838 seconds?

Is it possible to loose when it tells you you have 12 seconds to calculate (TIME 12 send by xboard) and you use 12,1 seconds?
Or does this "forfeits on time" mean your total time for the whole game is up?

If you get a time command something like "time 1200" and you take 12.1 seconds, yes you lose on time. You can't go beyond 12.0... there is no grace period.

There are very small delays built in. For example, you send xboard a "move xxx" command, xboard is most likely sitting there blocked, waiting on something from someone. When you send that move command, until xboard actually gets its hand on the message, YOUR clock is still running. board has to be unblocked, and then the process scheduler has to context switch to that process. That takes time. You should never try to use 100% of your time left, for this reason...

Most of us keep some sort of fudge factor to avoid this.

[hgm]

Note that if you are playing on an ICS XBoard is just passively relaying the traffic between ICS and engine, and that it the ICS that really decides whether to forfeit you or not. If you use timeseal, the ICS delegates the measuring of the time you have been thinking to timeseal, however, which runs on your own computer, and thus should not be affected by network delays.

There still will be a communication delay between your engine and XBoard, and between XBoard and timeseal, however. (These communicate through pipes.) This can get worse if your engine soaks up all available CPU time, competing at the same priority with the XBoard and timeseal processes. For that reason things often work more smoothly when you run the engine at a slightly lower priority. The option -niceEngines 10 in the XBoard command would take care of that, and issues the Linux nice() system call on the engine processes it spawns.

[sje]

There still will be a communication delay between your engine and XBoard, and between XBoard and timeseal, however. (These communicate through pipes.) This can get worse if your engine soaks up all available CPU time, competing at the same priority with the XBoard and timeseal processes. For that reason things often work more smoothly when you run the engine at a slightly lower priority. The option -niceEngines 10 in the XBoard command would take care of that, and issues the Linux nice() system call on the engine processes it spawns.

This helps, but there can still be a problem on systems which use hyper threading. For example, say you have your engine and Xboard running on a dual core machine with four hyperthreads. At 03:00 hours, the O/S launches a daily maintenance routine to run some CPU hogging task at low priority. The scheduler thinks it has more physical cores than really exist, so it gives CPU time to the maintenance task as if it were running at the same, higher priority as the engine (or Xboard).

As Bob mentioned, most authors use a fudge factor. Assuming at least several centiseconds of delay per move is prudent.

[Modern Times]

I played your engine on a 5+1 time control. It used 5 minutes on the first move out of book, and then just had the 1 second increment for the rest of the moves. It then lost on time.

[hgm]

[The scheduler thinks it has more physical cores than really exist, so it gives CPU time to the maintenance task as if it were running at the same, higher priority as the engine (or Xboard).

That would not really matter, would it? Processes running on the same HT of a physical core will never block each other, they would just slow each other down (by 30% or so). As the task of passing on the message is hardly an effort, doing it at 0.7x nominal speed will only cause micro-second delay. The only thing what hurts is if the OS decides to not run the GUI (or timeseal) at all for the 10msec (say) that it takes the processes currently occupying the hyper threads to finish their time slice. If the latter have lower priority, they will be kicked off the virtual core instantly when a process of higher priority wakes up from its blocking I/O call.

[Sven]

I'm trying to get my engine run on H.G. Muller's ics server. Most of the time it works, but occasionally I get:

Code: Select all

DeepBrutePos forfeits on time

which is strange as for example after moving the last move I got back from xboard:

Code: Select all

>ICS: kibitz !!! -15.55/9 (1.11 sec, 29126 nodes, 26 knps) PV=E8-D8\012

and if I interprete this correctly, this means that I had 1.11 seconds left?
So what is happening?
Is there maybe an extra time-limit?

That means you TOOK 1.11 seconds to make your move...

That's...odd. Because on the screen I see xboard counting from 12 to 0 and in my logging I see it calculating for 11.838 seconds?

Is it possible to loose when it tells you you have 12 seconds to calculate (TIME 12 send by xboard) and you use 12,1 seconds?
Or does this "forfeits on time" mean your total time for the whole game is up?

Hi Folkert,

please note that the "time" command tells you how many centiseconds are left in total for your engine until the next time control, and that you need to keep track of the number of remaining moves until then. The latter is in contrast to UCI where the engine usually will be informed about the number of remaining moves with the "movestogo" parameter.

Don't forget to increment the number of remaining moves by 40 (resp. the number of moves per period configured with the "level" command) after passing a time control.

For more details, see also the WB protocol spec.

Sven

[sje]

Processes running on the same HT of a physical core will never block each other, they would just slow each other down (by 30% or so). As the task of passing on the message is hardly an effort, doing it at 0.7x nominal speed will only cause micro-second delay. The only thing what hurts is if the OS decides to not run the GUI (or timeseal) at all for the 10msec (say) that it takes the processes currently occupying the hyper threads to finish their time slice. If the latter have lower priority, they will be kicked off the virtual core instantly when a process of higher priority wakes up from its blocking I/O call.

Yes, but it's not just the communication work which is affected and the slowdown factor is closer to 50%. The maintenance process is going to soak CPU time from the chess program search, too.

One approach is to disable hyperthreading in the machine before the O/S is booted. But this doesn't work all machines and in fact causes Linux to crash on my old Pentium 4 box.

Internally, Symbolic measures all time values, both epochs and intervals, with microsecond resolution. Because the program can efficiently and accurately check the elapsed time at each search node, it can "stop on a dime" and so handles the worst case time delay with reporting the move.

Perhaps the centisecond resolution of Xboard (and whatever UCI uses) which was sufficient for the Old Days needs to be adjusted for the New Days. I would suggest millisecond resolution or even microsecond resolution; even better might be supplying a floating point value seconds count with at least six digits of significance.