Can we make the clients ssh to a server? I think that's how the last study worked. Also, I think the last survey had both participants on a single machine, and that the machines uploaded results periodically.
This design would a) work with the fact that many personal computers do not have incoming ssh enabled, and b) machines may not be devoted to this task 24x7. A lot of people could enable a tournament during night time, provided that both "opponents" were on the same machine, eliminating scheduling problems. Terry McIntyre <[email protected]> Unix/Linux Systems Administration Taking time to do it right saves having to do it twice. ________________________________ From: Don Dailey <[email protected]> To: [email protected] Sent: Sun, June 19, 2011 5:09:59 PM Subject: Re: [Computer-go] scalability study On Sun, Jun 19, 2011 at 4:48 PM, Michael Williams <[email protected]> wrote: I get it. But ssh access is a barrier to participation. Even though I want to do this study, I don't have the time or energy to build a distributed auto-tester just for this "one-off" experiment. Windows is horrible for one-off experiments like this but Linux is built around useful abstractions and tools that can be combined in useful ways. I'm just trying to find a way that makes it possible to organize this experiment without requiring me to donate 200 man hours of my time. I'm actually thinking about the CGOS client now. I talked about how CGOS itself is not suited to this experiment, but I might be able to modify the simple CGOS client to connect to a local process that pretends it's a GTP Go program and so it would run on any OS. I'm also open to suggestions. Don On Sat, Jun 18, 2011 at 7:58 PM, Don Dailey <[email protected]> wrote: > >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 >>>>> >>>> >>>>_______________________________________________ >>>>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 >> > >_______________________________________________ >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
