Namecoin Forum

vinced wrote:

shads wrote:...
My concern is that the merged mining proxy is going to throttle all the advantage that psj has gained. I haven't tried it out but from what I can see from the source it's not designed for highly concurrent throughput...

The proxy is written using the python twisted library which does non-blocking I/O, so it actually is designed for high concurrency.

It would be best if a pool operator tested it under load. It's just a matter of doing a getwork in a loop from multiple processes and seeing how many requests per second the system can do. Compare that with getwork directly against bitcoind/namecoind.

When I get a chance to build the modified daemons I'll give it a go with the stress test client I've been using to benchmark psj.

vinced if the proxy returns true how does pushpool or poolserverj find out which chain it's valid for? Are they expected to internally verify against difficulties for each chain or can they then submit directly to each daemon to get a confirmed result?

shads wrote:I haven't tried but wouldn't joel katz's multithread rpc patch be able to applied to namecoind? When I switched to a patched bitcoind I got performance increase of several thousand %

which multithread patch do you have in mind? I'm patching bitcoind now with some custom patches + merged mining, maybe I missed this one. Can you point me an URL?

EDIT: is it this one? http://luke.dashjr.org/programs/bitcoin ... eb84dd4110

cosurgi wrote:

shads wrote:I haven't tried but wouldn't joel katz's multithread rpc patch be able to applied to namecoind? When I switched to a patched bitcoind I got performance increase of several thousand %

which multithread patch do you have in mind? I'm patching bitcoind now with some custom patches + merged mining, maybe I missed this one. Can you point me an URL?

EDIT: is it this one? http://luke.dashjr.org/programs/bitcoin ... eb84dd4110

This is where I found it.... with some neat instructions: https://bitcointalk.org/index.php?topic ... #msg384157

EDIT: BTW if you are looking to do some stress testing the stress test client here might be useful: http://poolserverj.org/downloads/

shads wrote:vinced if the proxy returns true how does pushpool or poolserverj find out which chain it's valid for? Are they expected to internally verify against difficulties for each chain or can they then submit directly to each daemon to get a confirmed result?

The proxy outputs to stdout a record with a 0 or a 1 for each chain.

Feel free to modify the getwork output if that makes pool integration easier.

It looks like there are no showstoppers being raised, so I would like to propose block 19200 for launch. At the current rate, this will be three weeks to a month from now.

Since it's tested, I don't see any reason to wait until 24000. And a month is enough time for people to change their clients.

Current rate is 10 blocks a day (last 30 blocks). So how about 19000? 25 days.

Post a Linux 64 bit binary & I'll upgrade!

vinced wrote:It looks like there are no showstoppers being raised, so I would like to propose block 19200 for launch. At the current rate, this will be three weeks to a month from now.

cool. Can you make a release? On github I still only see nc0.3.24.55-rc5 as latest.

EDIT: one thing - I think it will become a common mistake for people to send NMC to bitcoin address. I think you should modify the source, so that it rejects tx if the recipent's address does not start with N or M. (same thing should be done in bitcoin clients, because it's certain that someone will try sending his BTC to an NMC address)

I'm on it I'd like to see it ASAP but I'm, fine with 19200.