Ras wrote: ↑Thu Nov 26, 2020 8:35 pm
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.
hgm wrote: ↑Thu Nov 26, 2020 8:19 pmBut 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.