UCI2WB 4.0

[hgm]

Removed the empty line and add "I", save, OK. But then when I press edit engine list again, I got same image above, so my changes were not saved.

This is weird. I get that behavior too, at least in when I close WinBoard (with Save Settings on Exit on), and start it again. When I just click Edit Engine List in the same run it does see all the changes.

So it seems a genuine bug. But before you were able to delete engines from the list, and that change did stick, right? (And that would be what makes it weird.)

I will look into it; there was a major change in this area. Rather than always saving the engine list as the value of a (multi-line) string option -firstChessProgramNames in the user settings file, I added a new option -engineList which can specify a filename, and in the AA package was preconfigured to specify %APPDATA%\wb_engines.dat . This is kind of a special user settings file (similar to the -settingsFile option), which only contains the -firstChessProgramNames, and treats every other option as 'volatile'. This was done to make it easier to upgrade to share the engine list between different versions of WinBoard that would need different values for the other settings. But apparently the engine list is not always saved in this file.

(It has always been a problem to upgrade to newer versions that need different values for existing options. In the AA package this was extra relevant, because I wanted to change the value of -adapterCommand to refer to UCI2WB instead of Polyglot. If I let WInBoard-AA use the same user settings file as the previous version, they would keep using the obsolete values for these options. Unless I define the new values in the master settings file after the specification of the user settings file, but then later changes of them by the user would not be persistent anymore, and it would effectively have become a volatile option. Specifying an entirely new user settings file would lose the user his engine list, which could be very much work to recover from.

A kludgy solution that I have used before is to give every WinBoard version a user settings file with a different name, and then read alluser files of previous versions as well, so that the most recent (that for the version itself, after it has been run once) would overrule any earlier. In the master settings file this would require something like

/settingsFile=%APPDATA%\winboard.ini
/settingsFile=%APPDATA%\winboard470.ini
/settingsFile=%APPDATA%\winboard480.ini
/adapterCommand={UCI2WB "%fcp" "%fd"}
/settingsFile=%APPDATA%\winboard490.ini
/saveSettingsFile=%APPDATA%\winboard490.ini

But that leads to a proliferation of settings files, in the long run.)

P.S. For now you can just set /engineList="" at the bottom the master winboard.ini file (in the same folder as winboard.exe) to disable this feature, and use the engine list in the user settings file (which should be saved with all other settings as always).

[Ferdy]

Winboard-AA has factory.ini, I deleted winboard.ini and copy factory.ini then rename the copied factory.ini to winboard.ini. Now I can open winboard normally, delete all engines except the first one, then add new engines. Test is in progress.

[Ferdy]

Winboard-AA has factory.ini, I deleted winboard.ini and copy factory.ini then rename the copied factory.ini to winboard.ini. Now I can open winboard normally, delete all engines except the first one, then add new engines. Test is in progress.

Test with 4 winboard running in parallel. Hardware 4 cores, 8 threads, hyperthreading is on.

Code: Select all

-participants {Deuterium_v2019.1.36.50_x64_pop
Deuterium_v2019.2.37.52
texel_1.07_x64_pop
amoeba_3.0_win64
Bobcat 8.0 x64
Dirty
Ethereal9.00-Win64
Fizbo_1.6_64bit
Pedone_1.9
RubiChess-1.4
Wasp360-x64
}

All winboards had crashed. Games looks normal, only 1 time forfeit.

Engines still seen in windows task manager even without winboard.
Amoeba
Bobcat - still running with cpu usage
rubichess
wasps

Completed games out of scheduled 2000. TC 60s+1s.

Code: Select all

   # PLAYER                              :  RATING  POINTS  PLAYED   (%)
   1 Ethereal 9.00 (UCI2WB)              :  2541.2     2.5       3    83
   2 Texel 1.07 (UCI2WB)                 :  2437.6     5.0       7    71
   3 Pedone 1.9 (UCI2WB)                 :  2360.1     2.5       4    63
   4 RubiChess 1.4 (UCI2WB)              :  2360.1     2.5       4    63
   5 Deuterium v2019.2.37.52 (UCI2WB)    :  2270.0     8.5      19    45
   6 Wasp 3.60 (UCI2WB)                  :  2269.5     2.0       4    50
   7 Dirty CUCUMBER                      :  2269.5     2.0       4    50
   8 Amoeba 3.0.w64p-l (UCI2WB)          :  2269.5     2.0       4    50
   9 Deuterium v2019.1.36.50 (UCI2WB)    :  2269.0     8.5      19    45
  10 Bobcat v8.0 (UCI2WB)                :  2178.8     1.5       4    38
  11 Fizbo 1.6 (UCI2WB)                  :  2074.7     1.0       4    25

Another test is in progress with only one instance of winboard.

[Ferdy]

Completed games out of scheduled 2000. TC 60s+1s.

Correction:
That is only 1800 not 2000 scheduled games.
2 gauntlet setup, 1 vs 9 engines x 100 games plus 1 vs 9 engines x 100 games, is 1800 games total.

[Ferdy]

Another test is in progress with only one instance of winboard.

After 36 games, uci2wb crashed. But winboard continues the tournament.

[Ferdy]

Another test is in progress with only one instance of winboard.

After 36 games, uci2wb crashed. But winboard continues the tournament.

And after game 37, winboard crashed.




Zombie engines.



I stop testing for now.

[hgm]

The zombie engines apparently are a consequence of the killing by WinBoard of the adapter, before it can relay the 'quit' to the engine. This is truly amazing, because it still happens with /delayAfterQuit=1 (i.e. 1 sec). I had UCI2WB log its reception of GUI commands and its sending of commands to the engine on a separate file (so that it can be seen what happens after UCI2WB receives 'quit', and WinBoard closes the pipes to it, so that it no longer logs debug output in the winboard.debug file). From this it turns out that UCI2WB sometimes gets killed before it sends the 'quit' (No sending of 'quit' in the UCI2WB log, and WinBoard says in its log that it decided to kill.)

This ridiculous tardiness could be a consequence of the fact that I configured WinBoard to set the priority of the engines to "below normal" (-niceEngines 10). Which would then also apply to the adapter. Apparently this lowering of the priority can cause an enormous delay in stopping the engine's ponder (which was just started, and for which UCI2WB's engine thread is waiting), releasing the engine thread for looking at the command queue, and having it transmit the 'quit'.

Perhaps WinBoard should always refrain from ever killing an engine when it knows it is running through an adapter (which it would when it invoked the adapter through the -fUCI command), as it would just kill the adapter, while the adapter is supposed to trustworthy and prevented this way from taking its own measures against rogue engines. I also don't like the lowering of engine priorities to be applied to the adapter, but I don't know how it can be applied by the GUI to the engine without applying it to the adapter first. (And it would be unfair to alpply it to engines running without adapter, and not to engines running with one.) This could only be done by introducing a new CECP command to inform the adapter of the desired priority, so that the adapter then can apply it itself.

[Ras]

I also don't like the lowering of engine priorities to be applied to the adapter, but I don't know how it can be applied by the GUI to the engine without applying it to the adapter first.

Is it the adaptor that actually launches the engine process for UCI engines? If so, you could start the adaptor with normal priority from Winboard, and then have a command class that is only between GUI and adaptor. In this command class, there could be a command to tell the adaptor which priority modification (if any) to apply to started engines. That would be the same prio as for CECP engines directly started by Winboard.

The other question is whether this is actually necessary. Windows' scheduler works quite differently from the Linux one where xboard originated. The whole point of that re-nice in xboard was to keep the GUI responsive while the engine calculates, especially back then when CPUs only had a single core.

Since Windows is geared to desktop use, this problem is already tackled at OS level. A GUI that wakes up because of a mouse click receives a dynamic priority boost because people just expect smooth GUIs on desktop. Maybe that is already good enough even when all CPU cores are loaded with engine calculation.

[hgm]

Indeed, UCI2WB spawns the engine processes. And you are right, it would be better to defer the priority handling to the adapter. I guess a command-line parameter of the adapter could be used to request the engine priority; the engine name and directory are aready transmitted to it that way. WinBoard has a general feature that allows passing WinBoard command-line options to an adapter: a token %XXX in the specified -adapterCommand would be replaced by the value of the WinBoard option -XXX (so passing of the engine name is specified as %fcp, etc.) when launching the adapter. So I could include %niceEngines in the adpterCommand for UCI2WB. Then I could alter WinBoard so it would refrain from changing the priority of an adapter that would contain the substring %niceEngines in its adapterCommand.

In any case WinBoard should refrain from killing adapters; this never serves any purpose, and can only make matters worse. The problem with zombie Stockfishes goes entirely away when I refrain from killing 'engines' launched through the adapterCommand. Not sure how long this would allow the actual engines to continue using CPU (e.g. pondering) while the next game is already started, though. Perhaps I should have UCI2WB kill the engine it launched, a few millisec after it sent 'quit'. Or when it sees EOF on its stdin because the GUI closed the pipe.

[Ras]

I guess a command-line parameter of the adapter could be used to request the engine priority

I'd still guess that this isn't necessary on Windows at all because you get that dynamic priority boost upon mouse / keyboard events, or whenever a thread wakes up from some wait (on event, network, I/O or whatever).

There's just two basic design patterns to avoid in the GUI. First, if the GUI isn't event waiting, but polling. Then there will be no dynamic boost because it hasn' slept. Second, if too much is going on out of the event loop instead of a worker thread. In both cases however, re-nicing the engine merely masks the issues, but doesn't fix them. Going for thread priorities should be the last resort under Windows. Also because priority under Windows means something quite different than under Unix where this xboard idea originated.

Perhaps I should have UCI2WB kill the engine it launched, a few millisec after it sent 'quit'. Or when it sees EOF on its stdin because the GUI closed the pipe.

That could lead to new problems when an engine appears that itself is spawing child processes, not just threads. Dunno, maybe with some NN framework? Or if it's some learning engine that wants to save data before exiting? In this case, proper shutdown should be preferred if possible. Something like 1 to 5 seconds timeout after 'quit' seems generous.