Quote from: EErik on August 15, 2014, 04:21:47 PM

Quote from: contactlight on August 15, 2014, 02:13:08 PM

He has 1.5GH/s, take a look at the graph again.

i've look at the graph in this moment, but he has the same reward...

Quote from: PatMan on August 15, 2014, 02:13:21 PM

Patience is required with p2pool - I am using less hashrate than you on a couple of different nodes, sometimes I can go without a share for 12 hours or more - then 2 or 3 shares will appear within 5 minutes of each other. Hash rate & diff is going up on every pool - this is the way of things.

Just sit tight - it'll come Wink

Yes but patience apart, I have mined for about 2 weeks and in the last 4-5 days my reward decrease and go to 0.

On http://p2pool.info/ the active user speed is over 1900th/s

He has the same payout because he hasn't found another share, and his share is still on the chain. If he doesn't find another share before that one falls off the chain, his payout will go to zero. With the increasing difficulty, you're going to find fewer shares. The theory is that the pool will find more blocks, meaning the fewer shares you find will be paid more often.

Quote from: PatMan on August 15, 2014, 04:29:35 PM

Quote from: jonnybravo0311 on August 15, 2014, 03:41:16 PM

Quote from: PatMan on August 15, 2014, 02:13:21 PM

Can confirm that using --queue 0 on my S3's results in less DOA also

(also running a local node)

That's interesting data. I'm actually using the default values of 4096 on my local node and get 1-2% DOA. I never really noticed much difference when I set the queue values to 0 or 1 or left it alone at stock.

I believe that using --queue 0 puts more load on the asic cpu, but I'm not sure tbh - it might be the other way round - maybe ck can chime in here. Using a queue setting of zero has generally been regarded as the way to go with p2pool since the early days, although obviously the tech has changed since mining with 5 series GPU's Cheesy

Works good for me though..... Wink

If it works for you, then have at it. Personally, I saw no difference with the different queue settings. To be honest, I have no idea why Bitmain sets the queue value so high, and to understand it would require having their driver code. Bitmain uses an older version of cgminer that they have customized, so expectations of queue settings based upon the latest version of the software may not apply to Bitmain's fork.