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

Payment shows up on my wallet UI, no problem.

I see the block in my log file, but not in the UI.  I agree this is odd.

2014-11-17 05:07:35.767992 GOT BLOCK FROM PEER! Passing to bitcoind! 7b853c9b bitcoin: https://blockchain.info/block/00000000000000001747b51ad4fc5590668ac17752bf6aa14cac12637b853c9b

The latest block that paid out 330410 isn't showing on my node's list.  Usually this type of thing is due to a block that was orphaned in p2pool but valid on the Bitcoin network.

The difference for this one is that Coincadence (http://minefast.coincadence.com/p2pool-stats.php) usually shows when this happens on the right most column, but for 330410, it's listed as valid(green checkmark). I double checked other people's nodes and none of them show this block.  

So not to look a gift horse in the mouth but... Anyone have any ideas why this one wouldn't show? Is it actually orphaned on p2pool's network even though Coincadence shows it's not?

Yeah it has stabilized quite a bit now with >98% efficiency.

My bad 

i'm the cautious type. as a rule i've never bought batch 1 of any miner. I lost out bigtime because of this with the kfc jupiter as, when I came around to buying batch 2, they were sold out and i never did get a jup but I think i've probably saved myself from more headaches by being cautious this way. then again, it's not a foolproof way of deciding what to buy. I paid for b3 h*shf*st, but that's been my only real loss.

I have to say though, bitmain rigs, for me have been slightly hit and miss, not on the hardware side but on the pool side, they don't seem to be very good with DGM pools, which is my preferred method of mining, and for variance, I also mine p2pool, and also support for p2pool has come late from bitmain.

here's what I get mining DGM with bitmain miners... If i switch all my S3 over to the pool at once, it just falls over with 100% rejects. I have to ramp in one miner at a time and wait until it's stable and showing full hashrate at pool before I can ramp in the next. I also find that if I point too many (6 or more separate miners), the whole lot will begin to give lots of rejects (over 1/3rd).

Now, I know this is most likely caused due to pool stability + hardware compatibility with DGM but I have no problems with other h/w brands.

i mine on mmpool DGM pool (*reminisces of bitparking days!*) and i've never been able to point my full 20TH/s all at once, as the bitmaintech just falls over - funnily enough, never any rejects from my sp-tech rigs. I know that Meni R had input into the design of SP-t manufacturing, so perhaps Bitmain could consult with him for future equipment, to ensure their h/w is good on DGM pools?

just a thought.

I still have a few S3's running myself, but got rid of my S2's to subsidise the SP20 purchases. I felt very let down by Bitmains lack of support for the S2 owners - not only because they left it so late to honour their promise of p2pool compatible firmware, but also the about-turn of the upgrade option, the S4 coupon was a bit of a slap in the face too. (I couldn't even give that away!)

The BTC price hike was perfect timing too, I ended up paying less than BTC2 per unit shipped - so I'm a happy chappy    Just gotta wait for them now......

i should have also said, i'm happy with my S3's and had pondered using their PSU for the SP20 and selling them on.. in the end I just bought a new PSU, so i'll keep the S3's running, they are like the baby pet of the family and the spondoolies gear; the top dog! 

Jealous of you both.  I've got 9 S3s running here and haven't been able to justify replacing them with SP20s.  I WANT to do it because I love the SP-Tech gear, from the build quality of the units to the stability and rock-solid performance.  But the S3s have already paid for themselves and are mining pure profit at this point.  Makes it hard to pull the trigger.

i've never had any problems with any of the SP-Tech rigs, they mine on ANY mining method with 0 rejected shares and perform particularly well with p2pool and DGM. I alternate my hash between p2pool and DGM, for variance.
Can't wait for my SP20 to arrive next week

I don't think they've fully grasped the whole p2pool idea from what I've read so far from Bitmain - but I'm sure it'll all come out when they upload it to git - if they ever do. It will either make them or break them I think.

Oh, bought the SP20's by the way.....nice 

I've read through the tidbits Bitmain has provided in their announcement.  I just don't see it.  What they've done:

• Kept it in Python - guess it was easier than re-writing in C
• Provided a vardiff - um... that was done a long time ago
• Somehow solved the frequent restarts - yeah... sure.  That's code magic I'd like to see.
• Addressing the "small miner variance" - I posited on how they accomplished that in the announcement thread

yeah very interesting!

Bitmain announce their new p2pool software......check it out:

https://bitcointalk.org/index.php?topic=855548.new#new

He runs one of the relay nodes

Maybe this will help https://bitcointalksearch.org/topic/how-and-why-pools-and-all-miners-should-use-the-relay-network-766190

Remember that variance is high on p2pool especially when considering a tiny 600GHs

Pool share required is ~18 million, so:
600GHs average expected time to find a share with 600GHs at the moment is ~36hours.
If you don't find a share, you wont get anything.

800% variance on that (which is rare but not unheard of) means 286 hours ...

If it was mining effectively (and you received a payout) chances are you are both just in a streak of bad luck, ~600 GH/s is close to the minimum threshold to expect a payout in every block.

Do you show active shares in the share chain?

Since you both have the same gear, if you guys trust each other it might be worthwhile to both mine to the same address (or set up a multisig) so that overall you are closer to 1.2 TH/s and will have a better shot of keeping a share on the chain, then splitting the payout at some interval....

Supplying the node address would be helpful in troubleshooting...

Need some help,  

A friend  and I are mining on two different systems.  I have an S3+ and S1 on p2pool - decentralized mining using Windows 7.  My friend is also mining an S3+ and S1  mining on Linux.  

So here is both our problems. After we start bitcoin-qt / core and it is updated. We then both start our p2pool programs and for 5 days we both are mining along getting shares any where from .0039 to .01xxx.  but after 5 days we see .0000 btc and both of us try to reboot But on the restarts after 2 days we are still setting at .0000 btc, with stale rate and efficiency showing .   Is there a setting that we are missing to avoid p2pool to fail in collecting payouts for us, but continues to mine for shares?

Ah yep, I was looking at the times jonnybravo0311 used.
Since you got yours from your p2pool log, yep they'd be accurate (and more accurate than me)
I do (usually and currently) have p2pool running so I could have checked that log also

Nope, the p2pool hash rate is what it is
In the arena of what the rate is, but not very accurate.

You can see this by grepping for "Pool:.*Stale" in the logfile.

Here over the last few minutes:
2014-11-09 01:36:02.720179  Pool: 4604TH/s Stale rate: 14.9% Expected time to block: 10.3 hours
2014-11-09 01:36:05.726034  Pool: 4587TH/s Stale rate: 15.5% Expected time to block: 10.3 hours
2014-11-09 01:36:17.739654  Pool: 4464TH/s Stale rate: 14.9% Expected time to block: 10.6 hours
2014-11-09 01:36:20.744880  Pool: 4412TH/s Stale rate: 14.9% Expected time to block: 10.7 hours
2014-11-09 01:36:35.758069  Pool: 4412TH/s Stale rate: 14.9% Expected time to block: 10.7 hours
2014-11-09 01:36:50.773637  Pool: 4412TH/s Stale rate: 14.9% Expected time to block: 10.7 hours
2014-11-09 01:37:05.789544  Pool: 4412TH/s Stale rate: 14.9% Expected time to block: 10.7 hours
2014-11-09 01:37:11.870958  Pool: 4521TH/s Stale rate: 14.9% Expected time to block: 10.4 hours

It seems to think it varied by 5%