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
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
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,
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
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
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
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
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
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
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
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
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
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.
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
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
- 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
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
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
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
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,
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
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
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
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
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
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
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
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:
28 matches
Mail list logo
