On-line engine blitz tourney November

[hgm]

Why would UCI also not be susceptible to a Windows timer accuracy issue along with CECP?

Because UCI supports millisecond resolution on protocol layer and CECP doesn't. So, UCI engines have the possibility to be that precise. Also, I don't see why anyone would even use GetTickCount() with its low resolution - instead of QueryPerformanceCounter(), which is what my engine does under Windows.

You can control that for your own engine, but I you have little control over, and might not even know what possible opponents do.

The main point, however, is that even accurate timers will not accurately reflect how much CPU time your engine spends thinking. There can be unpredictable scheduling delays. So the time the GUI will take as your thinking time will be inherently fuzzy, even when the engine makes it very precise. Making it more precise than the latency noise doesn't buy you anything.

[Ras]

You can control that for your own engine, but I you have little control over, and might not even know what possible opponents do.

Nobody has control about any sort of limitations or shortcomings in other engines. That's not an argument.

The main point, however, is that even accurate timers will not accurately reflect how much CPU time your engine spends thinking.

As long as the CPU isn't overloaded, that's not a practical issue.

Making it more precise than the latency noise doesn't buy you anything.

Short games down to one second for the whole game without increments rely on having a resolution of less than 16ms, and even of less than 10ms - which CECP cannot provide by design.

Back in the old days of 2000 and XP, QueryPerformanceCounter() was not quite as good on all machines (see https://docs.microsoft.com/en-us/window ... ime-stamps) so that there was some rationale to use GetTickCount(). In 2020 however, the advice of using GetTickCount() along with arguing about its 16ms resolution is outdated by at least a decade. Windows has high resolution timers - just use them.

[hgm]

In the design of CECP the nps feature serves this function. IMO in a more reliable way than switching to msec resolution would do.

BTW, it would be trivial to support msec precision in CECP. Just introduce a feature for it. E.g. feature msec=1. Or perhaps more future proof, feature timeunit=N for requesting the time and otim commands to use units of 10^-N sec.

[Joost Buijs]

Why would UCI also not be susceptible to a Windows timer accuracy issue along with CECP?

Because UCI supports millisecond resolution on protocol layer and CECP doesn't. So, UCI engines have the possibility to be that precise. Also, I don't see why anyone would even use GetTickCount() with its low resolution - instead of QueryPerformanceCounter(), which is what my engine does under Windows.

Indeed, this is what I used in the past too. I my latest engine(s) I use the C++ <chrono> header which internally uses QueryPerformanceCounter().

Approx. like this:

Code: Select all

std::chrono::high_resolution_clock::time_point t0 = std::chrono::high_resolution_clock::now();
// some calculations
std::chrono::high_resolution_clock::time_point t1 = std::chrono::high_resolution_clock::now();
double elapsed_time = std::chrono::duration_cast<std::chrono::duration<double>>(t1 - t0).count();

[Ras]

In the design of CECP the nps feature serves this function.

Most engines don't support it, not even FairyMax 5.0b, and neither Crafty 23.4 - two of the most prominent CECP engines.

BTW, it would be trivial to support msec precision in CECP. Just introduce a feature for it.

I don't think that it's a solution to add even more features that nobody will implement.

[hgm]

In the design of CECP the nps feature serves this function.

Most engines don't support it, not even FairyMax 5.0b, and neither Crafty 23.4 - two of the most prominent CECP engines.

That is because Fairy-Max isn't designed for playing sub-second games. It also uses GetTickCount() for timing. I don't know about Crafty. It has always had a rather backward CECP implementation.

I don't think that it's a solution to add even more features that nobody will implement.

That is a rather strange remark. Almost every CECP engine supports loads of features. E.g. almost everyone supports setboard. (Fairy-Max doesn't, btw.) If engine authors consider it a problem that they are not told the remaining time in msec, of course they would support a feature that does give it to them in msec, rather than throwing their hand up in the air complaining that it is impossible. You support what you need, and ignore what is of no use to you.

Besides, if UCI2WB would support it, it means all UCI engines would support it even under WinBoard.

[brianr]

Is there a tourney manager that uses the higher precision timers?

[hgm]

I am not even sure what WinBoard uses. But that the time stamps in the debug file increase in steps of 16msec suggests it would use GetTickCount. But it would be a rather trivial patch to change that, of course.

But I am not so optimistic about the timing jitter in the communication as Rasmus.

[Ras]

That is a rather strange remark. Almost every CECP engine supports loads of features.

Can you name just two that support NPS? Especially with the "noderate=0" mode.

E.g. almost everyone supports setboard.

Because it's less work to implement than the edit mode.

If engine authors consider it a problem that they are not told the remaining time in msec

That's why the CECP ecosystem in practice doesn't support NPS - because it's an optional feature and not baked into the protocol. Same reason why making the time base optional would have no support in the wild and thus wouldn't solve anything.

Is there a tourney manager that uses the higher precision timers?

I'm not on Windows anymore, but under Linux, c-chess-cli has very precise timing (via clock_gettime with monotonic clock).

But I am not so optimistic about the timing jitter in the communication as Rasmus.

With Winboard, I wouldn't be too optimistic either. Native CECP engines don't support that precision in the first place. UCI engines can, especially if they use clock_gettime() (also supplied via MingW). However, Winboard has no direct UCI support, and Polyglot as in-between process will introduce timing problems. Even if it didn't, Winboard itself would still struggle with the timing because Polyglot has to convert to centisecs towards Winboard.

[hgm]

Can you name just two that support NPS? Especially with the "noderate=0" mode.

I admit that none of my own engines supports it. I hardly ever look at other engines, so I have no idea. But I know why I don't support it: I do not consider ultra-fast games a use case of my engines. So I don't design my engines for it. They happily use GetTickCount().

E.g. almost everyone supports setboard.

Because it's less work to implement than the edit mode.

That is a rather dubious claim. I think the edit command would require less code than is needed for parsing a FEN.

That's why the CECP ecosystem in practice doesn't support NPS - because it's an optional feature and not baked into the protocol. Same reason why making the time base optional would have no support in the wild and thus wouldn't solve anything.

No, they don't support NPS because they don't need it. That might very well be the reason they would not support a timebase feature either. You might think it is important to have msec resolution in the engine, but most people probably wouldn't. I certainly don't consider it necessary for my engines. Mdern CECP engine support features like memory=1, smp=1 (when the are multi-threaded) and egt="syzygy" (when they use EGT). Because these enable support for something they do want to do.

Take Fairy-Stockfish as an example. It even supports the highlight feature.

But I am not so optimistic about the timing jitter in the communication as Rasmus.

With Winboard, I wouldn't be too optimistic either. Native CECP engines don't support that precision in the first place. UCI engines can, especially if they use clock_gettime() (also supplied via MingW). However, Winboard has no direct UCI support, and Polyglot as in-between process will introduce timing problems. Even if it didn't, Winboard itself would still struggle with the timing because Polyglot has to convert to centisecs towards Winboard.

This is not what I mean by timing jitter. It means the intrisic variation in the time that elapses between writing to a pipe and another process reading and processing the message. That is an OS property, so WinBoard has nothing to do with it.

All the problems you mention are irrelevant. WinBoard and Polyglot do what I want them to do. WinBoard can send microseconds to Polyglot, if I desire so. It would be all for nought, however, if Windows adds to much noise to the communication lag. Unlike WinBoard and Polyglot, I have no control over what Windows does.