Probably the easiest thing for me is to run the programs via remote shell (ssh) using my own self-tester. I don't remember how my self-tester works but my chess and shogi self-tester multiplexes games, so it's a trivial setup, except that I would have to make the modification to restrict the number of connections to any particular machine (and this would need to be configurable.)
The reason for this is that my tester(s) assume everything is running on one machine (and I specify how many simultaneous games to allow) but if a given player has not played as many games as another player, it would schedule several games with that one player. But it would not be good if 20 instances of "[email protected] /home/joe/bin/zen -level 10000" needed to be scheduled since they would all be running on the same machine. If it were not for that, I would not need to make ANY modifications to the tester, I could just configure each player using that form assuming I set up the ssh keys properly and have an account on foobar.com. Another problem with the autotester is that it only knows how to play round robin matches, but that is not a big problem since I can partition the test easily enough. What I would do is run a full round robin just long enough to get reasonably stable ratings, then based on the ratings I could partition the players into separate sections by strength. And from time to time I would re-calibrate the ratings and change the partitions sizes in order that all the players have good interaction are not playing in isolated rating pools. I have not looked too closely but if my go tester does not multiplex games I can still simply run several instances of it. I just want to find a setup that does not require too much babysitting on my part. Don On Sat, Jun 18, 2011 at 7:08 PM, Michael Williams < [email protected]> wrote: > You could write a new server that uses a CGOS-compatible interface so that > the CGOS clients can be used. The server would always match-up two engines > from the same IP address that start with the same name prefix. And would > only run one game at a time for that IP address and prefix. On the client > side, you would run several instances for each CPU core, but only two of > them would be in a game at the same time (against each other). > > Or something like that. > > > > On Sat, Jun 18, 2011 at 6:50 PM, Don Dailey <[email protected]> wrote: > >> >> >> On Sat, Jun 18, 2011 at 6:25 PM, Jacques Basaldúa <[email protected]>wrote: >> >>> 1. Perhaps Erica may be of help. 10 months ago it >>> won the Olympiad, so it should be strong enough. If >>> Aja is so kind to let us copy of the binary. >>> >>> 2. I can donate cpu, but it will be better in 3 weeks >>> when I return from a short holiday and have a new >>> machine more. >>> >>> 3. Maybe the idea of using a special CGOS makes it >>> easier for everybody. >>> >> >> I thought of CGOS, but CGOS is a terrible solutions for this specific >> thing because it would have to be configured for a really long time control >> in order to avoid time forfeits. But it will not schedule a round until >> all games are complete from the previous round so most computers would be >> idle most of the time. It would be better to have a system that keeps all >> computers busy all of the time. >> >> On the other hand, that is a pretty simple way to do it but don't know if >> we would have the patience for it ... >> >> The previous study was good because it represented a huge amount of CPU >> effort, it was not just running a few games for a couple of days but it was >> thousands of games played on 40 or 50 cores over a period of weeks. I >> don't think CGOS would be good for this. >> >> I'm still thinking about how it might be done without a huge amount of >> effort on my part - I would really like to do this study. >> >> Let me ask the group this question: How do you run automated testing >> under CGOS conditions (other than using CGOS?) What tools are available >> that work under Linux? >> >> Don >> >> >> >> >> >>> >>> >>> Jacques. >>> >>> >>> >>> >>> >>> >>> ______________________________**_________________ >>> Computer-go mailing list >>> [email protected] >>> http://dvandva.org/cgi-bin/**mailman/listinfo/computer-go<http://dvandva.org/cgi-bin/mailman/listinfo/computer-go> >>> >> >> >> _______________________________________________ >> Computer-go mailing list >> [email protected] >> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go >> > > > _______________________________________________ > Computer-go mailing list > [email protected] > http://dvandva.org/cgi-bin/mailman/listinfo/computer-go >
_______________________________________________ Computer-go mailing list [email protected] http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
