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

In my log file I'll occasionally get something like this:

log:2013-10-26 08:42:53.003554 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!
log:2013-10-26 08:42:53.015818 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!
log:2013-10-26 08:42:53.029308 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!
log:2013-10-26 08:42:53.038270 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!
log:2013-10-26 08:42:53.293668 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!
log:2013-10-26 08:42:53.307047 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!
log:2013-10-26 08:42:53.321228 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!
log:2013-10-26 08:42:53.355749 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!
log:2013-10-26 08:42:53.587437 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!
log:2013-10-26 08:42:53.603913 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!

p2pool has been up for 12 days.  

I'm positive that it's just happening for one person & doesn't occur all that often

right now, it's at:

log:2013-10-26 08:58:10.006940 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!
log:2013-10-26 08:58:10.017284 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!
log:2013-10-26 08:58:10.028608 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!

log:2013-10-26 08:59:11.588038 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!
log:2013-10-26 08:59:11.601600 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!

log:2013-10-26 09:00:12.743830 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!

with no other errors in the past 5 minutes or so (during that time the miner I'm referring to had a hashrate swing of about 15ghash/s right when it started & then gradually increasing back to the norm).  The messages lasted from about 08:42:30 'til that last one at 09:00.

I'm guessing this is something related to the equipment being used to mine and not something locally on my p2pool?

Anyone else seen this?  Any setting or something I can change locally to make it not happen or happen less frequently?... or is it something that is totally out of my control?

That's the problem with a 'small' (yes anything under 100Gh/s is now small) hashrate compared to both your chosen pool and the total network rate.

The only way to have kept the amount more-or-less constant would have been to outgrow the %age changes and added 200 times your hashing power this year !

Thanks for all the responses. It's good to get feed back.

My miner setup was working perfect before the difficulty rose to 268 m. I was running my own p2pool client, efficiently was near perfect, stall rate was virtually zero, DOA was zero. I was able to find a share in nearly every block and got paid out nearly every time. I think I missed two payouts in about twenty, but I hadn't found a share so I knew that was correct too.

As soon as the difficulty rose to 268 m without anything changing at my side (after three months working perfectly) I stopped receiving payouts. After a week I ended up with one pay out of a very low amount as previously wrote in a previous post, but p2pool has paid out about 17 times. I had noticed that I couldn't get a successful share before the pool solved a block and when I did manage to get two , one was orphaned. That's when I got my only payout in a week.

Summery....

After a week of running at 268 m I have to say p2pool did not work for my 10 gh processing.

It had worked perfectly below 268m difficulty, my payouts were nearly ever time and perfect amounts as I calculated from inputting numbers into online calculators.

The problem seems to me that my 10 gh can't get a share fast enough for the network, but although I was informed when I did get a share I would get my fair share I clearly didn't.

Also I have to add, at the same time I had another 10 gh in another pool, not p2pool, and this paid what I would have expected, over the same time period.

I end by saying I believe in the p2pool idea, and I thank the coders, but I also believe as the difficulty rises more low hashing users may have to leave p2pool network due to the issues I have mentioned.

You may have something wrong with your miner setup, or with the pool you're using - how many p2pool 'shares' did you submit ?

There is some element of 'randomness' - but a week of 15Gh/s has found 17 P2Pool-type 'shares' and apart from the 2 days when that miner had found no p2pool-shares, I've been paid on every block found.

it isn't giving you your fair share if you are mining at something like p2pool.org

Sure, but personally I'm a fan of P2Pool's instant payouts when a block is solved AND a low variance.

That's why I wrote a proposal that would allow any P2Pool node to honor the work of either only the miners that find shares (as usual) or also the work of all miners that submit (low-diff) shares. https://github.com/forrestv/p2pool/issues/135

This approach would lower the variance at well attended nodes a lot and therefore might encourage many low-level hashrate miners to use P2Pool again.
Feel free to attach comments, improvements or even qualms.

The design of p2pool actually makes it impossible for you to get less than your fair share, over an infinite timeframe.  Your variance will grow as your hashrate shrinks in relation to the rest of the pool, but the sum will always work out.

Do you have any node info - hash rate, stale rate, DOA, efficiency?

UPDATE

After around 1 week of solid processing at 10 gh/s via p2pool network I received 0.00337845 BTC; after missing 16 block payouts in a row.

I'm sorry to say this can't be giving me my fair share for my work done on the p2pool network so I have moved off it.

So 10-15% loss anyway :/

No.  480-510GH/s.

130MH is pointless with current difficulty.   All you're doing is making heat and noise, and sucking power.

With 130MH you'd be better off mining one of the altcoins like Litecoin, or PPCoin.

You must be pushin much more hash.  At 130mh, I ran for 5 days and saw nothing.   I couldn't even get on the board due to no share.
I didn't change any settings from before, I have all updated soft....

My GPUs are still running strong.  They find a share every few days and earn a little dust.

Wholy cowpie batman, I stop mining 6 months ago, and come back and find that I can't even make it on the board.  
(dual gpu @ 130mh)

Oh well, now I just start my miners and use them as a heater when I need heat in my room.


Looks like the bitcoin network is going to get much smaller over time, as more and more hashers can't make the board.
This is a VERY BAD THING.  
This means that the security of the network is reduced, and is susceptible to shutdown using legal pressure on the few miners that are left.
Bitcoins strength was that it has so many hashers, the idea that any government could take down the hashers was impossible.
The death of fiat using the method of death by 1,000,000 cuts, now seems like its not going to happen.
As ROI disappears, only hashers left will be behemoths.
This implys that the entire network should implement a NODE policy (rewards for just running a hasher of any rate)
Even max rewards no matter who runs bigger hash.
(this would create hashers that just want the fame of being a large hasher(bragging rights) AND keep all the little nodes running.
Similar to how torrents work.  They work not because a single user is pushing gigabits, but because all users are pushing megabits(times 1,000)
If a ratio policy was implemented into torrents, the idea would have already failed(like the old days of ftps)

The value isn't in the nodes hash rate, but the fact that they are yet another node doing the relay race.
Rewards for running any hasher should have been implemented into the design to encourage everyone to stay in.

I don't really know, but I DO know that the number of participating hashers(regardless of hash rate) makes it safer for everyone.
Really, who cares who hashes more, if they are a single point of failure, it completely throws the model out the window.
Bitcoin2.0 needs to start now before the entire network hashes its self out of existence.

I understand that the bitcoin generated isn't worth the POWER the gpus use, but what if someone wants to generate SOMETHING?
(even very small returns?)

  If you can't generate a single share, you can't get on the list, so....
in the words of willy... http://www.youtube.com/watch?v=M5QGkOGZubQ

Is it also run 440GH/s on "normal" pools? Looks like flushwork takes like 1 sec

What a headache. First the servers crashed, then the miners crashed, then the power went out. But finally, finally got my servers up and running - YAY. Now I just need to get the rest of the miners up and functional.

My public p2pool node: http://mining.all-aboutbitcoins.com:9332/

Here is Jupiter with .97.  Compare to here https://bitcointalksearch.org/topic/m.3307821

Yeah, after a few hours of letting it run, I'd agree that it's not flawless - but it is way, way better than it was.

I wouldn't say flawlessly...but it does look much better.  I'll run 24 hrs and post results.