Matt Corallo (OP)
|
|
September 03, 2014, 11:27:16 AM |
|
There were a few major updates and both clients should update...The java client had a rather dumb bug that prevented it from relying outgoing blocks, though it received them fine...the python client was, as is all python, so horrendously non-performant that even a network rtt for a inv->getdata->block process to be faster. With some minor effort the python client now should reliably beat network rtts (seriously python???), though I'd advise using the java client where possible.
|
|
|
|
PatMan
|
|
September 03, 2014, 05:57:46 PM |
|
Damn that java - I just uninstalled it too........
|
|
|
|
Matt Corallo (OP)
|
|
September 03, 2014, 06:02:35 PM |
|
Damn that java - I just uninstalled it too........
Well, if you really wanted the python version you could use Jython, but then you're stuck with java anyway...I may benchmark pypy later and see if it helps but early testing shows its ~as fast.
|
|
|
|
PatMan
|
|
September 03, 2014, 06:06:02 PM |
|
Really? That surprises me, I've never used pypy but have heard it's much faster than std python.......
|
|
|
|
Matt Corallo (OP)
|
|
September 03, 2014, 06:09:48 PM |
|
Really? That surprises me, I've never used pypy but have heard it's much faster than std python.......
Well, its a JIT, and my tests may simply not have been long-running enough to give it sufficient warm-up time.
|
|
|
|
spiccioli
Legendary
Offline
Activity: 1378
Merit: 1003
nec sine labore
|
|
September 03, 2014, 07:51:30 PM |
|
Really? That surprises me, I've never used pypy but have heard it's much faster than std python.......
Well, its a JIT, and my tests may simply not have been long-running enough to give it sufficient warm-up time. Hi, I came to the same conclusions running p2pool long ago on pypy, it is as fast as python. See here, for example.spiccioli
|
|
|
|
-ck
Legendary
Offline
Activity: 4144
Merit: 1637
Ruu \o/
|
|
September 03, 2014, 10:07:28 PM |
|
There were a few major updates and both clients should update...The java client had a rather dumb bug that prevented it from relying outgoing blocks, though it received them fine...the python client was, as is all python, so horrendously non-performant that even a network rtt for a inv->getdata->block process to be faster. With some minor effort the python client now should reliably beat network rtts (seriously python???), though I'd advise using the java client where possible.
Upgraded, thanks. I did notice messages in both directions now instead of before on the java client.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
Matt Corallo (OP)
|
|
September 06, 2014, 06:03:42 AM |
|
There is now a C++ client. Those who had been using the python client should probably switch to it (its semantics are identical, it runs on Linux and under Wine, so I assume Windows) and it is much, much faster than the python client.
|
|
|
|
PatMan
|
|
September 06, 2014, 10:07:21 AM |
|
Great stuff Matt! Testing now.......
|
|
|
|
jedimstr
|
|
September 06, 2014, 03:37:13 PM |
|
There is now a C++ client. Those who had been using the python client should probably switch to it (its semantics are identical, it runs on Linux and under Wine, so I assume Windows) and it is much, much faster than the python client.
Any chance you or someone else could port/compile/brew a Mac C++ version? I tried porting and compiling myself but all the includes FUBAR'd the attempt. Or, I just need more coffee before I try again. Been running the Java client for awhile now, but can we get the jar added to the Git Repository too alongside the other clients? It'll make keeping up-to-date much easier.
|
|
|
|
Matt Corallo (OP)
|
|
September 06, 2014, 08:45:30 PM Last edit: September 06, 2014, 08:58:09 PM by Matt Corallo |
|
Any chance you or someone else could port/compile/brew a Mac C++ version?
I tried porting and compiling myself but all the includes FUBAR'd the attempt. Or, I just need more coffee before I try again.
Hmm, yea, I assume one or more of the socket calls isnt right? I didnt try it on any BSD. Also, it needs C++11, so if the version of clang OSX ships is particularly out-of-date it may fail there too...I'm happy to help test it if you can get me a list of compile errors.
|
|
|
|
Matt Corallo (OP)
|
|
September 06, 2014, 08:59:41 PM |
|
Been running the Java client for awhile now, but can we get the jar added to the Git Repository too alongside the other clients? It'll make keeping up-to-date much easier.
Done.
|
|
|
|
DrHaribo
Legendary
Offline
Activity: 2730
Merit: 1034
Needs more jiggawatts
|
|
September 06, 2014, 09:14:05 PM |
|
Is there a maven repo I need to add to build the java client? It's not finding the required bitcoinj version. Missing: ---------- 1) com.google:bitcoinj:jar:0.12-SNAPSHOT_nodelay
|
|
|
|
Matt Corallo (OP)
|
|
September 06, 2014, 09:31:56 PM |
|
Is there a maven repo I need to add to build the java client? It's not finding the required bitcoinj version. Missing: ---------- 1) com.google:bitcoinj:jar:0.12-SNAPSHOT_nodelay
If you're building the java client direct from source, it wants the branch at https://github.com/TheBlueMatt/bitcoinj/tree/nodelay. The only real difference is it sets TCP_NODELAY.
|
|
|
|
IYFTech
|
|
September 06, 2014, 11:44:37 PM |
|
Hi Matt, Sorry to go a bit off topic, but I was looking at your git repo & noticed you've worked on TextSecure. I've been using it for several weeks now - it's great work! Well done & kudos to you Sorry guys, carry on.......
|
|
|
|
DrHaribo
Legendary
Offline
Activity: 2730
Merit: 1034
Needs more jiggawatts
|
|
September 07, 2014, 07:04:15 PM |
|
Got it. Had to add _nodelay to the version in core/pom.xml so the RelayClient would find it after "mvn install". Strangely the tests for bitcoinj fail if you run them twice without "mvn clean". At least they did for me. But I guess that's a problem with the tests, not the library itself. Perhaps it's an idea for pools to set up direct peering? Could shave off a little time. Is it OK to pass new blocks directly to the RelayNodeClient instead of passing them through the local bitcoind ? Could shave off a little bit more time.
|
|
|
|
Matt Corallo (OP)
|
|
September 08, 2014, 01:16:30 AM |
|
Got it. Had to add _nodelay to the version in core/pom.xml so the RelayClient would find it after "mvn install". Strangely the tests for bitcoinj fail if you run them twice without "mvn clean". At least they did for me. But I guess that's a problem with the tests, not the library itself.
Perhaps it's an idea for pools to set up direct peering? Could shave off a little time.
Is it OK to pass new blocks directly to the RelayNodeClient instead of passing them through the local bitcoind ? Could shave off a little bit more time.
If you used that branch it should already have had _nodelay added to its version number (and you should probably use that branch of your OS may hold onto data before relaying it for some time). re: direct peering: sure, pools could do this (most already do afaiu). Sure, no harm in passing a block out quickly, but this is also why you should treat blocks that come from the relay network identically as some arbitrary blocks you get from an unknown source on the p2p network. See, for example, the for-w branch at https://github.com/TheBlueMatt/RelayNode/tree/for-w/client which I whipped up for another poolop so that they could peer a single relay network client with a ton of local pool daemons and have it properly route blocks that come in from the relay network to their bitcoind and from one of their pool daemons to all the other pool daemons and the relay network all at once.
|
|
|
|
DrHaribo
Legendary
Offline
Activity: 2730
Merit: 1034
Needs more jiggawatts
|
|
September 08, 2014, 09:36:31 PM |
|
If you used that branch it should already have had _nodelay added to its version number (and you should probably use that branch of your OS may hold onto data before relaying it for some time).
Sorry, I forgot to switch to the nodelay branch. re: direct peering: sure, pools could do this (most already do afaiu).
Yeah, but I meant with the relay software, running a RelayNode instead of a RelayClientNode. Not sure how much there is to save there, but there may be something.
|
|
|
|
norgan
|
|
September 13, 2014, 08:28:32 AM |
|
I've downloaded the exe client and am running it with "D:\Temp\relay\relaynetworkclient.exe public.au.relay.mattcorallo.com 127.0.0.1 8333" but I just get the following:
Closing bitcoind socket, failed to connect() (10049: Unknown error) Closing relay socket, failed to connect() (10049: Unknown error) Closing bitcoind socket, failed to connect() (10049: Unknown error) Closing relay socket, failed to connect() (10049: Unknown error) Closing bitcoind socket, failed to connect() (10049: Unknown error) Closing relay socket, failed to connect() (10049: Unknown error) Closing bitcoind socket, failed to connect() (10049: Unknown error) Closing relay socket, failed to connect() (10049: Unknown error) Closing bitcoind socket, failed to connect() (10049: Unknown error) Closing relay socket, failed to connect() (10049: Unknown error) Closing bitcoind socket, failed to connect() (10049: Unknown error) Closing relay socket, failed to connect() (10049: Unknown error) Closing bitcoind socket, failed to connect() (10049: Unknown error)
What am I doing wrong?
|
|
|
|
Matt Corallo (OP)
|
|
September 13, 2014, 08:45:31 PM |
|
I've downloaded the exe client and am running it with "D:\Temp\relay\relaynetworkclient.exe public.au.relay.mattcorallo.com 127.0.0.1 8333" but I just get the following:
Closing bitcoind socket, failed to connect() (10049: Unknown error) Closing relay socket, failed to connect() (10049: Unknown error)
What am I doing wrong?
10049 == WSAEADDRNOTAVAIL according to http://msdn.microsoft.com/en-us/library/windows/desktop/ms740668(v=vs.85).aspx. Any chance you're still on XP or have IPv6 explicitly disabled somewhere, which I think I might have broken in a recent push.
|
|
|
|
|