Timemanemant bei Lc0

By Peter Martan Date 2023-12-08 08:15 Edited 2023-12-08 08:59

Danke.
Gerade bei diesen Parametern würde ich halt wieder sehr unterscheiden zwischen verschiedenen Gegnern und verschiedener Hardware- TC, genau genommen (nein, nicht einmal das

) auch bei verschiedenen Teststellungen, wie groß der Vorteil einer Seite in der Eröffnungsstellung ist, davon hängt natürlich auch die durchschnittliche Partielänge ab und damit die optimalen Einstellungen fürs Time Management.

Am deutlichsten sieht man die Unterschiede nach wie vor bei MEA, was bei SF 200 msec. pro Stellung sind, sind bei Lc0 mit den jüngsten Compiles und Netzen 380msec. in der Vorgabe, damit der Gesamtzeitverbrauch zum Schluss bei beiden gleich ist, leider hängt natürlich auch das von der Zahl und der Art der Stellungen ab, ebenso wie vom Compile und vom Netz. BT4 braucht eher nur 370, BT3 je nachdem, welches davon und mit welchem Compile ziemlich genau 380 bis ev. auch 400. Lc0 nimmt sich also nur rund die Hälfte der Zeit pro Stellung, die vorgeschrieben wird, wenn man's mit dem vergleicht, was SF macht (und mit ihm die meisten anderen Engines, die ich teste, Ausreißer sind ansonsten nur vereinzelt, der prominenteste ist ShashChess, der auf bis zu 5x weniger eingestellt werden muss je nach Version, frühere Berserk- Releases haben wieder in der Richtung von Lc0 mehr Vorgabe gebraucht, Berserk 12 wieder nicht mehr).

Selbst im Shredder- GUI ist der Gesamtzeitverbrauch so unterschiedlich, wie man's bei den Beispielen im anderen Thread sieht, am wenigsten schwankt er im Fritz, vor allem kann man da halt auch noch mit EloStatTS die Lösungszeiten von Engine zu Engine und von Stellung zu Stellung in die Bewertung einbeziehen (lassen).
Im Shredder hab' ich als einfachsten Weg, den Gesamtzeitverbrauch mit zu bewerten: Der Zeitunterschied in der TotTime wird durch das dividiert, was Vorgabe ist, das macht dann dieses Ergebnis an zusätzlichen gewonnenen oder verlorenen Punkten aus, z.B. siehe BT4- Thread SF 1:30 und Lc0 1:17, werden 13 Sekunden Plus (in denen nach Vorgabe 13 Stellungen abzuarbeiten sind) für SF als 13 Lösungen weniger für ihn relativ zu Lc0 gezählt.

By Lothar Jung Date 2023-12-08 08:31

Der Buchparameter basiert auf einem 4 Züge Buch.
Bei 8 Züge würde ich ihn verdoppeln, bei 16 Züge vervierfachen.

Bei 5 Min/0 habe ich steepness auf 2 gesetzt.

Vom Gegner abhängig würde ich keine Parameter ändern.

Für Suites würden sich die default Werte anbieten.

By Peter Martan Date 2023-12-08 08:42 Edited 2023-12-08 09:00

Lothar Jung schrieb:

Für Suites würden sich die default Werte anbieten.

Aber nur, wenn's Suiten sind, die über ein GUI beurteilt werden, das sich an Zeitvorgaben seinerseits hält, Banksia z.B. ist wieder ein Fall für sich, wenn du dir da mal anschaust, wie das differiert von Engine zu Engine, was man vorgibt und was an Gesamtzeitverbrauch herauskommt.

MEA musst du adaptieren, weil ja da eine msec- Vorgabe/Stellung eigentlich auf die msec genau eingehalten werden müsste, damit's fair ist, da muss also der Gesamtzeitbrauch zum Schluss gleich sein, egal, wieviele Punkte gemacht werden, wie ich's bei Shredder in Elo (oder eine andere Performance, aus der man eine error bar berechnen kann, z.B. auch einfach in Lösungen pro Zahl der Stellungen) umrechnen würde, hab' ich noch editiert, als du schon geantwortet hattest.

Edit, edit:

Lothar Jung schrieb:

Vom Gegner abhängig würde ich keine Parameter ändern.

Ich würde Engine- Parameter gar nicht ändern, wenn ich (zumindest auch) wissen wollte, wie die default- Werte gegen welchen Gegner auf welcher Hardware- TC mit welchen Stellungen abschneiden, dazu gibt's ja die TC- Parameter des Matches, die man ändern kann, ebenso wie die mehrmals zitierten anderen Vorgabe- Parameter des Matches.
Z.B. Frank Quisinsky sieht das aber mit den Engine- Parametern auch anders, z.B. was den "Contempt" angeht

Langer Rede kurzer Sinn mal wieder: jedes Ergebnis aus game playing oder anderen Tests steht für sich allein. Wenn du einen einzelnen Parameter einer einzelnen Engine oder eines einzelnen Matches (Tests) in seinen Auswirkungen mit anderen Einstellungen dieses einen Parameters vergleichen willst, musst du alle anderen Parameter (der Engine, des Matches, des Tests) genau gleich lassen. Also bei Lc0, bei dem ja ständig neue Compiles unabhängig von den neuen Netzen rauskommen (dass SF im Framework dem einen Riegel vorgeschoben hat durch das Einbetten vom NNUE, kann ich besser und besser verstehen) jedes einzelne Compile mit jedem einzelnen Netz kreuzweise mit jedem einzelnen Parameter- Setting (das dich interessiert) für sich allein unter sonst exakt gleichen Bedingungen testen.

By Lothar Jung Date 2023-12-08 09:32

Da wir gerade bei dem wichtigen Thema der Bedenkzeiten sind:

Das letzte TC 3 min/1 sec. Turnier LC0/SF ging sehr schlecht für LC0 aus.
Nach der Einschätzung der Experten, lag es daran, dass LC0 wegen der sehr kurzen Bedenkzeit pro Zug, seine Minibenchsize nicht füllen d.h. ausnutzen konnte.
Bei den immer größeren Netzen wird dieses Problem besonders virulent.
Eine Erhöhung der Bedenkzeit bei den BT Netzen für Suites sollte deshalb erhöht werden.
Vielleicht könntest Du mit deiner großen Suite diese Problematik testen.

By Peter Martan Date 2023-12-08 09:56 Edited 2023-12-08 10:09

Lothar, du verstehst mich nicht ganz, glaube ich.
Bedenkzeiten bei Suiten (für alle Engines gleichermaßen) oder bei Matches erhöhen, gibt natürlich andere Ergebnisse, aber welche sind dann die "richtigeren"? Man könnte ja auch bei den CCC- Turnieren sagen, kürzere TCs spreizen die Elo, je mehr Spreizung desto genauer, dass das so einfach nicht ist, wissen wir (hoffentlich) mittlerweile alle. Außerdem ist CCC natürlich nicht interessiert, (auch schon wegen Torch) gegen Lc0 gleich zu testen wie TCEC, weil die TCEC- Ergebnisse haben wir eh und aus irgendwelchen error bars kommen die wenigen Partien dort sowieso praktisch nie, nicht einmal bei einem 100- Partien Sufi head to head allein.

Bedenkzeiten bei MEA- Suiten (du weißt, wovon ich spreche, ja?) müssen, damit Fairness herrscht, in der Summe der gesamt verbrauchten Zeit (die hängt ja bei MEA nicht davon ab, wieviel "gelöst" wird, bei GUIs schon, wenn man früheres Finden, bis auf bestimmte Extraplies limitiert, mit früherem Wechseln zur nächsten Stellung zulässt) gleich sein, und wie ich ganz am Anfang schrieb, ist das Verhältnis von dem, was Lc0 mit BT3 und dem letzten TCEC- Sufi- Compile angeht, eine Sache von 380mscec zu 200 msec, damit der Gesamtzeitverbrauch dem von Stockfish gleich wird, das Compile von deinem gestrigen Link (das übrigens auf TCEC derzeit mit dem 2860M- Netz, also einem BT3 spielt) mit dem BT4 sind's "nur" 370mscec, beides stimmt so nur für eine bestimmte Suite, getestet hab' ich das gestern mit einer MEA- Suite von 1001 Stellungen.
Noch Fragen?
Edit: Für den Fall, dass dich diese MEA- Ergebnisse auch in Zahlenwerten interessieren:

    EPD  : 1001.epd
    Time : ms
                                                Max   Total   Time   Hash          
    Engine           Score   Found  Pos   ELO  Score   Rate    ms     Mb  Cpu      
 1  lc0e492eeb-2860M  79725    821  1001  4099  87540  91.1%    200     2    2
 2  SF231105          79530    808  1001  4086  87540  90.8%    200     4    1
 3  Sawfish2TC        79320    812  1001  4077  87540  90.6%    200     4    1
 4  Lc0a4877961-2745M 79110    813  1001  4068  87540  90.4%    200     2    2
 5  Brainlearn26.5    78090    786  1001  4014  87540  89.2%    200     4    1
 6  SF231202          77660    786  1001  3991  87540  88.7%    200     4    1
 7  Dragon3.3         76780    782  1001  3946  87540  87.7%    200     4    1
 8  Berserk12         74595    746  1001  3834  87540  85.2%    200     4    1
 9  Ethereal14.25     73760    742  1001  3793  87540  84.3%    200     4    1
10  Wasp6.50         69770    696  1001  3586  87540  79.7%    200     4    1
11  Fire9.1          69190    673  1001  3555  87540  79.0%    200     4    1
12  Fritz19          68330    675  1001  3514  87540  78.1%    200     4    1

                                    Created with MEA
                                          by
                                       Ferdinand
                                         Mosca

By Lothar Jung Date 2023-12-08 17:46 Edited 2023-12-08 17:48 Upvotes 1

Danke, für den Test.
Ist jetzt LC0 die Engine, die am besten abschneidet?!
Ach ja, nur 1 CPU. Bei 14 CPUs würde die Tabelle andres aussehen.

By Peter Martan Date 2023-12-08 18:05 Edited 2023-12-08 18:11

Genau. Und bei den 555 hat z.B. SF dev. mit 8 threads (da kann ich im Shredder immer noch 3-4 A-B-Engines gleichzeitig laufen lassen) und 1"/Stellung 494/555 (Lc0 439), eine Engine mit einem so cleveren internen MulitPV- Modus, dass er sogar bei so kurzer TC noch hilft, schafft 517. Drum sag' ich ja, kommt immer auf die Stellungen und die Hardware- TC an, bei der man testet und welche Engines man wie untereinander vergleicht.

By Peter Martan Date 2023-12-08 11:06 Edited 2023-12-08 12:01

Lothar Jung schrieb:

Vielleicht könntest Du mit deiner großen Suite diese Problematik testen.

In einem GUI mit gutem Zeitmanagement mag ich das selbst mit Shredder, mit dem ich ja wenigstens ein paar Instanzen gleichzeitig laufen lassen kann, aber bei Lc0 auch nicht, weil ich nur eine einzelne gute GPU habe, und das aber auch 1"/Stellung als Untergrenze des Einstellbaren hat, nicht mit mehr als 555 Stellungen testen, hier hab' ich noch 2 Runs auf diese Art verglichen (1"Stellung, Extratiefe 2, 3070ti GPU, 2 CPU- Threads)

Lc0 v0.31.0-dag+git.a4877961 2860M
Bisher gelöst: 439 von 555 ; 1:41m

         1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  16  17  18  19  20
 -------------------------------------------------------------------------------------
   0 |   0   0   0   0   0   0   0   0   0   0   0   -   0   0   0   0   0   0   0   0
  20 |   0   0   0   0   0   0   0   0   -   0   -   0   0   0   0   0   0   0   -   0
  40 |   0   0   0   0   0   0   0   0   0   0   0   0   0   -   0   0   0   0   0   0
  60 |   0   0   -   0   0   0   0   -   0   0   0   0   0   0   0   0   0   -   0   0
  80 |   0   0   0   0   -   0   0   0   0   0   -   0   0   0   0   0   0   0   0   0
 100  |   0   0   0   0   0   0   0   -   0   0   0   0   0   0   0   0   0   0   0   0
 120  |   0   0   0   0   0   0   0   0   -   0   -   0   0   -   0   0   0   0   0   0
 140  |   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   -   0   -   0   0
 160  |   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   -   0
 180  |   -   0   0   -   0   0   0   0   0   0   0   0   0   -   0   -   0   0   0   0
 200  |   0   0   0   0   0   0   0   0   0   0   0   0   -   0   0   0   0   0   0   0
 220  |   0   0   0   0   0   0   0   -   0   -   0   0   0   0   0   -   0   0   0   0
 240  |   0   0   0   0   0   0   0   0   0   0   0   0   0   0   -   -   0   0   0   0
 260  |   0   0   -   0   0   0   -   0   0   0   -   0   0   0   0   0   0   -   0   -
 280  |   0   0   -   0   -   0   0   0   0   0   0   0   0   0   0   -   0   0   -   0
 300  |   -   0   0   0   0   0   0   -   0   -   0   0   0   0   0   0   0   0   0   -
 320  |   0   0   -   0   0   0   -   0   0   0   -   0   0   -   0   0   0   0   0   0
 340  |   0   0   0   0   -   -   -   0   0   -   -   0   0   0   0   0   0   0   0   0
 360  |   -   -   -   0   0   -   0   0   0   0   -   -   0   -   0   0   0   0   -   0
 380  |   -   0   0   -   0   0   0   0   0   0   0   0   -   0   -   0   -   -   0   0
 400  |   0   0   0   -   0   0   0   0   0   0   -   0   -   0   0   -   0   0   0   0
 420  |   0   0   0   0   0   -   -   0   0   0   0   0   -   0   0   0   -   0   0   -
 440  |   0   0   0   0   0   -   -   0   0   -   0   -   0   0   0   0   -   -   -   0
 460  |   0   0   -   -   0   0   0   0   0   -   -   -   0   0   0   -   0   -   0   0
 480  |   -   0   0   0   0   -   0   0   0   -   0   0   0   0   -   -   0   0   0   0
 500  |   -   0   -   0   -   -   0   -   0   -   0   0   0   -   0   0   -   0   -   -
 520  |   0   0   -   -   0   -   0   -   -   0   0   -   -   0   -   -   0   0   0   0
 540  |   -   -   -   -   -   0   -   0   0   0   0   0   0   0   0

TotTime: 4:30m SolTime: 1:41m

Lc0 v0.31.0-dag+git.a48779610 BT4 2745M
Bisher gelöst: 432 von 555 ; 1:47m

         1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  16  17  18  19  20
 -------------------------------------------------------------------------------------
   0 |   0   0   0   0   0   0   0   0   0   0   0   -   0   0   0   0   0   0   0   0
  20 |   0   0   0   0   0   0   0   0   -   0   0   0   0   0   0   0   0   0   -   0
  40 |   0   0   0   0   0   0   0   0   0   0   0   0   0   -   0   0   0   0   0   0
  60 |   -   0   0   0   0   0   0   -   0   0   0   0   0   0   0   0   0   0   0   0
  80 |   0   0   0   0   0   0   0   0   0   0   -   0   0   -   0   0   0   0   0   0
 100  |   0   0   0   0   0   0   0   -   0   0   0   0   0   0   0   -   0   0   0   -
 120  |   0   0   0   0   0   0   0   0   -   0   -   0   -   0   0   0   0   0   0   0
 140  |   0   0   0   0   0   0   0   0   0   0   0   0   0   -   0   0   0   -   0   0
 160  |   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   -   0
 180  |   -   0   -   -   0   0   0   0   0   0   0   0   0   -   0   -   0   0   0   0
 200  |   0   0   0   0   -   0   0   0   0   0   0   0   -   0   0   0   0   0   0   0
 220  |   0   0   0   0   0   0   0   -   0   0   0   0   0   0   0   -   0   -   0   -
 240  |   0   0   0   0   0   0   0   0   0   0   0   -   -   0   -   -   0   0   0   0
 260  |   0   0   0   0   0   0   -   0   0   0   0   0   0   0   0   0   0   -   0   -
 280  |   0   -   -   0   -   0   0   0   0   0   0   0   0   0   0   0   -   0   -   0
 300  |   0   -   0   0   -   0   0   -   0   -   0   0   0   0   0   0   0   0   0   -
 320  |   0   0   -   0   0   0   -   0   0   0   -   0   0   -   0   0   0   -   0   0
 340  |   0   0   0   0   -   -   -   0   0   -   -   0   0   0   0   0   0   -   0   0
 360  |   -   -   -   -   0   -   0   -   0   0   -   0   0   0   0   0   0   0   -   0
 380  |   0   0   0   -   0   0   0   -   0   0   0   0   -   0   -   0   -   -   0   0
 400  |   0   0   0   -   0   0   0   0   0   0   -   0   -   0   0   -   0   0   -   0
 420  |   0   0   0   0   0   -   -   0   0   0   0   0   -   -   0   0   0   0   0   -
 440  |   0   0   0   0   0   -   -   0   0   -   0   -   0   0   0   0   0   -   0   0
 460  |   0   0   -   -   0   0   0   0   0   -   -   -   -   0   0   -   0   -   0   0
 480  |   -   0   0   0   0   0   0   0   0   -   0   0   0   0   -   -   0   0   0   0
 500  |   -   0   0   0   -   -   0   -   0   -   0   0   0   -   0   -   -   0   -   0
 520  |   0   -   -   -   0   -   0   -   0   -   -   0   -   0   -   -   -   0   -   0
 540  |   -   -   -   0   0   -   -   0   0   0   0   0   0   0   0

TotTime: 4:40m SolTime: 1:47m

Ein eventueller Zeitvorteil bei den Lösungen muss natürlich, wenn überhaupt, hier nicht wie oben fälschlich geschrieben, anhand der TotTime (die der ganze Test dauert), sondern anhand der SolTime zusätzlich bewertet werden, man könnte also der langsameren Engine noch 6 Sekunden (Lösungen bei 1"/Stellung Vorgabe) abziehen.
Der langsameren Engine hier mehr Zeit zu geben als der schnelleren, finde ich ebenso gegen den Sinn des Tests, wie einer Engine in einem Match (in dem sie sich ja ebenso wie beim Stellungstest, wenn nicht über die CPU allein abgezählte msec vorgegeben werden pro Stellung wie bei MEA, die Zeit fürs Lösen oder Ziehen selbst einteilen soll, muss und kann) andere Zeitvorgaben als der gegnerischen vorzuschreiben, ist ein ebensolches absichtliches Bevorteilen, wie bestimmte Stellungen zu verwenden, von denen man weiß, dass sie der einen Engine besser liegen als der anderen.
Genau genommen ist auch schon ein Änderung an Time Management- Parametern ein ähnlich wirkender Eingriff. Kann man machen, muss man aber dann natürlich auch wieder bei der Relativierung zu anderen Ergebnissen berücksichtigen.

By Jörg Oster Date 2023-12-09 10:28 Upvotes 1

Vielleicht sollte man dann die Minibatchsize an die Zeitkontrolle anpassen?!

By Lothar Jung Date 2023-12-09 12:51

Eine gute Idee.
Man kann im Terminal die Optimale mbs ermitteln.
Man nimmt den besten niedrigsten Wert.
Aber für sehr kurze TC könnte man mit einem noch niedrigeren Wert experimentieren.
Vielleicht 32.

By Andreas Matthies Date 2023-12-08 10:33 Upvotes 3

Lothar Jung schrieb:

Natürlich sollte man auch den Moveoverhead bei kurzen Bedenkzeiten hochsetzen.
Bei 5 min./0 hat sich bei mir 40000 bewährt.

Warum das? MoveOverhead ist üblicherweise dafür da, die Engine zu unterrichten über die maximal mögliche Verzögerung der Kommunikation zwischen GUI und Engine. Diese sollte, wenn GUI und Engine auf demselben Rechner laufen, zwischen < 10ms bei guten GUIs wie Cutechess und einigen 100ms bei schlampigen GUIs wie Arena liegen. 40000 würde ja schon fast einer Übertragung der Züge per Tontafel entsprechen. Wenn es nur bei kurzer Bedenkzeit eingesetzt wird, scheint es hier eher die Schwächen im Zeitmanagement von Lc0 bei dieser Zeitkontrolle zu kaschieren.

Grüße, Andreas

By Lothar Jung Date 2023-12-08 17:43 Upvotes 1

Andreas, das ist eine Besonderheit von LC0 unter den giftigen Bedingungen des Maschinenraums von Schach.de:

- 5 Minuten, kein Increment (sonst bekommt man keine Gegner),
- Keine Anwendung von Remisregeln, außer 50 Züge Regel,
- Remisangebote werden unter Zeitnot nicht angenommen.

Bei 5 Minuten +2/3 Sekunden, bräuchte man ein Endspielpolster von 40 Sec. nicht.

Gruss

Lothar

By Andreas Matthies Date 2023-12-08 18:20

Lothar Jung schrieb:

Bei 5 Minuten +2/3 Sekunden, bräuchte man ein Endspielpolster von 40 Sec. nicht.

Okay, das ist eine Umschreibung von "Schwächen im Zeitmanagement von Lc0 bei dieser Zeitkontrolle kaschieren".

By Lothar Jung Date 2023-12-08 19:46 Upvotes 1

Nee, nicht ganz.
Das 5+0 Format ist unüblich.
Bei Remis die Engines auflaufen zu lassen, ist unsportlich.
Bei einem längerem Buch und besserem Endspiel, was jetzt LC0 beherrscht, wären mit den besseren Parameter, auch 10000 möglich.
LC0 hat bei sehr kurzen TC ein Latenzproblem aufgrund der PCI GPUs.

By Reinhold Stibi Date 2023-12-08 22:34

Das 5+0 Format ist das übliche Blitzformat und ganz bestimmt nicht unüblich

In der Zeitnot auflaufen zu lassen ist nicht unsportlich sondern ganz normal im Blitz.

Lc0 hat keine Probleme mit der Zeitnot wenn man MoveOverhead auf 70000 einstellt
und es geht dabei keine Partie mit Zeit verloren und die Zeiten für die einzelnen Züge stimmen.

By Martin Steinwandter Date 2023-12-09 08:13

LC0 ist da nicht alleine. Bei 5+0 verliert auch Stockfish auf Zeit, wenn der Moveoverhead nicht erhöht wurde.

By Reinhold Stibi Date 2023-12-09 08:28

Zu bemerken ist noch das Lc0 auch bei Blitz 5 Min. 0 Sek. sehr gut ist
und da auch keine Schwäche zeigt. Nur muss MoveOverhead richtig eingestellt sein.

Vor ca. 3 Monaten habe ich mit Lc0 und zwei RTX 2070 im Verbund (entspricht einer RTX 3070 Ti)
auf Schach.de bei 150 Partien in Folge keine Partie verloren. Nur gewinnt Lc0 weniger als Stockfish
und Abkömmlinge.

Leider verbraucht Lc0 mit RTX sehr viel Energie; bei meiner Kombination oben im gesamten System
700 Watt.

Mein Mini PC mit Ryzen 9 5900hx (8 Core/16 Thread) liefert mit Stockfish und Abkömmlinge noch
etwas bessere Ergebnisse und braucht nur 80 Watt.

By Jörg Oster Date 2023-12-09 10:25 Upvotes 1

Martin Steinwandter schrieb:

LC0 ist da nicht alleine. Bei 5+0 verliert auch Stockfish auf Zeit, wenn der Moveoverhead nicht erhöht wurde.

Stimmt.
Wobei der MoveOverhead dafür eigentlich nicht gedacht ist, wie Andreas ja weiter oben schon erklärt hat..

By Martin Steinwandter Date 2023-12-09 11:33

Ist schon klar, trotzdem musste ich zum Beispiel auf der Infinity chess Plattform bei 0 Inkrement Spielen den Move Overhead auf 400 stellen. War aber bekannt dass die Kommunikation zwischen GUI und Engine schlecht war. Deswegen gab es auch keine Turniere ohne Inkrement. Lokal mit der Arena gui genügen 100ms. Die Cute Chess gui begnügt sich mit default Werten.

By Jörg Oster Date 2023-12-09 10:18 Upvotes 1

Reinhold Stibi schrieb:

70 Sekunden?
Mal ehrlich, wenn das kein Hinweis auf ein Problem im Zeitmanagement ist, dann weiß ich es ja auch nicht.

By Reinhold Stibi Date 2023-12-09 10:42

Ja, das ist so.

Bei Lc0 ist die ideale Einstellung bei MoveOverhead 70000; das klingt zwar unwahrscheinlich
hoch, ist aber so.
Lothar Jung glaube ich hat 10000 eingestellt; hat aber damit schon einige Partien
auf Schach.de durch Zeit verloren.

Diese Einstellung hat sich in der Praxis bei Lc0 voll bewährt und die Zeiteinteilung bei den
Zügen insgesamt stimmt so.

Am besten selber ausprobieren.