[1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool

[bryonp]

Hey guys.... Curious,
As I am sure we are all seeing,
the hash rate keeps going up and down like a yo-yo.

My question, does this effect our block chances?

Is it bad , good , or indifferent?

[1713998352]

1713998352

[1713998352]

1713998352

[1713998352]

1713998352

[jonnybravo0311]

Hey guys.... Curious,
As I am sure we are all seeing,
the hash rate keeps going up and down like a yo-yo.

My question, does this effect our block chances?

Is it bad , good , or indifferent?

As the hash rate goes up, the expected time to block goes down.  As the hash rate goes down, the expected time to block goes up.  The chances of finding a block remains a constant - every hash has a chance to find one.

Edit: If you find your miner in the active miners tab at the link below you can see your estimated effective hash rate which will help you to get an idea of your luck compared with your actual hash rate:

http://minefast.coincadence.com/p2pool-stats.php

Not sure I get this part. Let's say p2pool doesn't find a block for 7 straight days (I hope I wont jinx it). My estimated effective hashrate goes very very down and I will get my share of the 25 BTC when a block is found based on the tiny effective hashrate right?

Windpath's calculation of effective hash rate is based upon the number of shares on the chain that are yours.  So, assuming you are finding an average number of shares, your effective hash rate would remain pretty constant, and close to your actual value.  When that block is found, you receive the reward based upon the number of shares you've got on the chain.  The block pays the previous 8640 shares (approximately 3 days worth).  So, if a block is found in 7 days, or in 7 seconds, your payout is determined by how many of the 8640 shares are yours.

[zvs]

Higher p2pool hash rate will decrease variance for larger miners since they'll always have shares & blocks will come more often.  It'll increase variance for small miners, I really have no clue what that is nowadays, maybe 100ghash?... because sometimes you will have no shares, even if blocks are being found.

I always liked to gamble though, anyway.

[mdude77]

Hey guys.... Curious,
As I am sure we are all seeing,
the hash rate keeps going up and down like a yo-yo.

My question, does this effect our block chances?

Is it bad , good , or indifferent?

I don't think the hash rate is varying *that* much.

There's no way, to my knowledge, that p2pool can know what the true hashrate is.  It has to guess.  It guesses by how quickly shares of a given size are being submitted.  Since that's going to vary by luck, the hashrate going to look like a yo-yo on speed.

M

[SpAcEDeViL]

Hy,

i have run a p2pool on http://miner-control.de

I have test it and make with round about 500 GHs few "node" Shares over 340k
Best Share was 1.55M in my cgminer.

But no Share was counted, what is wrong here? Can anybody Helps?

http://miner-control.de/bitcoin_p2pool/

[windpath]

Hy,

i have run a p2pool on http://miner-control.de

I have test it and make with round about 500 GHs few "node" Shares over 340k
Best Share was 1.55M in my cgminer.

But no Share was counted, what is wrong here? Can anybody Helps?

http://miner-control.de/bitcoin_p2pool/

Minimum share difficulty for the pool is currently ~4MM, you did not have any valid shares yet...

Expected time to share should be somewhere around 12 hours at 500GH/s

[SpAcEDeViL]

Thx.

Where can i see, or show on the page, what the miner needed for a Pool Share. So i can reject the question before they come

[windpath]

Thx.

Where can i see, or show on the page, what the miner needed for a Pool Share. So i can reject the question before they come

With the front end your using its in the right column under "Share Difficulty"

[jonnybravo0311]

S3s on p2pool... flashed the new firmware this morning and edited the cgminer script to set:

Code:

--queue 0 --expiry 1 --scan-time 1

First S3 hashing happily away at 440:


Second S3 hashing away at 427 (this one absolutely refuses to even hash at stock clocks without a smattering of "x" and "-":


Check out those hardware error rates... it's practically non-existent.

[rav3n_pl]

S3s on p2pool... flashed the new firmware this morning and edited the cgminer script to set:

Code:

--queue 0 --expiry 1 --scan-time 1

It is REALLY BAD because you are forcing miner to drop work after 1 sec and get new one.
queue=0 is good idea, but scantime should be at least 10s (P2pool share is every 30s) and expiry to max 30 (but expiry means to drop work in queue).

[jonnybravo0311]

S3s on p2pool... flashed the new firmware this morning and edited the cgminer script to set:

Code:

--queue 0 --expiry 1 --scan-time 1

It is REALLY BAD because you are forcing miner to drop work after 1 sec and get new one.
queue=0 is good idea, but scantime should be at least 10s (P2pool share is every 30s) and expiry to max 30 (but expiry means to drop work in queue).

That's an interesting point, and I probably should have considered the ramifications of setting it so low before just believing what I read as a recommendation.  I'm actually tearing down my S3s today, cleaning them completely of the messy thermal compound Bitmain used and putting AS5 on the chips.  I'll restart them with the updated scan time value of 10.

Thanks for the help.

[-ck]

Don't adjust scan or expiry, they're unhelpful. Don't drop queue lower than 1 on hardware that fast as it can impair its performance.

[jonnybravo0311]

Don't adjust scan or expiry, they're unhelpful. Don't drop queue lower than 1 on hardware that fast as it can impair its performance.

If you don't explicitly set scan/expiry parameters, what do they default to in cgminer?

EDIT: there are recommendations all over the board (bother literally and figuratively) regarding the best and/or most valuable tweaks to make.  Since you wrote the mining software, and I presume are at least conversationally familiar with Bitmain's hardware, what values would you recommend for the S3?  Should we leave it alone at Bitmain's setting of 4096?  Also, is Bitmain really using version 3.1.2 of cgminer, or have they number versions their own way because they've customized the software?  If yes, do you know the version of cgminer on which they based the one in the S3?

Thanks again!

EDIT2: Rather than just a straight up recommendation, is there some kind of formula to calculate the "best" setting for queue depth with a given hash rate and/or mining hardware?

EDIT3: Sorry!  I'm full of questions this morning... would setting the queue depth values be dependent on not only hash rate, but also the pool itself?  For example, would a miner on p2pool wish to have a value of X with hardware Y, but a miner on BTCGuild would want a value of Z for that same hardware Y.

[-ck]

I don't know what they did in their driver that needs such a large queue. I'd recommend a queue of 1 for every piece of hardware, always, on p2pool, unless there is some unique issue with the device that really needs it larger. S3 might fall into that category. Scan and expiry do nothing useful on today's hardware, today's stratum mining or with p2pool. All recommendations you may read are misguided. Bitmain really is using an older cgminer; they just kept working with the codebase they forked when they first created their own cgminer driver fork for S1.

EDIT: Virtually all manipulations of queue are also misguided, even if for other pools; the default is best there.

[jonnybravo0311]

I don't know what they did in their driver that needs such a large queue. I'd recommend a queue of 1 for every piece of hardware, always, on p2pool, unless there is some unique issue with the device that really needs it larger. S3 might fall into that category. Scan and expiry do nothing useful on today's hardware, today's stratum mining or with p2pool. All recommendations you may read are misguided. Bitmain really is using an older cgminer; they just kept working with the codebase they forked when they first created their own cgminer driver fork for S1.

EDIT: Virtually all manipulations of queue are also misguided, even if for other pools; the default is best there.

Thanks for your help.  If I understand you correctly, the following are your recommendations:

• For p2pool, queue depth of 1.
• Certain hardware that uses their own customized fork of cgminer may have different queue depth requirements due to driver implementation
• Scan time and expiry settings are pointless on modern mining hardware

Your guidance is much appreciated.

[-ck]

Yes, that's the summary.

[mdude77]

I don't know what they did in their driver that needs such a large queue. I'd recommend a queue of 1 for every piece of hardware, always, on p2pool, unless there is some unique issue with the device that really needs it larger. S3 might fall into that category. Scan and expiry do nothing useful on today's hardware, today's stratum mining or with p2pool. All recommendations you may read are misguided. Bitmain really is using an older cgminer; they just kept working with the codebase they forked when they first created their own cgminer driver fork for S1.

EDIT: Virtually all manipulations of queue are also misguided, even if for other pools; the default is best there.

Thanks for your help.  If I understand you correctly, the following are your recommendations:

• For p2pool, queue depth of 1.
• Certain hardware that uses their own customized fork of cgminer may have different queue depth requirements due to driver implementation
• Scan time and expiry settings are pointless on modern mining hardware

Your guidance is much appreciated.

Note that you can set most of these temporarily via API through SSH.  That'll allow you to test the changes before you make them permanent.

M

[zvs]

I don't know what they did in their driver that needs such a large queue. I'd recommend a queue of 1 for every piece of hardware, always, on p2pool, unless there is some unique issue with the device that really needs it larger. S3 might fall into that category. Scan and expiry do nothing useful on today's hardware, today's stratum mining or with p2pool. All recommendations you may read are misguided. Bitmain really is using an older cgminer; they just kept working with the codebase they forked when they first created their own cgminer driver fork for S1.

EDIT: Virtually all manipulations of queue are also misguided, even if for other pools; the default is best there.

Thanks for your help.  If I understand you correctly, the following are your recommendations:

• For p2pool, queue depth of 1.
• Certain hardware that uses their own customized fork of cgminer may have different queue depth requirements due to driver implementation
• Scan time and expiry settings are pointless on modern mining hardware

Your guidance is much appreciated.

They're pointless, but if you set expiry to 1 you may have some issues.

Was scan-time set to 1 and expiry set to 1 *ever* good?  I just did a quick google search and it looks like a lot of these GPU miner guides actually recommend that crap.  I always used a scan time of 30, expiry of 60 and queue of 1.  Was I wrong that whole time?  haha

[-ck]

They're pointless, but if you set expiry to 1 you may have some issues.

Was scan-time set to 1 and expiry set to 1 *ever* good?  I just did a quick google search and it looks like a lot of these GPU miner guides actually recommend that crap.  I always used a scan time of 30, expiry of 60 and queue of 1.  Was I wrong that whole time?  haha

Adjustment of scan time is from the CPU mining days. Adjustment of expiry time is from the pre-longpoll mining days (i.e. first getwork servers long before stratum). So neither of them have been helpful for over 2 years, not even for GPU mining. Most attempts at modifying them since then have been based on misinformation and mining solo to random altcoins.

[mdude77]

Was scan-time set to 1 and expiry set to 1 *ever* good?  I just did a quick google search and it looks like a lot of these GPU miner guides actually recommend that crap.  I always used a scan time of 30, expiry of 60 and queue of 1.  Was I wrong that whole time?  haha

I can't see how it could be.

M