Ok, so maybe I'm not understanding correctly what the different config options are and what they mean to my situation. In my mind I was concerned with tuning the miners according to a method of minimizing stales and rejects as I assume lower means better average hashrate and work done on the chain. I'm less concerned with how my graphs look. I am more concerned with maximizing the good work done and getting the most out of the miners (as I'm sure most are).
Right now, I've got 20+ Antminer S1's (which is where I set the address+128 pseudo diff), and 2 Cointerra IV's, default configs. Will be adding more S1's and a good bunch of S3's in the coming weeks. Call it around a total of 7TH/s average for now, to grow soon. All of them are set with the same miner address so to the node it appears as one large miner. I'm mining on coincadence, and I seem to be averaging a share every 1h15m at the moment.
One question is should I split up my types of miners into "sub-pools", organizing by type of miner as well as aggregate mining speed? From what I'm reading there seems to be per-miner best configs, and then per-node settings so that those with a higher overall hashrate can "play nicer" with the rest of the miners on the node. I could end up splitting into groups of roughly ~3Th/s each, putting me at the top end of the average hashrate on the node, but not making it so overly out of whack. And I'm assuming this would also apply whether I'm mining on another node, or if I create my own. If I bring up my own node I would be better off still trying to keep hashrates similar so that the pool work / share difficulty is roughly even?
Are the "+" and the "/" mutually exclusive settings, i.e. you can have one or the other so you're optimizing for the miner or the node, but not both?
I hope I'm not beating a dead horse with these questions, but unfortunately I've not been able to find one set of clear info anywhere which gives kind of a guide on how to properly configure your miners to get the most out of P2Pool - reading through almost 500 pages of this thread is likely to not happen, so if there's a good breakdown of this earlier, point me to a page and I'll happily go read.
Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 323. (Read 2591971 times)
August 03, 2014, 11:01:35 AM
August 02, 2014, 06:49:45 PM
Well, this is news to me (p2pool setting the pseudo share value itself). All previous talk about this, including everything I've seen outside this thread, has suggested manually setting pseudo shares. I always thought the auto detect feature (-1) wasn't a part of Stratum. For whatever reason, this doesn't appear to be working right with the Ant S3, or user kgb2mining wouldn't gain anything from setting pseudo shares manually.
August 02, 2014, 05:01:52 PM
No
Using the + indicator doesn't alter the way p2pool software runs, it doesn't tell it anything. + supplies information to the miner software (cgminer/bfg), that runs on the miner or whatever separate device you have controlling the ASIC boards. It tells the miner: do not send shares of difficulty lower than +n to the pool node. So: no extra shares are sent to the pool, it's the opposite.
Because + setting affects the mining software, it should be tuned for the hashrate of the individual mining device. So, for a standard Ant S3, somewhere between +256 and +512 will likely give the best results (rule of thumb is to use +1 for every 1 GH/s). + indicator must be set to get best performance for a given hashrate, otherwise the pool software becomes saturated with difficulty 1-2 shares that are not accepted on any pool these days (p2pool least of all...)
Are you stating that if you do not set the pseudo-share difficulty by using ADDRESS+n, then your miner will flood the p2pool node on which you're hashing with difficulty 1 shares? If that's the case, then why does the p2pool software even care about the "+"? In other words why would code exist in p2pool to handle you setting the pseudo-share difficulty at all if, as you state, it has no effect on the way the software runs?Using the + indicator doesn't alter the way p2pool software runs, it doesn't tell it anything. + supplies information to the miner software (cgminer/bfg), that runs on the miner or whatever separate device you have controlling the ASIC boards. It tells the miner: do not send shares of difficulty lower than +n to the pool node. So: no extra shares are sent to the pool, it's the opposite.
Because + setting affects the mining software, it should be tuned for the hashrate of the individual mining device. So, for a standard Ant S3, somewhere between +256 and +512 will likely give the best results (rule of thumb is to use +1 for every 1 GH/s). + indicator must be set to get best performance for a given hashrate, otherwise the pool software becomes saturated with difficulty 1-2 shares that are not accepted on any pool these days (p2pool least of all...)
From work.py:
Code:
self.pseudoshare_received = variable.Event()
Code:
desired_pseudoshare_target = None
desired_share_target = None
for symbol, parameter in zip(contents2[::2], contents2[1::2]):
if symbol == '+':
try:
desired_pseudoshare_target = bitcoin_data.difficulty_to_target(float(parameter))
except:
if p2pool.DEBUG:
log.err()
elif symbol == '/':
try:
desired_share_target = bitcoin_data.difficulty_to_target(float(parameter))
except:
if p2pool.DEBUG:
log.err()
desired_share_target = None
for symbol, parameter in zip(contents2[::2], contents2[1::2]):
if symbol == '+':
try:
desired_pseudoshare_target = bitcoin_data.difficulty_to_target(float(parameter))
except:
if p2pool.DEBUG:
log.err()
elif symbol == '/':
try:
desired_share_target = bitcoin_data.difficulty_to_target(float(parameter))
except:
if p2pool.DEBUG:
log.err()
Code:
if desired_pseudoshare_target is None:
target = 2**256-1
local_hash_rate = self._estimate_local_hash_rate()
if local_hash_rate is not None:
target = min(target,
bitcoin_data.average_attempts_to_target(local_hash_rate * 1)) # limit to 1 share response every second by modulating pseudoshare difficulty
else:
target = desired_pseudoshare_target
target = max(target, share_info['bits'].target)
for aux_work, index, hashes in mm_later:
target = max(target, aux_work['target'])
target = math.clip(target, self.node.net.PARENT.SANE_TARGET_RANGE)
Up to this point, I have been under the impression that p2pool dynamically tells the mining software to use the difficulty it assigns, or if the miner sets its own static pseudo-share difficulty, to use that one instead. I can see this happening in the logs, as well as in the UIs of my miners.target = 2**256-1
local_hash_rate = self._estimate_local_hash_rate()
if local_hash_rate is not None:
target = min(target,
bitcoin_data.average_attempts_to_target(local_hash_rate * 1)) # limit to 1 share response every second by modulating pseudoshare difficulty
else:
target = desired_pseudoshare_target
target = max(target, share_info['bits'].target)
for aux_work, index, hashes in mm_later:
target = max(target, aux_work['target'])
target = math.clip(target, self.node.net.PARENT.SANE_TARGET_RANGE)
Let me give another example. If I set the pseudo-share difficulty to ADDRESS+1, I can see my graphs become very smooth. If I set the pseudo-share difficulty to ADDRESS+1000, the graphs become very spiked. If I do not set it at all, the graphs are somewhere in the middle. If your assertion that setting of the value has no bearing on p2pool were true, then not setting it, and setting it to ADDRESS+1 should have the same effect: a very smooth looking graph.
So, to conclude, if you do not set the pseudo-share difficulty, one is assigned to you based upon the hashing power on the node by the p2pool software. If you do set it, then your miners submit shares at or above the value you set. If you set this value to something extremely low, then you are indeed flooding the p2pool node with shares that are completely worthless, but your graphs will look nice. Hence, you are using more bandwidth, and the node is processing a bunch of useless work.
August 02, 2014, 02:37:34 PM
You seeing 10 shares in 9 hours is nothing more than luck - not because you set the difficulty level.
Yes
Setting +128 sets your pseudo-share difficulty. All it does is tell the p2pool node to accept shares from your miner of 128 difficulty or higher. The effect is to make the graph prettier at the cost of increased bandwidth and processing done by the node to handle the extra shares your miners are sending.
No
Using the + indicator doesn't alter the way p2pool software runs, it doesn't tell it anything. + supplies information to the miner software (cgminer/bfg), that runs on the miner or whatever separate device you have controlling the ASIC boards. It tells the miner: do not send shares of difficulty lower than +n to the pool node. So: no extra shares are sent to the pool, it's the opposite.
Because + setting affects the mining software, it should be tuned for the hashrate of the individual mining device. So, for a standard Ant S3, somewhere between +256 and +512 will likely give the best results (rule of thumb is to use +1 for every 1 GH/s). + indicator must be set to get best performance for a given hashrate, otherwise the pool software becomes saturated with difficulty 1-2 shares that are not accepted on any pool these days (p2pool least of all...)
Setting actual share difficulty is done by /128. Unless you set this to some value higher than the share difficulty, it makes no difference to p2pool since you need to find a share of about 4.5M to even get on the chain. The only time you'd want to set this value is if you've got a much higher hash rate than average on the node.
Yes. Remember that unlike +, / indicator is information for the pool software. So whatever you set should be in relation to your total hashrate on your p2pool node, whereas + should be set to suit the hashrate of each individual mining unit. The rule of thumb is to set this to target an average of one share per hour, IIRC
Setting / is only a good idea for those with bigger overall hashrates. The advantage is that you forego the chance to get a smaller diff share accepted on the chain to concentrate on bigger diff shares (shares are weighted according to difficulty, i.e. 1 high diff share has higher payout than 1 share that only just passes the share difficulty).
August 02, 2014, 11:39:37 AM
I'm starting to play around with the static difficulty setting on my S1's (I'm mining at coincadence ATM). Through yesterday I had left it at the default, which according to the monitoring was "1,000".
Last night I changed it to static difficulty of 128 (BTCaddress+128 in the miner config).
Before the change I had 4 shares over the span of 6 hours. After the change I have had 10 shares in the past 9 hours, and my BTC earnings per block went up by .02BTC. Now, I've not had a share in 2 hours at the moment, so we'll see what happens through today.
In addition, I am noticing that my Rej% is down an average of 2% from about 7% to about 5%, and the Stale% is now flat 0 across all of them, where it was on average about .2-.5%. This to me is a good sign I think.
From what I understand bandwith and latency to the local node does help with a lower diff setting, because you're getting and submitting shares more frequently. If I'm correct in thinking that, then it makes sense. We're physically close to coincadence so my latencies are low, and we have ample bandwith to allow for lots of traffic at the lower diff setting.
I may take some of the group and set it to 256 diff and see if any of the numbers change for the S1's. We just ordered a bunch of S3's from batch 5, so I will probably try a 512 diff to start with when those come in next week and see what happens.
Setting +128 sets your pseudo-share difficulty. All it does is tell the p2pool node to accept shares from your miner of 128 difficulty or higher. The effect is to make the graph prettier at the cost of increased bandwidth and processing done by the node to handle the extra shares your miners are sending.Last night I changed it to static difficulty of 128 (BTCaddress+128 in the miner config).
Before the change I had 4 shares over the span of 6 hours. After the change I have had 10 shares in the past 9 hours, and my BTC earnings per block went up by .02BTC. Now, I've not had a share in 2 hours at the moment, so we'll see what happens through today.
In addition, I am noticing that my Rej% is down an average of 2% from about 7% to about 5%, and the Stale% is now flat 0 across all of them, where it was on average about .2-.5%. This to me is a good sign I think.
From what I understand bandwith and latency to the local node does help with a lower diff setting, because you're getting and submitting shares more frequently. If I'm correct in thinking that, then it makes sense. We're physically close to coincadence so my latencies are low, and we have ample bandwith to allow for lots of traffic at the lower diff setting.
I may take some of the group and set it to 256 diff and see if any of the numbers change for the S1's. We just ordered a bunch of S3's from batch 5, so I will probably try a 512 diff to start with when those come in next week and see what happens.
Setting actual share difficulty is done by /128. Unless you set this to some value higher than the share difficulty, it makes no difference to p2pool since you need to find a share of about 4.5M to even get on the chain. The only time you'd want to set this value is if you've got a much higher hash rate than average on the node.
You seeing 10 shares in 9 hours is nothing more than luck - not because you set the difficulty level.
August 02, 2014, 11:38:23 AM
I would think that latency and bandwidith would go up with the local node as you are now submitting shares every time you solve 128 instead of 1000, thus increasing both the load and bandwidth to process the increased number of shares coming into the local node.
In theory, yes this could affect a node with insufficient resources to handle the additional traffic and processing. Given the node I'm connected to, it shouldn't have enough of an affect to be detrimental since we're not talking about hundreds of miners, only 20 or so. Over the next couple weeks we'll be building our own local node which should make the resource questions moot, even for a few hundred miners at low diff. At least, I think so... 
Now we're up to 4 hours without a share, so maybe it'll turn out that manually setting the diff really won't have much of an effect in the long run.
August 02, 2014, 10:51:45 AM
I'm starting to play around with the static difficulty setting on my S1's (I'm mining at coincadence ATM). Through yesterday I had left it at the default, which according to the monitoring was "1,000".
Last night I changed it to static difficulty of 128 (BTCaddress+128 in the miner config).
Before the change I had 4 shares over the span of 6 hours. After the change I have had 10 shares in the past 9 hours, and my BTC earnings per block went up by .02BTC. Now, I've not had a share in 2 hours at the moment, so we'll see what happens through today.
In addition, I am noticing that my Rej% is down an average of 2% from about 7% to about 5%, and the Stale% is now flat 0 across all of them, where it was on average about .2-.5%. This to me is a good sign I think.
From what I understand bandwith and latency to the local node does help with a lower diff setting, because you're getting and submitting shares more frequently. If I'm correct in thinking that, then it makes sense. We're physically close to coincadence so my latencies are low, and we have ample bandwith to allow for lots of traffic at the lower diff setting.
I may take some of the group and set it to 256 diff and see if any of the numbers change for the S1's. We just ordered a bunch of S3's from batch 5, so I will probably try a 512 diff to start with when those come in next week and see what happens.
Last night I changed it to static difficulty of 128 (BTCaddress+128 in the miner config).
Before the change I had 4 shares over the span of 6 hours. After the change I have had 10 shares in the past 9 hours, and my BTC earnings per block went up by .02BTC. Now, I've not had a share in 2 hours at the moment, so we'll see what happens through today.
In addition, I am noticing that my Rej% is down an average of 2% from about 7% to about 5%, and the Stale% is now flat 0 across all of them, where it was on average about .2-.5%. This to me is a good sign I think.
From what I understand bandwith and latency to the local node does help with a lower diff setting, because you're getting and submitting shares more frequently. If I'm correct in thinking that, then it makes sense. We're physically close to coincadence so my latencies are low, and we have ample bandwith to allow for lots of traffic at the lower diff setting.
I may take some of the group and set it to 256 diff and see if any of the numbers change for the S1's. We just ordered a bunch of S3's from batch 5, so I will probably try a 512 diff to start with when those come in next week and see what happens.
I would think that latency and bandwidith would go up with the local node as you are now submitting shares every time you solve 128 instead of 1000, thus increasing both the load and bandwidth to process the increased number of shares coming into the local node.
August 02, 2014, 09:39:25 AM
I'm starting to play around with the static difficulty setting on my S1's (I'm mining at coincadence ATM). Through yesterday I had left it at the default, which according to the monitoring was "1,000".
Last night I changed it to static difficulty of 128 (BTCaddress+128 in the miner config).
Before the change I had 4 shares over the span of 6 hours. After the change I have had 10 shares in the past 9 hours, and my BTC earnings per block went up by .02BTC. Now, I've not had a share in 2 hours at the moment, so we'll see what happens through today.
In addition, I am noticing that my Rej% is down an average of 2% from about 7% to about 5%, and the Stale% is now flat 0 across all of them, where it was on average about .2-.5%. This to me is a good sign I think.
From what I understand bandwith and latency to the local node does help with a lower diff setting, because you're getting and submitting shares more frequently. If I'm correct in thinking that, then it makes sense. We're physically close to coincadence so my latencies are low, and we have ample bandwith to allow for lots of traffic at the lower diff setting.
I may take some of the group and set it to 256 diff and see if any of the numbers change for the S1's. We just ordered a bunch of S3's from batch 5, so I will probably try a 512 diff to start with when those come in next week and see what happens.
Last night I changed it to static difficulty of 128 (BTCaddress+128 in the miner config).
Before the change I had 4 shares over the span of 6 hours. After the change I have had 10 shares in the past 9 hours, and my BTC earnings per block went up by .02BTC. Now, I've not had a share in 2 hours at the moment, so we'll see what happens through today.
In addition, I am noticing that my Rej% is down an average of 2% from about 7% to about 5%, and the Stale% is now flat 0 across all of them, where it was on average about .2-.5%. This to me is a good sign I think.
From what I understand bandwith and latency to the local node does help with a lower diff setting, because you're getting and submitting shares more frequently. If I'm correct in thinking that, then it makes sense. We're physically close to coincadence so my latencies are low, and we have ample bandwith to allow for lots of traffic at the lower diff setting.
I may take some of the group and set it to 256 diff and see if any of the numbers change for the S1's. We just ordered a bunch of S3's from batch 5, so I will probably try a 512 diff to start with when those come in next week and see what happens.
August 02, 2014, 09:22:34 AM
I have not yet, but I'll give it a try. I don't think it ever made a difference on my s1 with manual diff on P2Pool. I'm going with everything default so far on P2Pool with the S3's. Pretty sure there was good bit of discussion about this many pages back. Maybe it's different on the S3, but I doubt it.
Has anybody used BITMAINs guildlines for P2P by setting a static difficulty? I tried 256 and my BestShare went just over 1K, at 512 it stays at 0 after an hour. Without the static difficulty they go well over 3M for BestShares and get over 10K within minutes. Maybe I should ask does the BestShare value really mean anything with this current firmware version? On regular pools I never had a BestShare, it wasn't until I went to P2P that BestShare gave me a value. My hash rate did go up a little higher as the guidance said it would though. Education on BestShare please.
https://bitcointalksearch.org/topic/m.7598229
https://bitcointalksearch.org/topic/m.7598229
There was some talk on the other thread https://bitcointalksearch.org/topic/m.8139727 that I replied on about the queue which I did see a few pages back here addressed too but must have missed the difficulty post. windpath is conducting some testing with the queue. I am now following the guidance from the Norgz P2P site for the difficulty setting to see if that makes any difference. So far the BestShare value has come back but do not know if that matters. I think the S3 is working fine on P2P but I am sure if we were not trying different settings we would not be happy.
I would imagine best share would be the same as best share in cgminer or bfgminer, the highest difficulty share found. Right now at a 1.4 PH pool rate its currently 4.9M to get a share so you would need to see 4.9M or higher to have earned a share on p2pool.
August 01, 2014, 09:39:25 PM
I have not yet, but I'll give it a try. I don't think it ever made a difference on my s1 with manual diff on P2Pool. I'm going with everything default so far on P2Pool with the S3's. Pretty sure there was good bit of discussion about this many pages back. Maybe it's different on the S3, but I doubt it.
Has anybody used BITMAINs guildlines for P2P by setting a static difficulty? I tried 256 and my BestShare went just over 1K, at 512 it stays at 0 after an hour. Without the static difficulty they go well over 3M for BestShares and get over 10K within minutes. Maybe I should ask does the BestShare value really mean anything with this current firmware version? On regular pools I never had a BestShare, it wasn't until I went to P2P that BestShare gave me a value. My hash rate did go up a little higher as the guidance said it would though. Education on BestShare please.
https://bitcointalksearch.org/topic/m.7598229
https://bitcointalksearch.org/topic/m.7598229
There was some talk on the other thread https://bitcointalksearch.org/topic/m.8139727 that I replied on about the queue which I did see a few pages back here addressed too but must have missed the difficulty post. windpath is conducting some testing with the queue. I am now following the guidance from the Norgz P2P site for the difficulty setting to see if that makes any difference. So far the BestShare value has come back but do not know if that matters. I think the S3 is working fine on P2P but I am sure if we were not trying different settings we would not be happy.
August 01, 2014, 09:16:04 PM
I have not yet, but I'll give it a try. I don't think it ever made a difference on my s1 with manual diff on P2Pool. I'm going with everything default so far on P2Pool with the S3's. Pretty sure there was good bit of discussion about this many pages back. Maybe it's different on the S3, but I doubt it.
Has anybody used BITMAINs guildlines for P2P by setting a static difficulty? I tried 256 and my BestShare went just over 1K, at 512 it stays at 0 after an hour. Without the static difficulty they go well over 3M for BestShares and get over 10K within minutes. Maybe I should ask does the BestShare value really mean anything with this current firmware version? On regular pools I never had a BestShare, it wasn't until I went to P2P that BestShare gave me a value. My hash rate did go up a little higher as the guidance said it would though. Education on BestShare please.
https://bitcointalksearch.org/topic/m.7598229
https://bitcointalksearch.org/topic/m.7598229
August 01, 2014, 07:14:22 PM
Has anybody used BITMAINs guildlines for P2P by setting a static difficulty? I tried 256 and my BestShare went just over 1K, at 512 it stays at 0 after an hour. Without the static difficulty they go well over 3M for BestShares and get over 10K within minutes. Maybe I should ask does the BestShare value really mean anything with this current firmware version? On regular pools I never had a BestShare, it wasn't until I went to P2P that BestShare gave me a value. My hash rate did go up a little higher as the guidance said it would though. Education on BestShare please.
https://bitcointalksearch.org/topic/m.7598229
https://bitcointalksearch.org/topic/m.7598229
August 01, 2014, 06:22:59 PM
Anybody notice a drop in shares?
With no changes in setup or machines....
My shares stopped late last night...
So today, I rebooted my computer and reset the system and started everything fresh even the bitcore....
Now running 4 hours at 4 TH and 0.0 shares...
Thats very unusual as I usually get about 2 an hour on average...
Just wondering if its only me?
Thanks
That's variance for you. Now... that's some pretty crappy luck, but, it happens. Sometimes when that happens to me, I give my miners a little pep talk. Positive words of encouragement like, "I'm going to trade you in" and "Do you want to end up on eBay, too?". Then, a lot of times if that doesn't do the trick, I'll threaten them with unplugging them and not plugging them back in or forcing them to work on the same block over and over until they get it right. In extreme cases I'll reboot everything repeatedly, just so they know who is in control.With no changes in setup or machines....
My shares stopped late last night...
So today, I rebooted my computer and reset the system and started everything fresh even the bitcore....
Now running 4 hours at 4 TH and 0.0 shares...
Thats very unusual as I usually get about 2 an hour on average...
Just wondering if its only me?
Thanks
August 01, 2014, 06:20:58 PM
How to find a p2pool public node with low ping
I found that I could get a good DOA (dead on arrival) rate, by finding a node with a good ping.
Several nodes close to me with low DOA rate by sorting by lowest ping.
Here is a list of public nodes
http://p2pool-nodes.info/
Using this windows tool here: http://www.nirsoft.net/utils/multiple_ping_tool.html (direct download: http://www.nirsoft.net/utils/pinginfoview.zip),
you can quickly and effectively ping a large number of these and sort by lowest ping.
Note: a low ping doesn't necessarily mean low DOA rate, but you are more likely to find it this way.
Here is a list of the nodes as of July that you can paste into pingInfoView (needs to be refreshed with current list)
https://docs.google.com/spreadsheets/d/19V7inJuM96FV9kIRG9Kwxhz321xYJn8AZ1hWgJEhwo4/edit?usp=sharing
Thats all folks
I found that I could get a good DOA (dead on arrival) rate, by finding a node with a good ping.
Several nodes close to me with low DOA rate by sorting by lowest ping.
Here is a list of public nodes
http://p2pool-nodes.info/
Using this windows tool here: http://www.nirsoft.net/utils/multiple_ping_tool.html (direct download: http://www.nirsoft.net/utils/pinginfoview.zip),
you can quickly and effectively ping a large number of these and sort by lowest ping.
Note: a low ping doesn't necessarily mean low DOA rate, but you are more likely to find it this way.
Here is a list of the nodes as of July that you can paste into pingInfoView (needs to be refreshed with current list)
https://docs.google.com/spreadsheets/d/19V7inJuM96FV9kIRG9Kwxhz321xYJn8AZ1hWgJEhwo4/edit?usp=sharing
Thats all folks
August 01, 2014, 05:38:31 PM
Hey all,
Wondering....
Has everyone seen a huge, more then 50 % loss of income here in the last month?
I know as the hash rate has been going up, the shares are more difficult
and the block payouts are lower... And I understand that we should see an
increase in the blocks to almost balance it out.
But this is not the way it has been working out for me at least?
Actually getting a bit nervous at the low payouts?
Thanks for any input.... I know I cant bee the only one.
According to my calculations, my expected earnings for the time period of 6/29 - 7/28 was about 1.9837BTCWondering....
Has everyone seen a huge, more then 50 % loss of income here in the last month?
I know as the hash rate has been going up, the shares are more difficult
and the block payouts are lower... And I understand that we should see an
increase in the blocks to almost balance it out.
But this is not the way it has been working out for me at least?
Actually getting a bit nervous at the low payouts?
Thanks for any input.... I know I cant bee the only one.
My actual earnings in that same time period: 2.3968BTC
So, no, I'm not seeing a 50% reduction in income.
just curious...is there a website or calculation tool that helps you project your income?
Using any bitcoin calculater, like coinwarz or the one at bitcoinwisdom, and plugging in your hashrate is how you project your income. Outside of that it's just variance/luck that effects your income.
August 01, 2014, 01:57:24 PM
Hey all,
Wondering....
Has everyone seen a huge, more then 50 % loss of income here in the last month?
I know as the hash rate has been going up, the shares are more difficult
and the block payouts are lower... And I understand that we should see an
increase in the blocks to almost balance it out.
But this is not the way it has been working out for me at least?
Actually getting a bit nervous at the low payouts?
Thanks for any input.... I know I cant bee the only one.
According to my calculations, my expected earnings for the time period of 6/29 - 7/28 was about 1.9837BTCWondering....
Has everyone seen a huge, more then 50 % loss of income here in the last month?
I know as the hash rate has been going up, the shares are more difficult
and the block payouts are lower... And I understand that we should see an
increase in the blocks to almost balance it out.
But this is not the way it has been working out for me at least?
Actually getting a bit nervous at the low payouts?
Thanks for any input.... I know I cant bee the only one.
My actual earnings in that same time period: 2.3968BTC
So, no, I'm not seeing a 50% reduction in income.
just curious...is there a website or calculation tool that helps you project your income?
August 01, 2014, 11:46:00 AM
Very excited...
Thanks Jonny! Your contribution to the graphing capabilities is much appreciated as well!
Thank you psahx!
Running your own node is the way p2pool was intended to be used, looking forward to getting the open source dashboard up as well, thanks
Thanks kgb, the future looks bright!
I'll take a look at swapping the tabs on the miner dashboard for active miners on a node to have "Recent Miner Shares" be the default tab....
---------------------
All of your feedback and help has been instrumental in getting things to where they are now, looking forward to us all growing p2pool in the future, now I better get back to work
Hey windpath, congrats on the acquisition!!! You've done a great job so far and have been a highly valued contributor to the p2pool experience for miners. I know when I'm not mining on my own node, I'm on yours. I'm glad I was able to contribute to what is, at least in my view, the best p2pool experience going. I wish you all the best, and look forward to your upcoming release.
Thanks Jonny! Your contribution to the graphing capabilities is much appreciated as well!
Keep up the good work, body!!!
Your contribution is very healthy for p2pool.
Thank you!
Your contribution is very healthy for p2pool.
Thank you!
Thank you psahx!
Definitely excited, and looking forward to the November 1st open source dashboard to add to my p2pool node.
Have to run my own node due to latency, but does help keep bitcoin/p2pool global.
Have to run my own node due to latency, but does help keep bitcoin/p2pool global.
Running your own node is the way p2pool was intended to be used, looking forward to getting the open source dashboard up as well, thanks
Cool, congrats windpath! It's always good news when someone who is genuinely interested in doing something has the means and is able to get it done. Looking forward to seeing how this develops and where we go from here.
Thanks kgb, the future looks bright!
I'll take a look at swapping the tabs on the miner dashboard for active miners on a node to have "Recent Miner Shares" be the default tab....
---------------------
All of your feedback and help has been instrumental in getting things to where they are now, looking forward to us all growing p2pool in the future, now I better get back to work
August 01, 2014, 07:48:17 AM
Windpath - one suggestion if I may for your interface? On the miner's page, could you change the default bottom statistic to be the Recent Shares instead of the Recent Blocks? I find myself wanting to know that information and clicking on it much more frequently than the blocks, since that is also the default on the other dashboard pages.
Not sure if that's even possible depending on how the underlying code generates the pages to begin with, but worth a shot.
Not sure if that's even possible depending on how the underlying code generates the pages to begin with, but worth a shot.
August 01, 2014, 07:42:15 AM
Cool, congrats windpath! It's always good news when someone who is genuinely interested in doing something has the means and is able to get it done. Looking forward to seeing how this develops and where we go from here.
August 01, 2014, 02:25:12 AM
Well folks, it's official!
I hope you are all as excited about this as I am
● By November 1st: Open source version of the data-rich Coin Cadence p2pool dashboard released including real time data from p2pool and the Bitcoin blockchain and an API that provides historical data.
-------------------
Definitely excited, and looking forward to the November 1st open source dashboard to add to my p2pool node.
Have to run my own node due to latency, but does help keep bitcoin/p2pool global.
Jump to: