It seems like the rule to not gate when king is in check and the king cannot capture the attacker is not yet implemented in winboard and KingSlayer-Aramis 0.8.
***h***f/r1bqkbnr/1ppp1ppp/p1n5/4p3/4PPP1/3P4/PPP4P/RNBQKBNR/**H*F*** b KQkq f3 0 4
When I played d8h4h, attacking black's king, it played:
30688 <first : move e1d2f
(Should have been e1d2 only.)
Winboard accepted it and sent this to me.
177917 >first : usermove 177917 >first : e1d2f
Been experiencing some time forfeits in Winboard 4.9.20200531. This is at TC 30s+100ms. In the example below, white still has 16cs or 160ms. It thinks around 16ms and got forfeited.
One thing I notice here is that the silence consumes time, around 86747-86591 or 156. Is this really charged to the engine thinking time?
I did the test between Deuterium and Crafty. Tried it in cutechess on same TC and no time forfeit. In winboard, both have loses on time.
The 'silence' should not consume any time, other than needed to flush the message to the debug file. It means that the routine MyPlaySound() for playing the move sound was called with a null argument, which would make it return immediately. It would also not matter if it did, because the move at that point has already been sent to the engine (to UCI2WB in this case). So the engine is already thinking, and will measure the time it will take from the point when it received that.
From the POV of WinBoard the engine is forfeiting: it is told it has still 160ms at t=86591, so its flag will fall at t=86751, and the move is only received at t=56763, i.e. 12ms too late. If the engine'log says differently, the cause must have been communication lag. I once measured the lag caused by UCI2WB, and it was only 1.5ms roundtrip (on a slow laptop). So I don't know how the lag can be so large. WinBoard by default runs the engines at a lower priority (option -niceEngines), and in recent versions it exempts known adapters from this when they are installed with a a command line (in -adapterCommand) that passes the -niceEngines option to them. Assuming this means the adapter will nice down the engine when it launches it, but can keep running at high priority itself. It could be that this scheme somehow backfires, because other stuff running on your PC occasionally competes for CPU at normal priority, and then pushes the engine out of business.
I run that test in winboard tourney manager with concurrency of 4. I have 4 cores/8 threads, hyperthreading is ON. I am sure there are enough cpu resources as I have not run other programs not even browsing, also I look at the task manager occasionally and cpu utilization is only around 50% to 60%.
Another observation based from reading the logs is that if time left is 20cs or 200ms or less, there is a high chance that the engine will be forfeited due to time.
The current solution is to add a time buffer of 200ms.
Well, one issue was the difference in behavior between WinBoard and CuteChess. If WinBoard is running the engines at lower priority, and CuteChess is not, this is a difference. Arguing that this difference cannot be the cause of the trouble is not a reliable method to reveal the truth; we know nothing about how the Windows scheduler works. I would first make sure the engines are running under the same conditions, e.g. use -niceEngines 0 in WinBoard if that is what CuteChess does. If that would still cause time losses on WinBoard, and not on CuteChess, we have something we could look into in more detail, e.g. by making all involved entities announce time stamps for their actions that can be related to each other, rather than only to the time they have been running. Then we can see excatly where the lag originates.
It used to be that running the engines at lower priority would make things work more reliably. Apparently on newer Windows systems this is no longer true, to the point where one can wonder whether the OS should be considered broken. With so many (HT) cores in reserve, and no other heavy computational task running it is really strange that a process, even a lower-priority proces, should get suspended by as much as 250 ms. It is almost like the process image must have been swapped to disk. (To make room for what? Garbage that MicroSoft wanted to pollute your memory with?)
