Dann Corbit wrote:But I am with you -- a simple swap using a temp would have been more clear and therefore better. It's not like we will produce wrong timing results if we lose 10 cycles.
On a modern processor the xor trick might even be slower than using a temporary variable. From wikipedia:
On modern CPU architectures, the XOR technique can be slower than using a temporary variable to do swapping. One reason is that modern CPUs strive to execute instructions in parallel via instruction pipelines. In the XOR technique, the inputs to each operation depend on the results of the previous operation, so they must be executed in strictly sequential order, negating any benefits of instruction-level parallelism.
Bob was kind enough to send me timeseal and timestamp for Mac OS and Linux, but when I tried to use the linux files this morning I realized the pi needs armv6 binaries.
So I compiled this version, and it works fine
Only other gotcha was I had to use port 23 for freechess.org not port 5000.
It's played a couple of test games as guest, I've now requested a computer account.
Both xboard and icsdrone work ok.
It manages about 150knps vs 2500knps on my macbook, not bad for a $5 device!!
I take it you compiled a version of openseal for arm6? Timeseal source code is not available. From what I have been told on FICS by moomutz, there could be some rare cases with buggines with using openseal client on the timeseal server. He said it was something regarding getting your latency time being confused with your game elapsed clock time under certain situations (It was a few months ago when I spoke to him about it when I was trying to setup an ics style server on the raspberry pi 2 and had a few questions). But still, just so you are aware. It's not like you have many other options.
JoshPettus wrote:I take it you compiled a version of openseal for arm6? Timeseal source code is not available. From what I have been told on FICS by moomutz, there could be some rare cases with buggines with using openseal client on the timeseal server. He said it was something regarding getting your latency time being confused with your game elapsed clock time under certain situations (It was a few months ago when I spoke to him about it when I was trying to setup an ics style server on the raspberry pi 2 and had a few questions). But still, just so you are aware. It's not like you have many other options.
Yes I did
Maybe Bob can send me an arm6 version..
If there are bad bugs, I can just not use it - it's not as if I'll be going for ratings records, it's more the fun in using something so small and cheap as the pi for the engine to sit and play on.
As it is, I'm, waiting for the computer account. Not looking good though - I resent my mail from a few days ago, just in case.
I have been using openseal successfully for years at FICS. The only time I have had an issue with it was when I built an x86 version. Heh.
There are known bugs with the actual timeseal program anyway. Someone associated with xboard, I had thought HGM, was working to get a non-buggy version out. I don't know if that ever came to pass or not.
For some reason, timeseal source had always been treated like some national secret. The result being that it has been a royal pain to get timeseal binaries for different platforms. That changed when openseal came about and I've been happy with it as I said, for years.
I know at least one person who has the real timeseal source, but I don't want to burden him by naming him. If I felt a need to produce binaries for different platforms, I might try. Fact is, there isn't a need because openseal works.
Openseal does lack the -p option, binding itself to a port, though. That option is interesting, allowing you to use timeseal on a different machine if you desire. I explored this once as a way to use real timeseal by invoking the -p option on an x86 box on the lan and calling it from the box running the engine. I never got satisfactory results, but maybe it works better now with faster networking hardware. Worth a shot maybe.
Thanks Eric, I really wonderd. I was just reporting what MooMutz told me. Thing is, I have seen various versions of the openseal source code floating around (particularly with the decoder). So it could be some version causing the issues
These are the latest versions I found and I bundled it together with a bunch of client binaries I compiled. (Openseal needs a unix like system, so for windows I had to compile it around cygwin)
bnemias wrote:I have been using openseal successfully for years at FICS. The only time I have had an issue with it was when I built an x86 version. Heh.
There are known bugs with the actual timeseal program anyway. Someone associated with xboard, I had thought HGM, was working to get a non-buggy version out. I don't know if that ever came to pass or not.
For some reason, timeseal source had always been treated like some national secret. The result being that it has been a royal pain to get timeseal binaries for different platforms. That changed when openseal came about and I've been happy with it as I said, for years.
I know at least one person who has the real timeseal source, but I don't want to burden him by naming him. If I felt a need to produce binaries for different platforms, I might try. Fact is, there isn't a need because openseal works.
Openseal does lack the -p option, binding itself to a port, though. That option is interesting, allowing you to use timeseal on a different machine if you desire. I explored this once as a way to use real timeseal by invoking the -p option on an x86 box on the lan and calling it from the box running the engine. I never got satisfactory results, but maybe it works better now with faster networking hardware. Worth a shot maybe.
Much better approach, assuming xboard/winboard, is to run xboard + timeseal on one machine, have xboard start the engine on another machine. I run like this all the time when I am using the 20 core box that doesn't run X at all...
