Re: [computer-go] How to properly implement RAVE?
I actually tried leaf parallelization first, but after reading the mentioned paper I switched to an implementation of root parallelization (as described). I'm not sure if I implemented it correctly (like in my description), but after testing a 2-core-version against a single- core-version with a few games, I can say the dual core version wins at least 75% of the games, which I think would be an ELO difference of about 200. I have yet to switch colors but the results should be similar. -ibd There were a couple of papers [2] at CG2008 on this subject. The consensus seemed to be that root parallelization [1] was best. In fact Guillaume Chaslot's version got a strength speedup of 3.0 using 2 threads, and 6.5 using 4 threads (dropping to 14.9 with 16 threads). This is of course impossible, and implies the parallel version is somehow doing MCTS better than the single thread algorithm! Darren [1]: Build multiple MCTS trees in parallel, one per thread. No communication. At end add the trees together and use grand total to select move. [2]: http://www.cs.unimaas.nl/g.chaslot/papers/parallelMCTS.pdf and A Parallel Monte-Carlo Tree Search Algorithm by Tristan Cazenave (I couldn't seem to find a PDF link.) -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] time measurement
On Tue, 2009-02-03 at 10:41 +, Nick Wedd wrote: Providers of Go servers claim that it would be pointless to try to implement client-side time, as players would be able to cheat by hacking their clients and fiddling with the clock. I don't doubt that they would try to cheat, indeed I know that they would; but providers of chess servers have been able to prevent cheating. As I understand it, their clients perform CRC checks on themselves to ensure that they have not been hacked, and the packets they send are CRC-checked by the server to ensure that the packets have not been hacked. And how does the chess server know when I suspend my cable modem or yank the plug from the wall to give my program (or myself?) more time to think? It looks exactly like lag. That's the easy, crude way. I'm also willing to bet that any client-side CRC check could be hacked, in exactly the same way that people hack software piracy checks. I mentioned last time we discussed network lag that on the chess server FICS there were constant accusations of cheating based on timeseal. I haven't played there in years, but I'd be surprised if the situation has changed. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] time measurement
On Tue, Feb 03, 2009 at 10:41:53AM +, Nick Wedd wrote: Providers of Go servers claim that it would be pointless to try to implement client-side time, as players would be able to cheat by hacking their clients and fiddling with the clock. I don't doubt that they would try to cheat, indeed I know that they would; but providers of chess servers have been able to prevent cheating. As I understand it, their clients perform CRC checks on themselves to ensure that they have not been hacked, and the packets they send are CRC-checked by the server to ensure that the packets have not been hacked. Sorry, I don't buy that. It may work with an audience of human players who are not good programmers. But for a person who is already writing a go-playing program, and the whole time management in it, adding what ever cheats sounds trivial. Besides, this would add an extra layer of complexity to be programmed, with new chances for mistakes. All in all, I think this is a messy and unreliable solution to a problem I have not seen happening. For what it is worth I vote against client-side time controls. - Heikki who admittedly doesn't even have a functional program at the moment -- Heikki Levanto In Murphy We Turst heikki (at) lsd (dot) dk ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] time measurement
I would not want to discourage remote players - some systems are designed to take advantage of large supercomputers which are not very portable. However, remote players need to accept the trade-off. They get to avoid the trouble of packing up and shipping a trailer full of computer gear to the other side of the world. The downside is that network lag happens. As others have mentioned, client-side timing can be gamed by the simple expedient of pulling the plug to the modem; I can think of a few ways to manipulate iptables which would have similar effects. I hope that tournament organizers do their best to provide a decent connection. Remote participants need to do likewise. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] time measurement
if it really mattered, remote participants could use a phone to connect -- it's not like these are very high-volume transmissions, and the latency, while high, is still an unimportant fraction of total time. on the plus side, the latency is exact. on the minus side, it's a pretty expensive phone call. :) s. On Tue, Feb 3, 2009 at 12:03 PM, terry mcintyre terrymcint...@yahoo.com wrote: I would not want to discourage remote players - some systems are designed to take advantage of large supercomputers which are not very portable. However, remote players need to accept the trade-off. They get to avoid the trouble of packing up and shipping a trailer full of computer gear to the other side of the world. The downside is that network lag happens. As others have mentioned, client-side timing can be gamed by the simple expedient of pulling the plug to the modem; I can think of a few ways to manipulate iptables which would have similar effects. I hope that tournament organizers do their best to provide a decent connection. Remote participants need to do likewise. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] time measurement
On Feb 3, 2009, at 2:34 PM, Heikki Levanto wrote: All in all, I think this is a messy and unreliable solution to a problem I have not seen happening. For what it is worth I vote against client-side time controls. Maybe you haven't seen it. That doesn't mean it doesn't exist. I've lost games on KGS because it took too long for my opponent's move to arrive. Made me lose the game before even given a split-second to respond. Client-side time-control would have prevented that. If the problem exists for human play it exists for computer play. I always thought that security-certificates, signed applications and public-key encryption were well equipped to tackle a problem like this. But I'm certainly no security expert. Mark ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] How to properly implement RAVE?
On Sun, Feb 1, 2009 at 4:46 PM, Isaac Deutsch i...@gmx.ch wrote: By the way, I got about 75 ELO points (1650-1720) with light playouts out of RAVE. Do you think this is in the expected range? It's not really similar to the 20%-60% win rate rise vs. GnuGo described in some papers... My bot is about 1/4-1/2 of the speed of yours, but here are my strength numbers (median of reported bayeselo numbers below): HouseBot Rango_004 RAVE - 1778 ELO 1721 ELO UCT- 1587 ELO 1642 ELO Given the tremendous speed difference between our bots, I suspect you may have some debugging to do :( I'll try to put my bot up on CGOS again in the next few days. Maybe some head to head games will best answer how our implementations compare to each other. HouseBot parameters: One search thread Max 50k playouts per move (time control may reduce) No pondering Variants with RAVE in the name: UCT+RAVE Variants with UCT in the name: UCT without RAVE hb-797-RAVE-50k 1826 hb-791-RAVE-50k 1778 hb-819-RAVE-50k 1715 hb-799-UCT-50k 1606 hb-797-UCT-50k 1605 hb-770-UCT-50k 1570 hb-791-UCT-50k 1556 ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Vacation reply
Thanks to massive amounts of spam, I no longer monitor this account. Please update your address book with my new address (joe.hebl at gmail.com). Thanks, Joe ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] time measurement
On Tue, Feb 03, 2009 at 03:51:14PM -0200, Mark Boon wrote: On Feb 3, 2009, at 2:34 PM, Heikki Levanto wrote: All in all, I think this is a messy and unreliable solution to a problem I have not seen happening. For what it is worth I vote against client-side time controls. Maybe you haven't seen it. That doesn't mean it doesn't exist. True enough. I always thought that security-certificates, signed applications and public-key encryption were well equipped to tackle a problem like this. But I'm certainly no security expert. No amount on crypto-mumbo-jumbo will solve the problem that the server will have to trust the program, and its author. Signing can provide some little assurance that the program running today is the same as was running yesterday, but that's about all. As long as we can write our own programs, there is no way to stop us from cheating in them, intentionally or by accident. I still think the that such time controls would take too much work to implement, make it easier to cheat, and offer no reasonable solution to a problem that may not warrant it. But that is, of course, my opinion. -H -- Heikki Levanto In Murphy We Turst heikki (at) lsd (dot) dk ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] time measurement
In a recent posting I used the phrase client side time. Someone has asked me what I meant. As well as answering him, I am posting my answer here, for three reasons: (1) to inform those who do not know, (2) to invite correction from those who know better than me, (3) as a gentle nag to any Go server programmers who be read this. Client side time means that the clients, rather than the server, measure the time used by the players. This means that only the time which the player has available for thinking is counted against him. So the way a good chess server works is: The server sends my opponent's move to my client. My client starts my clock and displays my opponent's move. I think, my clock ticks. I input my move to my client, my clock stops ticking. My client sends my move to the server. This differs from the way Go servers work (or at least, all Go servers that I know about). With Go servers, time for both players is measured by the server. This has the disadvantage that communication time is counted against the player, increasing both the time used (which does not matter much) and its variance from random netlag (which matters a lot). Providers of Go servers claim that it would be pointless to try to implement client-side time, as players would be able to cheat by hacking their clients and fiddling with the clock. I don't doubt that they would try to cheat, indeed I know that they would; but providers of chess servers have been able to prevent cheating. As I understand it, their clients perform CRC checks on themselves to ensure that they have not been hacked, and the packets they send are CRC-checked by the server to ensure that the packets have not been hacked. Nick -- Nick Weddn...@maproom.co.uk ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] time measurement
In message 1233686072.20891.9.ca...@acer-debian, Jeff Nowakowski j...@dilacero.org writes On Tue, 2009-02-03 at 10:16 -0800, Ian Osgood wrote: Frankly, I'm baffled that nobody in the online Go world cares about network lag. Timeseal has been a mature technology on the chess servers for over a decade. I logged into FICS today for nostalgia and one of the first thing I see is somebody complaining on channel 53 about somebody lag cheating. What sort of cheating does he complain about? Does he provide evidence that it happens? rec.games.backgammon has frequent complaints about rigged dice, but I would not take them seriously. It's just a can of worms to require some proprietary binary that people have to use, trust, and believe is unhackable. Whenever I have connected to a server, for Go, chess, or any other game, I have used a proprietary binary, the client. I have never found this a problem. And remember, pulling your network cable from the wall is an unstoppable hack. Yes, but it only gives you more pondering time, not more full thinking time. Nick -- Nick Weddn...@maproom.co.uk ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] time measurement
This is the timeseal web site: http://www.unix-ag.uni-kl.de/~chess/soft/timeseal/ Looks like an interesting read. Terry McIntyre terrymcint...@yahoo.com -- Libertarians Do It With Consent! - Original Message From: Jeff Nowakowski j...@dilacero.org To: computer-go computer-go@computer-go.org Sent: Tuesday, February 3, 2009 10:34:32 AM Subject: Re: [computer-go] time measurement On Tue, 2009-02-03 at 10:16 -0800, Ian Osgood wrote: Frankly, I'm baffled that nobody in the online Go world cares about network lag. Timeseal has been a mature technology on the chess servers for over a decade. I logged into FICS today for nostalgia and one of the first thing I see is somebody complaining on channel 53 about somebody lag cheating. It's just a can of worms to require some proprietary binary that people have to use, trust, and believe is unhackable. And remember, pulling your network cable from the wall is an unstoppable hack. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: remote time measurement
My theory is that the organizers of tournaments with remote participants could appoint official observers, to observe the operators at the remote end of connections. Not foolproof, but simple and doesn't interfere with the conduct of the tournament. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] How to properly implement RAVE?
On Tue, Feb 3, 2009 at 1:53 PM, Isaac Deutsch i...@gmx.ch wrote: Hi Jason, Thanks for your numbers. I might try to limit my bot to 50k playouts and 1 core, but I usually simulate as long as time permits. That kind of setup should make it easier to compare. There have been a few times in the past where multiple authors posted similar bots with the same configurations and let them all duke it out on the server for a while. Once upon a time, I was the owner of a bot that was performing far worse than yours and trying to figure out why. I forget who owns myctest, but they were very willing to run a bot to help me out. Do you suspect my pure UCT version has bugs, too, judging from its rating? Maybe, but it's not all that likely. It could be that your RAVE implementation isn't buggy either. IIRC, when I was running my bots, there were very few bots in the 1600-2100 ELO range. That may have skewed my results. I find it hard to find good tests for the correctness of a program depending on randomness, and even harder to find bugs. I created a bunch of unit tests to test very specific cases with my search. Looking at http://housebot.svn.sourceforge.net/viewvc/housebot/branches/0.7/search/uct.d?view=markupthose tests are as follows: - (line 743) Exploitation of perfect children - Two children with 100% winning rate. Run 100 simulations and ensure that only one child was explored. - (line 767) Evaluation of foced sequences - Commented out. I never added that functionality (Auto-expand when only one follow-up move is available) - (line 777) Recognition of a lost position - The end of the game is one move away, and the game is lost. Ensure that each leaf is evaluated once and that the search stops and declares the position as lost - (line 793) Recognition of a won position - The end of the game is one move away and the game is won. Ensure that only one leaf is evaluated and that the search stops and declares the position as won - (line 809) Two ply search of a won position - (line 834) Searches with solved children (some won, some lost) - (line 862) Searches where a winning subtree gets solved through a transposed position - Multiple paths exist to the same subtree. Force the evaluation through one path to complete and then force the evaluation through another path and ensure the conclusion is picked up - (line 894) Searches where a losing subtree gets solved through a transposed position - (line 924) Searches where a losing terminal gets solved through a transposed position I focused most of the tests on terminal positions that were easier to understand how they should turn out. It also had the nice side effect of helping me speed up my endgame handling in addition to helping me find several bugs that had been plaguing my bot. Maybe we can set up our bots to play under similar circumstances on CGOS. Yes, I'll set it up soon (but probably not today). Regards, Isaac My bot is about 1/4-1/2 of the speed of yours, but here are my strength numbers (median of reported bayeselo numbers below): HouseBot Rango_004 RAVE - 1778 ELO 1721 ELO UCT- 1587 ELO 1642 ELO Given the tremendous speed difference between our bots, I suspect you may have some debugging to do :( I'll try to put my bot up on CGOS again in the next few days. Maybe some head to head games will best answer how our implementations compare to each other. -- Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] time measurement
On Tue, 2009-02-03 at 10:16 -0800, Ian Osgood wrote: Frankly, I'm baffled that nobody in the online Go world cares about network lag. Timeseal has been a mature technology on the chess servers for over a decade. I logged into FICS today for nostalgia and one of the first thing I see is somebody complaining on channel 53 about somebody lag cheating. It's just a can of worms to require some proprietary binary that people have to use, trust, and believe is unhackable. And remember, pulling your network cable from the wall is an unstoppable hack. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] time measurement
- Original Message From: Gian-Carlo Pascutto g...@sjeng.org Heikki Levanto wrote: No amount on crypto-mumbo-jumbo will solve the problem that the server will have to trust the program, and its author. Signing can provide some little assurance that the program running today is the same as was running yesterday, but that's about all. As long as we can write our own programs, there is no way to stop us from cheating in them, intentionally or by accident. Very true. To the people that point to timeseal on the chess servers: both the binaries and the protocol itself are trivially reverse engineerable. I know of at least 2 people (not counting myself) who have done this. Because the client side is fully under your control, you can cheat all you want with this system. But you can also write a client for a non-supported platform :) The only reason why this doesn't create more problems is that the people who have the ability to do this reverse engineering usually have better things to do with their time than to cheat on chess servers. It's like copy protections: it stops some people, but it sure as hell ain't secure in any meaningful sense. So it's trustworthy enough the people accept it as a palliative for net lag, in an environment where most people can be trusted. From browsing chess-specific web sites, there are customs and procedures for dealing with cheats. In this day and age, unless you're in the boonies, only so much net lag is believable. Preserving one's reputation is a good enough incentive for most people to do the right thing. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] time measurement
On Tue, 2009-02-03 at 18:54 +, Nick Wedd wrote: What sort of cheating does he complain about? Does he provide evidence that it happens? He couldn't flag his opponent when he ran out of time. Of course this could just be lag, or maybe he killed his process when he was losing. Once you introduce allowances for lag there's no way of telling if it's legitimate or intentional. Whenever I have connected to a server, for Go, chess, or any other game, I have used a proprietary binary, the client. I have never found this a problem. Keeping up-to-date binaries for all platforms tends to be a problem. That's why KGS runs on Java -- which tends to be trivial to hack. For something like FICS, there are many open source clients or clients built for particular platforms, so finding a suitable one is easy. However, the timeseal binary itself is separately maintained and compiled for many platforms. Yes, but it only gives you more pondering time, not more full thinking time. If the game is being relayed live then I can delay the timesealed connection (traffic shaping isn't hard) after my program makes its move but before the opponent responds, and on another connection anonymously observe the opponent's reply and enter it manually into another running copy of my program. Now I have as much thinking time as I want. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] time measurement
there are two solutions. first, we have the preferred solution: a real time system. optimally Fischer time, acceptably Byo-Yomi. second, the Someone Else's Problem solution: tournament organizers provide connection points on servers they manage, in multiple countries, with the manager servers implementing timeseal. edge cloud points are now available, and this would be a small matter of programming. thanks for opening the thread Nick, and thanks Ian for pointing the way to an answer. On Tue, Feb 3, 2009 at 10:16 AM, Ian Osgood i...@quirkster.com wrote: On Feb 3, 2009, at 8:34 AM, Heikki Levanto wrote: On Tue, Feb 03, 2009 at 10:41:53AM +, Nick Wedd wrote: Providers of Go servers claim that it would be pointless to try to implement client-side time, as players would be able to cheat by hacking their clients and fiddling with the clock. I don't doubt that they would try to cheat, indeed I know that they would; but providers of chess servers have been able to prevent cheating. As I understand it, their clients perform CRC checks on themselves to ensure that they have not been hacked, and the packets they send are CRC-checked by the server to ensure that the packets have not been hacked. Sorry, I don't buy that. It may work with an audience of human players who are not good programmers. But for a person who is already writing a go-playing program, and the whole time management in it, adding what ever cheats sounds trivial. Besides, this would add an extra layer of complexity to be programmed, with new chances for mistakes. All in all, I think this is a messy and unreliable solution to a problem I have not seen happening. For what it is worth I vote against client-side time controls. - Heikki who admittedly doesn't even have a functional program at the moment -- Heikki Levanto In Murphy We Turst heikki (at) lsd (dot) dk Perhaps you misunderstand how this is implemented for the chess servers. The server authors themselves provide the client authentication service. It acts as a filter between any go client and remote server. On ICS, this was called timeseal. Instead of your go client connecting to the server directly, it connects via pipe or local socket to timeseal, and timeseal makes the authenticated connection to the remote server. In the past, this timeseal component was distributed as an opaque binary for various hosts as a means of hampering reverse engineering. In other words, the burden is on the Go server author to implement both the client and server sides of the timeseal protocol. Individual Go program authors simply download the timeseal client and configure their program to connect to it. No extra coding required. Frankly, I'm baffled that nobody in the online Go world cares about network lag. Timeseal has been a mature technology on the chess servers for over a decade. Ian ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ -- - Ryan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] time measurement
a slightly simpler protocol: you let me put a machine on your local network that i control, and you agree to do an ntp-like service with it. s. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] time measurement
Here is a simple protocol: email your program to me, and I will test it on my local network :-) All protocols require some trust somewhere, in this case you must trust me to test it fairly and not distribute your program in the case that you want to keep it protected. - Don On Tue, 2009-02-03 at 17:15 -0500, steve uurtamo wrote: a slightly simpler protocol: you let me put a machine on your local network that i control, and you agree to do an ntp-like service with it. s. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] time measurement
It's just a can of worms to require some proprietary binary that people have to use, trust, and believe is unhackable. The SSL connectivity part would be reasonably unhackable. (I.e. if you happened to have a supercomputer to hand to decode the signal you would probably want to use it for your program instead!) Reverse-engineering the binary itself to then make your own client is still a risk, but is a specialist skill beyond most go programmers. And remember, pulling your network cable from the wall is an unstoppable hack. There could be a definition of reasonable net lag (e.g. max of 6 seconds for any one move, and max average of 2 seconds per move across the whole game). Anyone playing with their network cables is then more likely to do more harm than good to their clock. (This also limits the benefit of making your own client binary.) The server could also run traceroute before and during the game to get a fair idea of what is reasonable net lag for that particular client. Darren -- Darren Cook, Software Researcher/Developer http://dcook.org/mlsn/ (English-Japanese-German-Chinese-Arabic open source dictionary/semantic network) http://dcook.org/work/ (About me and my work) http://dcook.org/blogs.html (My blogs and articles) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] time measurement
The server could also run traceroute before and during the game to get a fair idea of what is reasonable net lag for that particular client. Couldn't traceroute also be used with server-side timekeeping? The server could credit the player for trusted hops in the traceroute. Probably only the last hop would be untrusted. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] time measurement
On Feb 3, 2009, at 7:08 PM, Darren Cook dar...@dcook.org wrote: The server could also run traceroute before and during the game to get a fair idea of what is reasonable net lag for that particular client. Couldn't traceroute also be used with server-side timekeeping? The server could credit the player for trusted hops in the traceroute. Probably only the last hop would be untrusted. Yes, though it usually takes 10+ seconds (*) to complete, so not something that can be run every move. Traceroute uses ICMP messages with ever increasing TTL. It is trivial to implement. Sending multiple simultaneous messages or just the important TTL would make it practical. In some areas of the world, the biggest lag is on the client's first hop, so this can't completely solve the problem. Darren *: All waiting, no CPU load: $ time traceroute www.google.com (tells me 56ms, 47ms, 47ms, and 11 hops; peak was 97ms on first try to the 10th hop) real0m9.297s user0m0.000s sys 0m0.004s -- Darren Cook, Software Researcher/Developer http://dcook.org/mlsn/ (English-Japanese-German-Chinese-Arabic open source dictionary/semantic network) http://dcook.org/work/ (About me and my work) http://dcook.org/blogs.html (My blogs and articles) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] How to properly implement RAVE?
Hi Jason, Thanks for your numbers. I might try to limit my bot to 50k playouts and 1 core, but I usually simulate as long as time permits. Do you suspect my pure UCT version has bugs, too, judging from its rating? I find it hard to find good tests for the correctness of a program depending on randomness, and even harder to find bugs. Maybe we can set up our bots to play under similar circumstances on CGOS. Regards, Isaac My bot is about 1/4-1/2 of the speed of yours, but here are my strength numbers (median of reported bayeselo numbers below): HouseBot Rango_004 RAVE - 1778 ELO 1721 ELO UCT- 1587 ELO 1642 ELO Given the tremendous speed difference between our bots, I suspect you may have some debugging to do :( I'll try to put my bot up on CGOS again in the next few days. Maybe some head to head games will best answer how our implementations compare to each other. -- Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] time measurement
Heikki Levanto wrote: No amount on crypto-mumbo-jumbo will solve the problem that the server will have to trust the program, and its author. Signing can provide some little assurance that the program running today is the same as was running yesterday, but that's about all. As long as we can write our own programs, there is no way to stop us from cheating in them, intentionally or by accident. Very true. To the people that point to timeseal on the chess servers: both the binaries and the protocol itself are trivially reverse engineerable. I know of at least 2 people (not counting myself) who have done this. Because the client side is fully under your control, you can cheat all you want with this system. But you can also write a client for a non-supported platform :) The only reason why this doesn't create more problems is that the people who have the ability to do this reverse engineering usually have better things to do with their time than to cheat on chess servers. It's like copy protections: it stops some people, but it sure as hell ain't secure in any meaningful sense. -- GCP ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] time measurement
i like how simple ICMP hacking is. large trunk lines might be the only ones worth trusting as secure, but it's a good start. again, i'd rather move away from absolute time, which i find horrendous. On Tue, Feb 3, 2009 at 4:21 PM, Jason House jason.james.ho...@gmail.com wrote: On Feb 3, 2009, at 7:08 PM, Darren Cook dar...@dcook.org wrote: The server could also run traceroute before and during the game to get a fair idea of what is reasonable net lag for that particular client. Couldn't traceroute also be used with server-side timekeeping? The server could credit the player for trusted hops in the traceroute. Probably only the last hop would be untrusted. Yes, though it usually takes 10+ seconds (*) to complete, so not something that can be run every move. Traceroute uses ICMP messages with ever increasing TTL. It is trivial to implement. Sending multiple simultaneous messages or just the important TTL would make it practical. In some areas of the world, the biggest lag is on the client's first hop, so this can't completely solve the problem. Darren *: All waiting, no CPU load: $ time traceroute www.google.com (tells me 56ms, 47ms, 47ms, and 11 hops; peak was 97ms on first try to the 10th hop) real0m9.297s user0m0.000s sys 0m0.004s -- Darren Cook, Software Researcher/Developer http://dcook.org/mlsn/ (English-Japanese-German-Chinese-Arabic open source dictionary/semantic network) http://dcook.org/work/ (About me and my work) http://dcook.org/blogs.html (My blogs and articles) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ -- - Ryan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] time measurement
The server could also run traceroute before and during the game to get a fair idea of what is reasonable net lag for that particular client. Couldn't traceroute also be used with server-side timekeeping? The server could credit the player for trusted hops in the traceroute. Probably only the last hop would be untrusted. Yes, though it usually takes 10+ seconds (*) to complete, so not something that can be run every move. Darren *: All waiting, no CPU load: $ time traceroute www.google.com (tells me 56ms, 47ms, 47ms, and 11 hops; peak was 97ms on first try to the 10th hop) real0m9.297s user0m0.000s sys 0m0.004s -- Darren Cook, Software Researcher/Developer http://dcook.org/mlsn/ (English-Japanese-German-Chinese-Arabic open source dictionary/semantic network) http://dcook.org/work/ (About me and my work) http://dcook.org/blogs.html (My blogs and articles) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] time measurement
Further information, including a helpful diagram: http://www.edcollins.com/chess/lag.htm Terry McIntyre terrymcint...@yahoo.com -- Libertarians Do It With Consent! - Original Message From: terry mcintyre terrymcint...@yahoo.com To: computer-go computer-go@computer-go.org Sent: Tuesday, February 3, 2009 10:59:12 AM Subject: Re: [computer-go] time measurement This is the timeseal web site: http://www.unix-ag.uni-kl.de/~chess/soft/timeseal/ Looks like an interesting read. Terry McIntyre -- Libertarians Do It With Consent! - Original Message From: Jeff Nowakowski To: computer-go Sent: Tuesday, February 3, 2009 10:34:32 AM Subject: Re: [computer-go] time measurement On Tue, 2009-02-03 at 10:16 -0800, Ian Osgood wrote: Frankly, I'm baffled that nobody in the online Go world cares about network lag. Timeseal has been a mature technology on the chess servers for over a decade. I logged into FICS today for nostalgia and one of the first thing I see is somebody complaining on channel 53 about somebody lag cheating. It's just a can of worms to require some proprietary binary that people have to use, trust, and believe is unhackable. And remember, pulling your network cable from the wall is an unstoppable hack. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
