bryonp
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 85
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 24, 2014, 05:30:14 PM |
|
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?
|
|
|
|
jonnybravo0311
Legendary
Offline
Activity: 1344
Merit: 1024
Mine at Jonny's Pool
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 24, 2014, 06:41:07 PM |
|
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.phpNot 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.
|
Jonny's Pool - Mine with us and help us grow! Support a pool that supports Bitcoin, not a hardware manufacturer's pockets! No SPV cheats. No empty blocks.
|
|
|
zvs
Legendary
Offline
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 24, 2014, 10:53:11 PM |
|
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
Legendary
Offline
Activity: 1540
Merit: 1001
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 24, 2014, 11:15:17 PM |
|
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
|
I mine at Kano's Pool because it pays the best and is completely transparent! Come join me!
|
|
|
SpAcEDeViL
Legendary
Offline
Activity: 986
Merit: 1027
Miner-Control.de Pooler
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 25, 2014, 04:01:00 PM |
|
Hy, i have run a p2pool on http://miner-control.deI 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
Legendary
Offline
Activity: 1258
Merit: 1027
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 25, 2014, 04:20:03 PM |
|
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
Legendary
Offline
Activity: 986
Merit: 1027
Miner-Control.de Pooler
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 25, 2014, 04:31:20 PM |
|
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 ![Wink](https://bitcointalk.org/Smileys/default/wink.gif)
|
|
|
|
windpath
Legendary
Offline
Activity: 1258
Merit: 1027
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 25, 2014, 05:19:36 PM |
|
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 ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) With the front end your using its in the right column under "Share Difficulty"
|
|
|
|
jonnybravo0311
Legendary
Offline
Activity: 1344
Merit: 1024
Mine at Jonny's Pool
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 26, 2014, 03:56:02 AM |
|
S3s on p2pool... flashed the new firmware this morning and edited the cgminer script to set: --queue 0 --expiry 1 --scan-time 1 First S3 hashing happily away at 440: ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2F1msiNmI.png&t=665&c=FBouIg7rnoPSzA) Second S3 hashing away at 427 (this one absolutely refuses to even hash at stock clocks without a smattering of "x" and "-": ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2FaXCrYU2.png&t=665&c=gRAuHNsGIAiZ8Q) Check out those hardware error rates... it's practically non-existent.
|
Jonny's Pool - Mine with us and help us grow! Support a pool that supports Bitcoin, not a hardware manufacturer's pockets! No SPV cheats. No empty blocks.
|
|
|
rav3n_pl
Legendary
Offline
Activity: 1361
Merit: 1003
Don`t panic! Organize!
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 26, 2014, 09:27:18 AM |
|
S3s on p2pool... flashed the new firmware this morning and edited the cgminer script to set: --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
Legendary
Offline
Activity: 1344
Merit: 1024
Mine at Jonny's Pool
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 26, 2014, 02:37:38 PM |
|
S3s on p2pool... flashed the new firmware this morning and edited the cgminer script to set: --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.
|
Jonny's Pool - Mine with us and help us grow! Support a pool that supports Bitcoin, not a hardware manufacturer's pockets! No SPV cheats. No empty blocks.
|
|
|
-ck
Legendary
Offline
Activity: 4214
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 26, 2014, 02:39:26 PM |
|
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.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
jonnybravo0311
Legendary
Offline
Activity: 1344
Merit: 1024
Mine at Jonny's Pool
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 26, 2014, 02:43:10 PM Last edit: July 26, 2014, 02:56:12 PM by 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.
|
Jonny's Pool - Mine with us and help us grow! Support a pool that supports Bitcoin, not a hardware manufacturer's pockets! No SPV cheats. No empty blocks.
|
|
|
-ck
Legendary
Offline
Activity: 4214
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 26, 2014, 02:56:32 PM |
|
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.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
jonnybravo0311
Legendary
Offline
Activity: 1344
Merit: 1024
Mine at Jonny's Pool
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 26, 2014, 03:12:56 PM |
|
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.
|
Jonny's Pool - Mine with us and help us grow! Support a pool that supports Bitcoin, not a hardware manufacturer's pockets! No SPV cheats. No empty blocks.
|
|
|
-ck
Legendary
Offline
Activity: 4214
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 26, 2014, 03:14:43 PM |
|
Yes, that's the summary.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
mdude77
Legendary
Offline
Activity: 1540
Merit: 1001
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 26, 2014, 03:18:43 PM |
|
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
|
I mine at Kano's Pool because it pays the best and is completely transparent! Come join me!
|
|
|
zvs
Legendary
Offline
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 27, 2014, 12:01:54 AM |
|
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
Legendary
Offline
Activity: 4214
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 27, 2014, 12:11:33 AM Last edit: July 27, 2014, 01:15:37 AM by ckolivas |
|
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.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
mdude77
Legendary
Offline
Activity: 1540
Merit: 1001
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 27, 2014, 12:46:21 AM |
|
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
|
I mine at Kano's Pool because it pays the best and is completely transparent! Come join me!
|
|
|
|