EGF vs AGA pros win-and-continue match

Bill Spight · **#121**

One thing I would disagree with is adjudication. Way back when, I ran a one day local tournament with, as it turned out, too many rounds, not enough time. So for each round I had a time for games to end or be adjudicated. Boy, did I get raked over the coals for that decision! (I had scheduled more rounds because of previous complaints that there were too few rounds. {shrug} BTW, my final solution for those tournaments was to have flights with 6 players maximum per flight and self-scheduling of games after the first. That way we could get 5 games done in one 8 hour day, 10:00 - 6:00.

)

Even kyu players in a local tournament take their games seriously enough that they want them to be decided by their own play. I think they are right. And I think that that principle holds true for pro players in an international tournament, as well.

And if KGS is not flexible enough to receive and pass on local time stamps from the clients, there are other servers out there.

dsatkas · **#122**

jlt wrote:

dsatkas wrote:

I don't understand what the fuss is all about. Mateuz was clearly ahead, there were what 10 moves, basically dame remaining? And he claims he played with a 10 sec margin. Give him the win already and next time plan more carefully the tournament.

The problem is not so much for this game, but for future games if disconnections occur earlier. Clear rules have to be written.

yeah, exactly my sentiment.

daal · **#123**

Uberdude wrote:

Marcel Grünauer wrote:

Bill Spight wrote:

Pardon my ignorance, by why doesn't the software record the time between receipt of the opponent's move from the server and the time the player's move is submitted? Net lag has always been with us, so I would have thought that for timed events the local time taken would be the proper record.

Presumably for the same reason that they don't use the client's timestamp to begin with: It's possible to forge the timestamp. Although it would take quite a bit of effort to forge it and it probably would not be worth it in the context of a game. So maybe KGS considers the server to be the single point of truth and if a client has a problem, then so be it.

Because KGS was written 20 years ago by 1 guy as a hobby, rather than as a serious piece of software for business critical real time operations. And as Marcel says there's a question of trust between server and client so it's not trivial.

It may have been written 20 years ago, but that is no excuse for the current owners not to have addressed the problem. Quite frankly, if I were a pro, I would refuse to play any type of serious game on KGS. I find it baffling that anyone considers it normal that games can be lost due to a technical glitch that happens so often, and that KGS has nothing more to say about it than that it must be a problem on the client's side. There must be a better way of dealing with lag than how KGS does it. You play your move, and half the time there is no indication that there is a problem and then poof, the game is over and you lost. It is just a miserably poor implementation that ruins games and provides for an infuriating user experience. Their troubleshooting page, https://www.gokgs.com/help/faq/troubleshooting.html does not even mention lag! Compare that for example with https://lichess.org/lag or with Chess.com which has a meter showing the quality of both players connections during a game. I have no idea whether it is possible or not to eliminate lag, but I am certain that the user experience on KGS could be vastly improved.

Joaz Banbeck · **#124**

Aram wrote:

No need for estimates. Just do what any pro tournament would due if outside unforseen circumstances halt the play.

Wind back the clock, continue play from the position from where the disruption happened...

I like this solution. As long as proctors ensure that lag cannot be faked.

However, if they cannot, we could end up with the Kazan tesuji. Need more time in a complex position? Let the clock run and claim that it was lag. ( NB: I am not claiming that Surma did or would do such a thing. But some future player in a less clear position might )

However this is decided, the tournament directors should decide soon. The longer they wait, the more the pot gets stirred, and the fewer people will be happy with it - even if it is ultimately the best possible decision.
Indeed, the the tournament directors should have thought about the possible problems that could arise, and made their decisions before the tournament started, so that they could have implemented the decision immediately.

Bill Spight · **#125**

Thanks to daal for the link to the lichess lag page.

lichess wrote:

Lag compensation

Lichess compensates network lag, up to one second per move. After your move, your average network lag is added to your clock. As a result, having a higher network lag than your opponent is not a handicap.

dsatkas · **#126**

Joaz Banbeck wrote:

However, if they cannot, we could end up with the Kazan tesuji. Need more time in a complex position? Let the clock run and claim that it was lag. ( NB: I am not claiming that Surma did or would do such a thing. But some future player in a less clear position might )

The Kazan tesuji...are you for real?

Joaz Banbeck · **#127**

dsatkas wrote:

Joaz Banbeck wrote:

However, if they cannot, we could end up with the Kazan tesuji. Need more time in a complex position? Let the clock run and claim that it was lag. ( NB: I am not claiming that Surma did or would do such a thing. But some future player in a less clear position might )

The Kazan tesuji...are you for real?

I think so. Did I not spell it correctly?

I thought about dubbing it the 'Volga tesuji', for many Americans are more likely to have heard of that word, but I couldn't stand the thought of being responsible for the inevitable pun of a 'Volga move'.

Oberlappen · **#128**

What a mess, I hope they decide soon, or give a hint in which direction the discussions about it where.

xed_over · **#129**

Joaz Banbeck wrote:

As long as proctors ensure that lag cannot be faked.

The proctors should have been "watching" the game from their own separate login as well. Then they could tell if a move (made locally), made it to the server or not.

But this is still just a workaround for KGS' lack of networking robustness.

hyperpape · **#130**

Regarding the outcome, to me it seems like every option has severe downsides. I think resuming the game might be the fairest approach, since the rules didn't specify. However, since each option is bad, I can't fault the organizers, no matter how they choose.

On the technical side, the network lag correction that lichess institutes is for a maximum of one second of predictable lag. A substantial fraction of us who've played on KGS have had the experience of suddenly experiencing lag during a game that previously seemed normal. If your average connection time is 200 ms and then suddenly it's 5 or 10 seconds, a one second fix can't address that. It's a good idea that smoothes over the easy cases, but leaves the hard ones untouched.

The only way to avoid problems with lag or disconnection is to trust the client to say when it is connected, or sent the move. If you do that, you will have widespread cheating (probably not in a professional match like this, but among general users). You can try to fight that, but I believe that it's practically impossible for the developer of a desktop application to win. Because the client sends the timestamp, the user can fake that timestamp. Any attempt to work around that will be a cat-and-mouse game that will suck up the developers' time, and they'll still end up losing.

Bill Spight · **#131**

xed_over wrote:

Joaz Banbeck wrote:

As long as proctors ensure that lag cannot be faked.

The proctors should have been "watching" the game from their own separate login as well. Then they could tell if a move (made locally), made it to the server or not.

Not only that. That would give a good estimate of the netlag to and from the server, if the clients made local time records. Or how about keeping an independent record of netlag by pinging the server?

Bill Spight · **#132**

hyperpape wrote:

Regarding the outcome, to me it seems like every option has severe downsides. I think resuming the game might be the fairest approach, since the rules didn't specify. However, since each option is bad, I can't fault the organizers, no matter how they choose.

On the technical side, the network lag correction that lichess institutes is for a maximum of one second of predictable lag. A substantial fraction of us who've played on KGS have had the experience of suddenly experiencing lag during a game that previously seemed normal. If your average connection time is 200 ms and then suddenly it's 5 or 10 seconds, a one second fix can't address that. It's a good idea that smoothes over the easy cases, but leaves the hard ones untouched.

The only way to avoid problems with lag or disconnection is to trust the client to say when it is connected, or sent the move. If you do that, you will have widespread cheating (probably not in a professional match like this, but among general users). You can try to fight that, but I believe that it's practically impossible for the developer of a desktop application to win. Because the client sends the timestamp, the user can fake that timestamp. Any attempt to work around that will be a cat-and-mouse game that will suck up the developers' time, and they'll still end up losing.

Well, we are not trying to solve the general problem of netlag on KGS, just the netlag problem for a serious tournament.

BTW, is it necessary to go through KGS or any other public go server? A dedicated site could give the tournament organizers better control and might even be more efficient.

Bojanic · **#133**

If proctor is in same room as player, there is a great chance that they will share same connection, Even if they have separate connection, it could be affected by same lag.

xed_over · **#134**

Bojanic wrote:

If proctor is in same room as player, there is a great chance that they will share same connection, Even if they have separate connection, it could be affected by same lag.

very true... and therefore all the more obvious that lag is occurring, since they can see on the player's screen that he submitted the move, and on his on screen that the move did not make the round trip back from the server.

xed_over · **#135**

Bill Spight wrote:

BTW, is it necessary to go through KGS or any other public go server? A dedicated site could give the tournament organizers better control and might even be more efficient.

I've been advocating for a private, dedicated tournament server for years.

Joaz Banbeck · **#136**

xed_over wrote:

Bill Spight wrote:

BTW, is it necessary to go through KGS or any other public go server? A dedicated site could give the tournament organizers better control and might even be more efficient.

I've been advocating for a private, dedicated tournament server for years.

This sounds like a good use of AGA funds.

As Oberlappen noted earlier, the AGA players do not have the same access to face-to-face tournaments that their EGF peers do. So it seems a natural goal for the AGA to ensure that there are online opportunities for their top players.

Violence · **#137**

Ok. I'm reading a lot about the circumstances regarding this situation and how that affects the decision that should be made here, and I think that's really approaching this situation from the wrong perspective.

Tournament policy is founded on tournament philosophy, namely, the idea that the integrity of the tournament must be protected above all else.

This situation should be looked at like this: In a game that was not yet completed, one player ran out of time on the clock, and as a result, the other player was declared the winner by the server. The player who ran out of time claims that they made their move in time, but the server lag prevented the move from being made.

Who each player is and how trustworthy they are is completely irrelevant. The board state of the game is completely irrelevant. Nothing else matters here, because we are trying to determine tournament policy, and basing policy around given circumstances unless they're truly unusual or unique is a bad way of creating policy.

The first thing to do is to try and find proof of the player's claim. If there is evidence that the server that lag did occur and a win was falsely given, then that is certainly a reason to deviate from the given result.

If that is not the case, then in lieu of better options, you must accept the timeout result. If you want to implement ways to check or deal with lag, that is something that must be done in future tournaments. With the policy you have, you have to use what the clock has given you, or else the clock is meaningless, and the integrity of the event is compromised.

If Mateusz was not himself but another player with a history of cheating or underhanded play, you must be able to make the same ruling.

If the game was not almost decided but instead still very much in question, you must be able to make the same ruling.

You cannot resume play from the same position here because you wouldn't have resumed play from the same position had this happened from a board state that was still very much in question, the player would be compromised and would both be able to consult outside assistance for the position, something that compromises the integrity of the game and the event.

You cannot rematch this game, because at any other point in time, for any other player who claims to be experiencing lag and times out as a result, you cannot rematch all of their games, for logistical reasons and common sense.

Regardless of how trustworthy a player is or how good their track record of integrity is, you cannot as a tournament organizer take them at their word if you aren't ready to take every players' statements as fact when you're issuing a ruling like this, it would be blatant favoritism if you treat any player differently, and so when you make these rulings you have to discard what you know about them and what you know about the game state. Those things are completely irrelevant here.

Unless there is evidence that supports Mateusz's claim that him running out of time was due to KGS and not him, you have to accept the KGS result as the result.

xed_over · **#138**

just posted a few minutes ago: https://www.facebook.com/transatlantict ... 7416945998

tpgtc wrote:

A tournament team that includes officials from the EGF, the AGA, KGS, and the tournament referee (Myungwan Kim 9P) is still reviewing the case of the 4th match. We will announce the official decision as soon as it's confirmed. Thank you for your patience.

Kirby · **#139**

Also from Facebook: https://medium.com/@EuroGoHebdo/transat ... 15e0191988

I still don't understand the reference to "Kazan"...

Kirby · **#140**

Violence wrote:

The first thing to do is to try and find proof of the player's claim. If there is evidence that the server that lag did occur and a win was falsely given, then that is certainly a reason to deviate from the given result.
...
Unless there is evidence that supports Mateusz's claim that him running out of time was due to KGS and not him, you have to accept the KGS result as the result.

What do you propose should happen in cases where there is evidence of timeout due to KGS lag?

EGF vs AGA pros win-and-continue match

Who is online