Namecoin Forum

What type of column is the timestamp in your database? I thought I'd tested with bigints, datetimes and timestamps (in which case you shouldn't need the unix_timestamp part). INSERT INTO shares (rem_host, username, our_result, upstream_result, reason, solution, timestamp) VALUES (?, ?, ?, ?, ?, ?, ?...

Actually I just realised you are running pushpool and psj at the same time and just switching clients betweent then... that would probably rule out what I said or pushpool would be slowing down as well... My new theory... if the pool is only occasionally utilised and you've got a large cache size se...

It's memory usage will probably be higher but it shouldn't be any more of a load on cpu or disk than pushpool... My testing has shown it performs quite a bit faster in most scenarios and most of those tests were very heavily loaded. Admittedly I was quite liberal with the amount of memory available ...

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, may...

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?

... 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-blocki...

doublec wrote:

shads wrote: Unless they are using a multithreaded namecoind though they are hitting a bottleneck there.

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 %

BTW if I'm wrong about that and it's not a bottleneck that's great... But if it is I'm not taking a shot at the proxy, It probably does what it does very well, but it would benefit from being embedded into an architecture that was designed for high concurrency, high throughput scenarios.

I agree re: high availability though I do have to contend the point that no pushpoold like implementation is multithreaded... poolserverj runs every major task group in separate thread pools... I'm curious what has changed to make you think it's no longer a potential bottleneck? Do you mean it's not...

It's still not the bottleneck. The bottleneck is threading. No implementation uses more than one core. No implementation of what? There's already scalability issues for btc pools and from what I can see from the the merged mining proxy code (I don't know python so apologies if I'm wrong) it's not r...