I've been playing with the new release of xboard (Thanks H.G. for this release) to run fast match between my engine and a couple of other engines.
I wanted to run really fast games in wich engines start with 10 seconds on the clock and then get 0.1s increments after each moves. This is, I think, similar to what Dr. Hyatt is doing. H.G.M. suggested I use --firstTimeOdds and --secondTimeOdds to describe a time control with sub second increment. I did it like this :
The engines get informed about the time control with the command "level 0 0:10 0" so they know that the base time is 10 seconds, but they don't know they'll get a 0.1 second increment. Obviously this is expected since the Winboard protocol doesn't define a way to tell engines that they get a sub second increment.
So my questions are : Is there any way around this? And how does Dr Hyatt run 10+0.1s match?
I've been playing with the new release of xboard (Thanks H.G. for this release) to run fast match between my engine and a couple of other engines.
I wanted to run really fast games in wich engines start with 10 seconds on the clock and then get 0.1s increments after each moves. This is, I think, similar to what Dr. Hyatt is doing. H.G.M. suggested I use --firstTimeOdds and --secondTimeOdds to describe a time control with sub second increment. I did it like this :
The engines get informed about the time control with the command "level 0 0:10 0" so they know that the base time is 10 seconds, but they don't know they'll get a 0.1 second increment. Obviously this is expected since the Winboard protocol doesn't define a way to tell engines that they get a sub second increment.
So my questions are : Is there any way around this? And how does Dr Hyatt run 10+0.1s match?
I don't use xboard. Playing 256 games at a time would result in a _ton_ of network traffic since the graphical displays have to go somewhere, and the cluster does not have a console that can display things. I had to write a referee myself to solve this...
I've been playing with the new release of xboard (Thanks H.G. for this release) to run fast match between my engine and a couple of other engines.
I wanted to run really fast games in wich engines start with 10 seconds on the clock and then get 0.1s increments after each moves. This is, I think, similar to what Dr. Hyatt is doing. H.G.M. suggested I use --firstTimeOdds and --secondTimeOdds to describe a time control with sub second increment. I did it like this :
The engines get informed about the time control with the command "level 0 0:10 0" so they know that the base time is 10 seconds, but they don't know they'll get a 0.1 second increment. Obviously this is expected since the Winboard protocol doesn't define a way to tell engines that they get a sub second increment.
So my questions are : Is there any way around this? And how does Dr Hyatt run 10+0.1s match?
I don't use xboard. Playing 256 games at a time would result in a _ton_ of network traffic since the graphical displays have to go somewhere, and the cluster does not have a console that can display things. I had to write a referee myself to solve this...
Hi,
I knew you were not using xboard. What I was asking is how do you tell the engines they should use a 10s+0.1s time control since winboard doesn't allow this?
I've been playing with the new release of xboard (Thanks H.G. for this release) to run fast match between my engine and a couple of other engines.
I wanted to run really fast games in wich engines start with 10 seconds on the clock and then get 0.1s increments after each moves. This is, I think, similar to what Dr. Hyatt is doing. H.G.M. suggested I use --firstTimeOdds and --secondTimeOdds to describe a time control with sub second increment. I did it like this :
The engines get informed about the time control with the command "level 0 0:10 0" so they know that the base time is 10 seconds, but they don't know they'll get a 0.1 second increment. Obviously this is expected since the Winboard protocol doesn't define a way to tell engines that they get a sub second increment.
So my questions are : Is there any way around this? And how does Dr Hyatt run 10+0.1s match?
I don't use xboard. Playing 256 games at a time would result in a _ton_ of network traffic since the graphical displays have to go somewhere, and the cluster does not have a console that can display things. I had to write a referee myself to solve this...
Hi,
I knew you were not using xboard. What I was asking is how do you tell the engines they should use a 10s+0.1s time control since winboard doesn't allow this?
For the opponents I use, I simply modified their source so that the increment is specified in 1/100ths of a second. I then send them the "level 0 X 10" command which they interpret as "level 0 X 0.1". My referee then sends the normal time/otim commands and sends the normal value there since it is already in .01 second units.
When I tested with xboard, I just used no increment for very fast games...
I've been playing with the new release of xboard (Thanks H.G. for this release) to run fast match between my engine and a couple of other engines.
I wanted to run really fast games in wich engines start with 10 seconds on the clock and then get 0.1s increments after each moves. This is, I think, similar to what Dr. Hyatt is doing. H.G.M. suggested I use --firstTimeOdds and --secondTimeOdds to describe a time control with sub second increment. I did it like this :
The engines get informed about the time control with the command "level 0 0:10 0" so they know that the base time is 10 seconds, but they don't know they'll get a 0.1 second increment. Obviously this is expected since the Winboard protocol doesn't define a way to tell engines that they get a sub second increment.
So my questions are : Is there any way around this? And how does Dr Hyatt run 10+0.1s match?
I don't use xboard. Playing 256 games at a time would result in a _ton_ of network traffic since the graphical displays have to go somewhere, and the cluster does not have a console that can display things. I had to write a referee myself to solve this...
Hi,
I knew you were not using xboard. What I was asking is how do you tell the engines they should use a 10s+0.1s time control since winboard doesn't allow this?
For the opponents I use, I simply modified their source so that the increment is specified in 1/100ths of a second. I then send them the "level 0 X 10" command which they interpret as "level 0 X 0.1". My referee then sends the normal time/otim commands and sends the normal value there since it is already in .01 second units.
When I tested with xboard, I just used no increment for very fast games...
Indeed, this is a problem with ultra-fast games: The incrtement gets lost in rounding. WB protocol does not allow decimals on the timing parameters.
The most practical solution is to not use incremental, but classical time control. Games on the average last 60 moves (and most engines assume this in allocating their time), so with 1:40+1 in practice you will be playing 60 moves in 160 seconds. So you could play 60/2:40 or 40/1:45 in stead. An alternative is to simply let the increment come to the engine as a (pleasant) surprise. Most of it will get lost in communication delays anyway, at this speed, so perhaps it is just as well that the engine does not count on it.
Usually adapting the engines is not an option. If it were, it would be best to forget about time, and implement the nps command in the engine to read its own node count in stead of the system clock. Then you are completely insensitive to any kind of delay, and could even play milli-second games.
hgm wrote:Indeed, this is a problem with ultra-fast games: The incrtement gets lost in rounding. WB protocol does not allow decimals on the timing parameters.
The most practical solution is to not use incremental, but classical time control. Games on the average last 60 moves (and most engines assume this in allocating their time), so with 1:40+1 in practice you will be playing 60 moves in 160 seconds. So you could play 60/2:40 or 40/1:45 in stead. An alternative is to simply let the increment come to the engine as a (pleasant) surprise. Most of it will get lost in communication delays anyway, at this speed, so perhaps it is just as well that the engine does not count on it.
Usually adapting the engines is not an option. If it were, it would be best to forget about time, and implement the nps command in the engine to read its own node count in stead of the system clock. Then you are completely insensitive to any kind of delay, and could even play milli-second games.
I am still not a fan of node count limits. It creates significant time imbalances. Some programs are constant in their NPS from start of game to simple endgames. Others speed up dramatically. Ferret used to speed up by a factor of 4-5x in simple endgames as an extreme example. If you pick a set number of nodes, the more a program typically speeds up in the ending, the bigger the time disadvantage it incurs since it will be searching for shorter periods of time than the opponent.
I forgot to add that Crafty typically has a factor of 2x or a little more between opening and endgame NPS speeds..
hgm wrote:Indeed, this is a problem with ultra-fast games: The incrtement gets lost in rounding. WB protocol does not allow decimals on the timing parameters.
The most practical solution is to not use incremental, but classical time control. Games on the average last 60 moves (and most engines assume this in allocating their time), so with 1:40+1 in practice you will be playing 60 moves in 160 seconds. So you could play 60/2:40 or 40/1:45 in stead. An alternative is to simply let the increment come to the engine as a (pleasant) surprise. Most of it will get lost in communication delays anyway, at this speed, so perhaps it is just as well that the engine does not count on it.
Usually adapting the engines is not an option. If it were, it would be best to forget about time, and implement the nps command in the engine to read its own node count in stead of the system clock. Then you are completely insensitive to any kind of delay, and could even play milli-second games.
That's a good idea. In my case, using classical time control will work.
I'll do something like 40 moves per 15 seconds (if it's not too fast).
hgm wrote:So every system has its limitations. But a mere factor 2 in nps is very little compared to the timing-delay ucertainties you get at 1 msec per move.
Yes, but using time makes things better as the time control is stretched, while using nodes is bad all the time...
