Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 533. (Read 2591920 times)

Ideally forrestv should run the node the Jalapeno is mining on to debug it, better synchronize with him or you have high chances are just confirming what others with regular Jalapenos got without any clue on how to help.

I have a 5.6 GH/s jalapeno, but I never tried it with p2pool because I got it after the previous reports of it not working (and so I assumed it wouldn't work).  I am traveling through next Thursday, but when I get back home, I'll try it with p2pool (with the latest versions of both p2pool and bitcoind) for next weekend and see how it does.

Thanks for the update, awesome work! Just wanted to clarify something with what you said above; you said you are seeing no correlation between latency and efficiency with the new versions, but you are working from a very low latency range. Do you have any reason to believe that if latencies on nodes are higher than 0.2s(say between 0.3 and 0.5) that efficiency will still NOT be affected? Just interested to see that you think.

BTW, I've followed your guide regarding latest versions, blockmaxsize/txfees and miner tuning and looks to be helping..thanks for that!

Meaning that there was another user (ckolivas) with a Jalapeno I should have remembered? I suppose I should be ashamed...

So that's make it 3 now (and forrestv doesn't even have the same model you and ckolivas have, just peachy for someone trying to debug a problem).

Instead of trolling around:
What's interesting is that the same (or probably very similar, ckolivas might have tested with an earlier version of cgminer) software using the same driver doesn't exhibit the same behavior at all with different hashrates.
This points to only one of the 2 possible sources of problems with ASICs and p2pool I suspected :
a bug in p2pool when a single miner reaches a hashrate limit between 3.4GH/s and 6+GH/s (2^32 H/s comes to mind...).

anyone tried to run p2pool alongside an electrum server? Is that feasible?

Yes I've already requested a protocol change for p2pool and Jalapenos, but that wasn't the problem.

The problem was p2pool performance ... according to what's written there:
https://bitcointalk.org/index.php?topic=18313.5120

that gyverlb posted twice on that page, once before and once after, the 7 posts on the subject ...

It's nearly confirmed: getblocktemplate latency doesn't influence efficiency with both latest p2pool and bitcoind. I can't even raise it to more than 0.2s now and I don't see any efficiency change between 0.01s and 0.2s.

What's more interesting is the optimal number of connections with other P2Pool node. I had bandwidth problems and lowered them to a total of 6 (3 in and 3 out) to fit both bitcoind and P2Pool's traffic in a ~400kb/s upload limit. My efficiency was between 110 and 115% with these 6 connections.

My BW problems were solved since then and I didn't touch my settings (an average of 112.5% efficiency is not too bad...).
I just tested with a total of 10 connections and my efficiency reached 120%. I'll now focus on testing these settings to make it a bit more clear the kind of compromise done by tweaking them.

I've seen that the 2 most recent P2Pool blocks were less than 200kB and 20kB in size.
There's no good reason to generate short blocks like that when there are plenty transactions to reap fees from anymore.
Please start upgrading to bitcoind-0.8.2 and if you don't have bandwidth limitations that make it impossible to do so for you, raise your maxblocksize and lower you mintxfee and minrelaytxtfee settings (see my guide for values to start from). You and everyone else will earn more BTC this way.

well, about 10-15 nodes dropped offline for me with this latest batch of horse staple battery transactions

Sorry for not posting about it, but I did in fact receive a 3.4GH/s single-core Jalapeno prototype (half the hash rate of a normal Jalapeno). I'm composing a more thorough report right now, but it suffices to say that there were no interesting results. It works with P2Pool about as well as was expected - ~1520% DoA due to ASIC batching latency, but no problems other than that.

EDIT: This was all using cgminer 3.2.0. If anyone who can demonstrate problems with Jalapenos can provide more details about their setup, I can try to replicate it.

I may have missed someone (sorry), but apart from you and maybe forrestv (didn't remember any post where he confirmed testing one on p2pool or even having received it, feel free to point me to it) I don't know of anyone with a Jalapeno in this thread. As you obviously don't use p2pool or tried to help fix any problem with it (given that you don't waste an occasion to troll about how p2pool not being good for Bitcoin) what's your point asking about "drastic performance problems" for hardware nearly nobody owns?

I have more than twice the hashrate of a Jalapeno mining on p2pool (with a single rig about half of its speed) with no problem and I'm far from being the largest miner on it: the problem is either due to a single connection to p2pool reaching a high enough hashrate or some peculiar behavior of the hardware that makes cgminer behave differently with it and trigger a p2pool bug.
Even Avalons are rare enough that finding both an Avalon and a developer interested in helping at the same time is difficult (seems ckolivas made progress in cgminer but couldn't help with the p2pool code). If forrestv doesn't have a working Jalapeno in hand you can stick your head in the sand and wish for support any day...

Yes feel free to stick your head in the sand and dream of unicorns.

Why don't you ask him if he received it and started using it? No need to pollute this thread with this, only people with Jalapenos can help and I don't see any around here.

Not with high hashrate ASICs and stratum.

What you mean? p2pool is working fine. With new bitcoin version (low latencies) everything back to "normal"

So ... there any sign of fixing the p2pool drastic performance problem that was the reason BFL sent forrestv a Jalapeno weeks ago?

Yeah sure:
I also tried custom user override +1 or +10 to force proxy to have 1 or 10 difficulty. Blade just doesn't do a thing, while I was mining nicely with cgminer on same port. That's simple topology of my network and my miners:

Configuration:
laptop - a few FPGA connected with cgminer
blade1 - connected to PC with proxy to bitminter, working nicely all time
blade2 - connected to PC with proxy to bitminter, working nicely all time
PC with proxy (proxy connected to localhost p2pool) - a few FPGA connected with cgminer

Experiments with stratum proxy to p2pool:
laptop with cgminer -> PC = working fine
PC local cgminer -> PC = working fine (local cgminer to local proxy to local p2pool)
blade1 -> PC = nothing
blade2 -> PC = nothing

I was running 2 proxy on PC, port 5000 bitminter, port 5001 p2pool. Blade sits and do nothing while on port 5001, when I pressed Switch Pool, instantly It started working on bitminter proxy.

How to debug this crap, when there is no connection errors or something, at all? 

Right you are sir! And continuing to try and get it lower still...

You have low latency! Very good 

and 0.5% fee

Not trying to steal anybody's thunder or anything but if you are looking for a public P2Pool node in Europe, you could try mine at harvestcoin.com; it's based in Ireland.

Bitcoin mining and stats @ http://mining.harvestcoin.com:9332
Litecoin mining and stats @ http://mining.harvestcoin.com:9327

If you have any questions or comments please don't hesitate to ask.

maqifrnswa, I'm waiting Thank you!