Simultaneous games question

[lemonsqueeze]

Hi, i'm trying hook up Pachi to gtp2ogs, see how it does on ogs.
So far it's working fine for single games, but looks like i'm having an issue with simultaneous games.

How is it supposed to work at the moment ? gtp2ogs spawns one engine instance per simultaneous game ?
(trying live games atm, running with --persist)

Looks like this is what's happening, my engine script gets spawned again when the 2nd game starts and it's not happy about it. Maybe i need PR #44 to use a single instance instead ? But this only works for correspondence games i guess...

Otherwise i can fix my side to handle multiple instances, but i need a way to set max number of simultaneous games (if it spawns 30 instances it's going to be an issue ...)

[roy7]

Hi there! Yes OGS's model is basically that a bot plays all the games at once that people want. (I think the KGS model might be bots play one game at a time only, I'm not sure.)

If you want to stick to only slower time settings you could see about changing --corrqueue in some way to try and only work on one game at a time for cpu/gpu purposes (like turn it on but use it for all games not just correspondence games). If you turn off --persist, it'll restart your bot fresh for each move. I added --persist since I wanted the prior tree search in Leela to stick around from move to move.

There's no easy way atm to "reject matches if a match is under way" although it has been requested before. I'm not sure if Tokumoto ever added that in his own bots. It has been requested before but I never wrote it up myself.

[lemonsqueeze]

Thanks, this makes sense. Yes, i'm a bit new to the ogs model.

Managed to get simultaneous games working !
For now i let it spawn multiple instances and they have a queue to decide whose turn it is to run.
This works pretty well with a few simul games, but it becomes an issue when too many people start hammering the thing at the same time. I guess it's the same with Leela, how do you deal with it ? Just require big enough time settings to avoid timeouts ?

I'd rather avoid running without --persist, starting a new instance for each move is quite slow. But then if it solves all the timeout / concurrency issues maybe it's worth looking into...

I'm thinking maybe best is to signal gtp2ogs to start/stop accepting new games. I could check system load from time to time and restart it with --rejectnew when it gets too much (--rejectnew isn't going to affect active games, is it ?)

[roy7]

--rejectnew won't affect ongoing games, it just rejects new challenges. But you can go to the accept challenge part of the code and maybe add a check for your system load so you reject if load is too high.

With my bots I just accept all of the games and hope for the best as the GPU gets stretched really thin. :) I turn off pondering for unranked games, and I turn off using the GPU for correspondence games.

[lemonsqueeze]

That would be cleaner than the rejectnew hack =)
It doesn't work too bad actually, just tried something this afternoon. Not very user friendly though, with --rejectnew players just know their game request was rejected but they don't know why. It'd be nice to be able to pass a custom message, like "Bot is busy at the moment, please try again in a few minutes."
Shouldn't be too hard i guess.

[roy7]

Yeah that's a feature request to OGS, but not something I can provide. It is a server level feature.

[TokumotoK]

Limiting the number of ongoing live/blitz games is a feature I've been asking roy7 for years :P
Also, "Bot is busy at the moment" or "Your challenge is declined because XXX" is something I want badly, but I've found that opening the api for bots to send private messages is difficult for it means someone could code a spam bot.

[lemonsqueeze]

Ok, i'll check with server team.

@TokumotoK no need for private messages, we just need a way to tell the server which msg to use in the popup instead of "Game offer was rejected", right ?

[roy7]

Correct, if there was a way in the API to optionally send a message back to server when we reject a game challenge, it could display on the "game rejected" popup message box was my thought.

Would need some love from @anoek though.

[anoek]

Hey all, I'll try and give the bot system some attention this and next week, this should be pretty feasible to get in place.

[roy7]

@anoek Thanks! :) If you like, the /devel branch of gtp2ogs could go ahead and do a fresh release and merge into /master. I have permissions on that but I don't want to mess up the tagging/etc. If you don't mind giving the /devel changes a sanity glance. This way people out of the blue pulling down master will be in sync with most of the bot operators.

[lemonsqueeze]

Oh wow, thanks for all the attention !
Just created an issue, but looks like it wasn't necessary =)

[anoek]

Ok that turned out to be way less trouble than I thought it would be. Sorry it took so long @TokumotoK, I know you've been wanting that for awhile.

You'll see I updated gtp2ogs to utilize a newly created post method to reject challenges, this method accepts a message field for custom messages. I put a generic one in there for now, I leave it to y'all to put meaningful messages in there as to why a challenge was rejected.

Everything should be live and ready to use. Enjoy!

@roy7 How about I'll do a release in a day or two after you guys have had a chance to make whatever custom messaging changes you want to make?

[roy7]

Awesome! I've got some plans tonight but hopefully tomorrow I'll see about working with that. My intent will be to add custom messages into every accept/reject decision in gtp2ogs. Maybe even store them all up in the string so the reject notice will mention every reason why at the same time.

[TokumotoK]

Thank you, thank you, thank you

[roy7]

@anoek I added a PR with tons of messaging. I didn't merge it immediate since I didn't have time to test it but I think it's very straight forward. I also merged an error catching branch and my corrqueue feature too.

[lemonsqueeze]

Thanks !

[roy7]

@lemonsqueeze and @TokumotoK I have added support to limit the max # of games the bot will play at a single time. I'm not 100% confident in my approach until it gets a good amount of testing and never deadlocks, my fear is there might be some way a game ends but disconnect() isn't called so it will think we're at the max forever? Maybe this fear is groundless. Regardless, I have a branch here:

https://github.com/roy7/gtp2ogs/tree/maxtotalgames

that lets you do --maxtotalgames 1 to only play 1 game at a time. Motivated by @wonderingabout's frequent requests. ;)

[roy7]

And enhancement I could make is to automatically apply --hidden any time you are at the cap, so you don't appear in the list if you won't accept their game. Just to make a better user experience.

[wonderingabout]

nice !!!

as i said, people with limited GPU power cant play many games at the same time or thinking time is too long

big thanks to everyone !!!

[wonderingabout]

actually @roy7

as @lemonsqueeze just highlighted to me by mail today, theres the issue of correspondence games

let's imagine there are 10 correspondence games , and --maxtotalgames 10

then if --persist is set to ON (pondering makes the bot stronger), then no one will be able to play any live game

what i suggest is to make 4 new arguments

--maxtotalgames (same)
--maxtotalgamesblitz
--maxtotalgameslive
--maxtotalgamesnoncorr (would be the max number of live+blitz games)
--maxtotalgamescorr

if we do that @roy7 , then we could fix the example i mentionned like that :
--maxtotalgamescorr 5 --maxtotalgamesnoncorr 5

to improve it even further, we may improve the --persist into 4 new arguments as well :

--persist (same)
--persistnoncorr (persist only for non correspondence games)
--persistlive
--persistblitz
--persistcorr

then the fix would be even better, for example

--maxtotalgamescorr 10 --maxtotalgamesnoncorr 3 --persistnoncorr --maxactivegames 1

a dream command to run lol

[roy7]

Good catch. I was sort of picturing only live play bots would use this. I'll make improvements.

[TokumotoK]

Thanks a LOT!

To me, Persist and Limiting the number of simultaneous games is needed only for Live/Blitz. Limiting them for corres does not make sense somewhat going against the nature of corres, except for another problem.

Problem is, people pause games and forgets about them, thereby increasing the number of simultaneous/persist games for bots, and this is a separate issue that applies to live/blitz as well. This should be handled with "--maxpausetime" or "--maxpausedays" as I requested separately.

@anoek Isn't it about time the devel branch got merged ? I mean after roy7 makes the improvements.

[wonderingabout]

@TokumotoK

roy7 asked that me and aquabot run some tests of it first before merging it

by that time, hopefull @roy7 will add the improvements we mentionned earlier

and you can already test it, no need to wait for merging, see :

https://github.com/wonderingabout/gtp2ogs-tutorial/blob/master/docs/3A3-linux-optional-upgrade-to-devel.md
https://github.com/wonderingabout/gtp2ogs-tutorial/blob/master/docs/3B3-windows-optional-upgrade-to-devel.md

[lemonsqueeze]

https://github.com/roy7/gtp2ogs/tree/maxtotalgames

@roy7
Nice, i was thinking for correspondence games maybe the easiest it to make --maxtotalgames imply --corrqueue this way there is at most one instance dedicated to them. Then for --maxtotalgames 10 we can allow 9 live games, keeping one for correspondence games which can wake up anytime.

[wonderingabout]

@lemonsqueeze

i dont think its a good idea, because as @TokumotoK said, the number of corr games should be unlimited, or at least very high

the issue is rather with --peristnoncorr i think (its persist that takes gpu power, not the number of corr games, and theres no reason to persist in corr games, only blitz and live

[TokumotoK]

I don't intend to wait for the merge at all if it works.
My point is, --maxtotalgames does not work without --maxpausetime. Those bots that play a lot of games are bound to have players pausing and forgetting about the game, so the bots with --maxtotalgames, --maxtotalgameslive or similar set will stop playing any game sooner or later as the limit is filled with ongoing paused games.

[wonderingabout]

the expiring time is another issue indeed, but wouldnt that be a problem for ranked games ?

if you set an expire time of say one week, then your bot's rank will be abused (for unranked games its fine though)

edit : maybe i dont understand well what would be the purpose of you using maxpausetime

edit 2 : theres an easier way : just use --nopause , its what i use in all my bots
like that pause is not allowed, and when you think of it theres no reason to pause against a bot :

-> you want more time ? dont play live game but play corr instead
-> you will be afk for 1 month ? then start a new game when you come back (you may use fork to resume where you left)

adding --nopause may actually make the bot games organization healthier

[TokumotoK]

No. Imagine --maxtotalgames is set to 4. Four players pausing a game and forgetting about it will fill it, prohibiting the bot from playing other games.

Being able to pause against a bot is a major advantage of playing a bot as opposed to a human. So using --nopause negates one of the attractiveness of playing against a bot. We don't want to prohibit players from pausing. We just want to limit the pause period, so that forgotten games will expire in a reasonable period.

[wonderingabout]

ok i understand now, but then why not just play a corr game if the player wants a long time ? (instead of pausing a live game)

that would fix the fillling game slots issue, if --persistnoncorr is implemented

[TokumotoK]

Yeah, tell that to the many players who 'forgets' that they've paused a game.

[wonderingabout]

if you disable pause, they cant forget that they have paused :)

also, i want to mention that --maxtotalgames is not the actual total number of games

its the number of connected games
with --persistnoncorr , the number of connected games would be 0 most of the time for corr games

edit :

see : https://github.com/roy7/gtp2ogs/blob/maxtotalgames/gtp2ogs.js#L1535

(the next 10 code lines starting from here)

maybe i should ask @roy7 to rename it --maxconnectedgames to make it clearer

[TokumotoK]

Let me say this again. "Being able to pause at will, for bathroom, lunch, dinner, etc." is a MAJOR advantage of playing against a bot, as opposed to creating nuisance to the human opponent. We just need to limit it.

[wonderingabout]

ok, i leave that choice to you

if you ask me though , i would just play a corr game with very large time settings

but you raised the point that --maxtotalgames is not a clear name indeed

maybe we should rename it --maxconnectedgames

and again this shows how this issue is related to the need of --persistnoncorr that we also need

[roy7]

Pausing didn't even occur to me since I've used --nopause for ages on all of my own bots.

Persist shouldn't have anything to do with the size of the connected_games list. Persist just means the bot engine isn't killed/restarted for each move (ie: the engine remains in memory waiting for the next move, so things like prior search results can remain cached/etc). It won't use extra GPU time if your bot doesn't do pondering. Pondering on or off is a bot specific decision by the operator outside of gtp2ogs.

My initial thought on corr games is just not to count them at all with --maxtotalgames. Or maybe I'll rename it to --maxlivegames. Then we just need to count all of the connected_games that aren't using corr time controls. For people who support corr on their bots and want to reduce GPU impact, that's what --corrqueue is for. (I added that since I one had someone playing like 10+ corr games and they'd make all the moves at one time, causing me to run 10 copies of Leela at the same time, doh.)

I should probably add a way for persist to not affect corr games as an option though, so need to keep the process in memory for possibly days. The GPU can only keep so much data in memory before it runs out. (I think on my own bots I started using a 24 hour persist timeout just to prevent too many piling up.)

[wonderingabout]

yes i of course use --nopause too on all my bots (again, if you want longer time settings, just play a corr game with long time settings)

My initial thought on corr games is just not to count them at all with --maxtotalgames.

yes, that works (it would not address all cases though like the one where one bot operator wants to limit the number of max corr games)

--maxlivegames doesnt include blitz, how about --maxnoncorrgames or --maxblitzlivegames (assuming corr games get excluded

also as you said earlier i use pondering for my bot

i'm interested in you --corrqueue argument too @roy7 , but i'm not sure if it will have the behaviour i want : disabled pondering on corr games only

I should probably add a way for persist to not affect corr games as an option though

yes !!!! i think the same, and it's what i want :)

it seems like the natural behaviour of how --persist should behave btw (theres no reason to do pondering in corr games), so we may just set it as the default behaviour for --persist

[wonderingabout]

any news @roy7 ?

[roy7]

No, it's Christmas and I have a sore throat, I'm just relaxing. :)

[wonderingabout]

oh ok, have fun and please tell us when you have any news @roy7 :)

[roy7]

@wonderingabout Should this issue be closed? I believe we/you did add support for max # of games in the past?

[wonderingabout]

@roy7 sorry for the delay, i didnt notice your message!

yes, the main issue is solved now that we have --maxconnectedgames and --maxconnectedgames per user :)

other issues should be adressed separately in their own PRs

so yes we should close this issue 💯