Bitcoin Forum
December 11, 2016, 02:06:48 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 [493] 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 ... 744 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2035753 times)
Duce
Full Member
***
Offline Offline

Activity: 155


View Profile
August 02, 2014, 02:39:25 AM
 #9841

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://bitcointalk.org/index.php?topic=671189.msg7598229#msg7598229

There was some talk on the other thread https://bitcointalk.org/index.php?topic=671189.msg8139727#msg8139727 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.
1481465208
Hero Member
*
Offline Offline

Posts: 1481465208

View Profile Personal Message (Offline)

Ignore
1481465208
Reply with quote  #2

1481465208
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481465208
Hero Member
*
Offline Offline

Posts: 1481465208

View Profile Personal Message (Offline)

Ignore
1481465208
Reply with quote  #2

1481465208
Report to moderator
1481465208
Hero Member
*
Offline Offline

Posts: 1481465208

View Profile Personal Message (Offline)

Ignore
1481465208
Reply with quote  #2

1481465208
Report to moderator
sconklin321
Member
**
Offline Offline

Activity: 109


View Profile
August 02, 2014, 02:22:34 PM
 #9842

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://bitcointalk.org/index.php?topic=671189.msg7598229#msg7598229

There was some talk on the other thread https://bitcointalk.org/index.php?topic=671189.msg8139727#msg8139727 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.
kgb2mining
Member
**
Offline Offline

Activity: 112


View Profile
August 02, 2014, 02:39:25 PM
 #9843

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.

sconklin321
Member
**
Offline Offline

Activity: 109


View Profile
August 02, 2014, 03:51:45 PM
 #9844

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.



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.
kgb2mining
Member
**
Offline Offline

Activity: 112


View Profile
August 02, 2014, 04:38:23 PM
 #9845

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... Smiley

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.
jonnybravo0311
Legendary
*
Offline Offline

Activity: 1008


Mine at Jonny's Pool


View Profile WWW
August 02, 2014, 04:39:37 PM
 #9846

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.
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.

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.
Carlton Banks
Legendary
*
Offline Offline

Activity: 1470



View Profile
August 02, 2014, 07:37:34 PM
 #9847

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).


Vires in numeris
jonnybravo0311
Legendary
*
Offline Offline

Activity: 1008


Mine at Jonny's Pool


View Profile WWW
August 02, 2014, 10:01:52 PM
 #9848

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?

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()
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.

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.

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.
Carlton Banks
Legendary
*
Offline Offline

Activity: 1470



View Profile
August 02, 2014, 11:49:45 PM
 #9849

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.


Vires in numeris
kgb2mining
Member
**
Offline Offline

Activity: 112


View Profile
August 03, 2014, 04:01:35 PM
 #9850

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.
jonnybravo0311
Legendary
*
Offline Offline

Activity: 1008


Mine at Jonny's Pool


View Profile WWW
August 03, 2014, 05:02:47 PM
 #9851

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.

You're not beating a dead horse at all, and your questions are good ones.

First, the "+" and "/" are not mutually exclusive.  You can set your mining address to "ADDRESS/256+256" and both the pseudo-share and actual share difficulty would be set accordingly.

As to whether or not you should set values... that's debatable.  If you do not set anything, the node will make the determination for you based upon the node's entire hash rate.  There are patches out there to address this, but the node operator would have to install the proper fork of the p2pool code.  These patches will dynamically determine the proper difficulty setting based upon the address, rather than the node's hash rate.  On windpath's node, if you don't set it, you'll get the highest value set for you: 1000 (he'd probably actually see 999.99 in the logs, but whatever...).

Bitmain has come out and stated that S3 owners who mine on p2pool should set the difficulty levels manually.  They have suggested using "ADDRESS/256+256".  I've tried it and have found absolutely no difference in performance.  My error rates, WU, accepted vs rejected have all remained consistent whether or not I set it.  I have noticed no difference in hashing speed, either.

Could there be an effect of setting these values?  Possibly.  I just don't know enough of Bitmain's driver code to understand where the advantage would be in forcing static difficulty settings vs dynamic ones.  Hence, even though I personally have seen no difference, I have set my S3s to Bitmain's recommendations.  One thing I have noticed, however, is that by doing so, my "Best Share" value is now ALWAYS "0".  Not that the value has any meaning other than to see just how close you came to solving a block.

If I remember correctly - and Carlton Banks stated this as well in his post - your target should be around a share an hour.  Since you're pretty much there now, I don't see a need for you to set your share difficulty (by using "/") to a value higher than the ~4.5M already required to put a share on the chain.  However, if you do add enough hardware to make it so you find shares considerably faster than that, you might want to set it at that point.  Right now, to find a share an hour (using 4.5M as the share difficulty), we can figure it out using the following:
Code:
Difficulty * 2**32 / hash rate = number of seconds to find a share
4500000 * 2**32 / R = 3600
R = 5368709120000
So, 5.37TH/s is the hash rate you'd need to find a share an hour at 4.5M difficulty.  Obviously that rate changes as the difficulty level does.  Just like I did with the previous formula, you can determine what your difficulty *should* be set to if you know your hash rate to keep that share finding time at 1 hour.  You could then use that to set your difficulty via the "/".  For example, let's assume I've got 10TH/s:
Code:
D * 2**32 / 10000000000000 = 3600
D = 8381903.17153930664063
So, if you had 10TH/s and wanted to keep your share finding to an hour, you'd use "ADDRESS/8381903"

Hope this helps.

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.
sconklin321
Member
**
Offline Offline

Activity: 109


View Profile
August 03, 2014, 08:57:45 PM
 #9852

I had a question that might if everything works as I believe, could be a possible solution to eliminate some of our issue with scalability.  Correct me if I'm wrong, but regardless of the actual hashrate on p2pool, it adjusts the minimum share difficulty to maintain an average of a 30 second share submission rate?  So if everyone used the "Address/Minimum share submit" it would then adjust the minimum difficulty to maintain the 30 second share submission regardless of the actual hashrate, correct?

If all of the above is true, wouldn't hard coding the formula below from JonnyBravo0311 to main a minimum share submission of 1 share/hr based on the address' hashrate alleviate some of the ever increasing difficutly so that smaller miners, I have to admit this includes myself at 250 gh/s, would be able to submit more shares?  It shouldn't effect anyone's income, as it was my understanding that we get our distributions based on weighted shares anyway.


Code:
Difficulty * 2**32 / hash rate = number of seconds to find a share
4500000 * 2**32 / R = 3600
R = 5368709120000


If all my assumptions are correct, I believe this would, at least for the short term, be a viable option until a more permanent can be found an coded.  Any feedback would be appreciated.
contactlight
Full Member
***
Offline Offline

Activity: 168


View Profile
August 03, 2014, 11:38:19 PM
 #9853

I have been mining on P2Pool lately and even though I had great payouts initially, I haven't been finding any shares lately.

I have two Antminer S3s and I have been thinking if it is a bad idea to have both of them mine to the same address. Wouldn't that make the P2Pool set a higher difficulty for both of them? Should I be mining to different addresses with them?
mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
August 04, 2014, 01:03:47 AM
 #9854

I have been mining on P2Pool lately and even though I had great payouts initially, I haven't been finding any shares lately.

I have two Antminer S3s and I have been thinking if it is a bad idea to have both of them mine to the same address. Wouldn't that make the P2Pool set a higher difficulty for both of them? Should I be mining to different addresses with them?

The pseudoshare will be higher, yes.  The shares that count will be the same regardless.

M

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
contactlight
Full Member
***
Offline Offline

Activity: 168


View Profile
August 04, 2014, 01:11:06 AM
 #9855

I have been mining on P2Pool lately and even though I had great payouts initially, I haven't been finding any shares lately.

I have two Antminer S3s and I have been thinking if it is a bad idea to have both of them mine to the same address. Wouldn't that make the P2Pool set a higher difficulty for both of them? Should I be mining to different addresses with them?

The pseudoshare will be higher, yes.  The shares that count will be the same regardless.

M

So the actual share difficulty is actually not based on the hashrate of the miner. Only the psuedoshare difficulty depends on the hashrate. Is that correct?

Are psuedoshares valued at all? Because even though my node says approximately 6 hours to a share, I don't get any shares even when I run my miner for over a day.
mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
August 04, 2014, 01:23:52 AM
 #9856

I have been mining on P2Pool lately and even though I had great payouts initially, I haven't been finding any shares lately.

I have two Antminer S3s and I have been thinking if it is a bad idea to have both of them mine to the same address. Wouldn't that make the P2Pool set a higher difficulty for both of them? Should I be mining to different addresses with them?

The pseudoshare will be higher, yes.  The shares that count will be the same regardless.

M

So the actual share difficulty is actually not based on the hashrate of the miner. Only the psuedoshare difficulty depends on the hashrate. Is that correct?

Are psuedoshares valued at all? Because even though my node says approximately 6 hours to a share, I don't get any shares even when I run my miner for over a day.

Pseudoshares only make your hashrate look better on the graph.  The actual share chain difficulty is based upon the entire hashrate of the pool.  Keep in mind luck (aka variance) plays a role here.  When it says approx 6 hours, that's on average.  You'll have some that are less, some that are more, but your luck has to be pretty bad to not get one within 24 hours.

I've got two folks on my node that look like they're using two S3s a piece.  They're chugging right along with shares, so S3s seem to be working well.

M


MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
ceslick
Full Member
***
Offline Offline

Activity: 161

digging in the bits... now ant powered!


View Profile WWW
August 04, 2014, 01:55:24 AM
 #9857

So what are the best settings then for an S1 running at 200GHS on P2Pool?


http://www.integratedideas.net  - Home of Rock Solid Miners
NZ Based BTC P2Pool: http://www.integratedideas.net/p2pool-btc/  -  NZ Based DOGE P2Pool: http://www.integratedideas.net/p2pool-doge/
Cloud mining with CEX.IO: https://cex.io/r/2/ceslicknz/0/
contactlight
Full Member
***
Offline Offline

Activity: 168


View Profile
August 04, 2014, 02:09:41 AM
 #9858

I have been mining on P2Pool lately and even though I had great payouts initially, I haven't been finding any shares lately.

I have two Antminer S3s and I have been thinking if it is a bad idea to have both of them mine to the same address. Wouldn't that make the P2Pool set a higher difficulty for both of them? Should I be mining to different addresses with them?

The pseudoshare will be higher, yes.  The shares that count will be the same regardless.

M

So the actual share difficulty is actually not based on the hashrate of the miner. Only the psuedoshare difficulty depends on the hashrate. Is that correct?

Are psuedoshares valued at all? Because even though my node says approximately 6 hours to a share, I don't get any shares even when I run my miner for over a day.

Pseudoshares only make your hashrate look better on the graph.  The actual share chain difficulty is based upon the entire hashrate of the pool.  Keep in mind luck (aka variance) plays a role here.  When it says approx 6 hours, that's on average.  You'll have some that are less, some that are more, but your luck has to be pretty bad to not get one within 24 hours.

I've got two folks on my node that look like they're using two S3s a piece.  They're chugging right along with shares, so S3s seem to be working well.

M



I don't think my miners can be this unlucky, though. No shares in this long might indicate a problem.

I remember a couple of weeks ago, when I was mining on the same node with the same hardware, I was getting shares constantly. Sure, variance but this seems too much.

I am doing stratum+TCP, should I try http? My DOA is about 3% so no problems there. My latency is no more than 80ms as well.
bryonp
Member
**
Offline Offline

Activity: 77


View Profile
August 04, 2014, 02:26:33 AM
 #9859

Do you all find a huge savings in electrical power when using your new S3's?
I run 4th
16 s-1's and 1 S-2... my electric bill is around 1250.00...

My income stands approx 2400.00 before electric???

Wondering if I should sell off my coin and buy s-3's or just hold out???

Anyone's input is so welcome...
Thanks
DUDES......

sconklin321
Member
**
Offline Offline

Activity: 109


View Profile
August 04, 2014, 02:45:47 AM
 #9860

I have been mining on P2Pool lately and even though I had great payouts initially, I haven't been finding any shares lately.

I have two Antminer S3s and I have been thinking if it is a bad idea to have both of them mine to the same address. Wouldn't that make the P2Pool set a higher difficulty for both of them? Should I be mining to different addresses with them?

The pseudoshare will be higher, yes.  The shares that count will be the same regardless.

M

So the actual share difficulty is actually not based on the hashrate of the miner. Only the psuedoshare difficulty depends on the hashrate. Is that correct?

Are psuedoshares valued at all? Because even though my node says approximately 6 hours to a share, I don't get any shares even when I run my miner for over a day.

Pseudoshares only make your hashrate look better on the graph.  The actual share chain difficulty is based upon the entire hashrate of the pool.  Keep in mind luck (aka variance) plays a role here.  When it says approx 6 hours, that's on average.  You'll have some that are less, some that are more, but your luck has to be pretty bad to not get one within 24 hours.

I've got two folks on my node that look like they're using two S3s a piece.  They're chugging right along with shares, so S3s seem to be working well.

M



I don't think my miners can be this unlucky, though. No shares in this long might indicate a problem.

I remember a couple of weeks ago, when I was mining on the same node with the same hardware, I was getting shares constantly. Sure, variance but this seems too much.

I am doing stratum+TCP, should I try http? My DOA is about 3% so no problems there. My latency is no more than 80ms as well.

The big difference from a couple weeks ago, is the hashrate and difficulty has gone up, I'd even estimate that it almost double over the past month.  That could have something to do with it.  I've also heard of pools taking as long as almost 7x expected to find a block.  Considering the sharechain mimics the blockchain, I'd say the same variance could easily be expected here.  It should happen too often, but it's definitely possible.
Pages: « 1 ... 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 [493] 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 ... 744 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!