Bitcoin Forum
December 04, 2016, 02:19:04 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 2 3 4 [5] 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 »
  Print  
Author Topic: [NEW POOL & MINER] - BitcoinPool.com - Jump In! ~NO FEES~ :)  (Read 95993 times)
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
March 09, 2011, 04:06:51 PM
 #81

it looks like you are trying to make it more efficient to allow more people in.

I'd like to notice that they are doing it more effective for them (for the pool), but using this "hacked" miner is less effective for users. We had long discussion with FairUser and Geebus about this and it looks they still don't understand what they are doing. Pretty bad for pool operators Wink. Their "mining efficiency" is absolutely irrelevant number.

I'm not using "ineffective miners" on my pool because I'm masochist but because it is good for users. By the way, everybody on my pool (or every other current pool) can "optimize" his miner by setting custom ask rate on command line. But I really don't recommend that.

Because I don't like to start long discussion about nothing again, this is both my first and last post in this thread. Thank you for reading.

1480861144
Hero Member
*
Offline Offline

Posts: 1480861144

View Profile Personal Message (Offline)

Ignore
1480861144
Reply with quote  #2

1480861144
Report to moderator
1480861144
Hero Member
*
Offline Offline

Posts: 1480861144

View Profile Personal Message (Offline)

Ignore
1480861144
Reply with quote  #2

1480861144
Report to moderator
1480861144
Hero Member
*
Offline Offline

Posts: 1480861144

View Profile Personal Message (Offline)

Ignore
1480861144
Reply with quote  #2

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

Activity: 4


View Profile
March 09, 2011, 04:23:55 PM
 #82

-a 5 -t 8 -o host@host.com:#### -u XXXXXXXX -p XXXXXXXXX is how you are supposed to set it up

I'm using it with deepbit's pool (deepbit.net) it also works with btcmine.com's miner

I dug through the source code of Ufasoft's miner.

Basically, most miners (poclbm, diablominer, rpc-miner, jgarzik's cpu miner) work like this:

Client (Request for Getwork w/ Authorization Headers included) --> Server
Server (Respond with Getwork) --> Client
Client (Send Hash from Getwork) --> Server
Server (Respond with Accepted, or Invalid/Stale) --> Client

Ufasoft's Miner works like this:
Client (Request Getwork) --> Server
Server (Prompt for Authorization) --> Client
Client (Respond with Credentials) --> Server
Server (Respond with Getwork) --> Client
Client (Send Hash from Getwork) --> Server
Server (Prompt for Authorization) --> Client
Client (Respond with Credentials) --> Server
Server (Respond with Accepted, or Invalid/Stale) --> Client

Twice as much network traffic, and incompatible with our pool simply because they don't include the credentials in the headers on every request.

Maybe you can email ufasoft about it and see if they can modify the way their miner works.

I'd like to point out my RPC Proxy fixes this issue with Ufasoft's client, as it doesn't use any authorization locally, and always sends authorization to the server.

Regards
elFarto
xenon481
Sr. Member
****
Offline Offline

Activity: 406



View Profile
March 09, 2011, 04:39:48 PM
 #83

Absolutely, this "efficiency" number is how much processing you are saving their server (potentially lowering server costs for the pool operator), not how much better you as a miner are doing.

To be fair, a more efficient pool server means that costs per miner are lower and those savings "can" (and currently are) be passed on from the pool operator to the miners.

The problem is that the way that this pool has implemented their efficiency gains comes at the cost of increased percentages of Stale (unpaid) wasted processing power. And to make it worse, it specifically causes slower miners to incur the worst of this increase of Stales.


I fully applaud and support these operators for having taken the initiative of creating their own pool (competition is awesome), but I will not stand for "spin" to be applied to try and hide the truth from an open community.

That being said, this certainly might be the most effective pool (due to no required fees) for miners with fast hardware.

Tips Appreciated: 171TQ2wJg7bxj2q68VNibU75YZB22b7ZDr
nster
Full Member
***
Offline Offline

Activity: 126



View Profile
March 09, 2011, 04:59:12 PM
 #84

Absolutely, this "efficiency" number is how much processing you are saving their server (potentially lowering server costs for the pool operator), not how much better you as a miner are doing.

To be fair, a more efficient pool server means that costs per miner are lower and those savings "can" (and currently are) be passed on from the pool operator to the miners.

The problem is that the way that this pool has implemented their efficiency gains comes at the cost of increased percentages of Stale (unpaid) wasted processing power. And to make it worse, it specifically causes slower miners to incur the worst of this increase of Stales.


I fully applaud and support these operators for having taken the initiative of creating their own pool (competition is awesome), but I will not stand for "spin" to be applied to try and hide the truth from an open community.

That being said, this certainly might be the most effective pool (due to no required fees) for miners with fast hardware.

How fast is "fast" is 250~300Mh/s enough to get more from this pool?

167q1CHgVjzLCwQwQvJ3tRMUCrjfqvSznd Donations are welcome Smiley Please be kind if I helped
nster
Full Member
***
Offline Offline

Activity: 126



View Profile
March 09, 2011, 05:15:30 PM
 #85

oh and guys, you can use the normal poclbm with this pool so if that is suppose to give you better performance, why can't we just use that?

167q1CHgVjzLCwQwQvJ3tRMUCrjfqvSznd Donations are welcome Smiley Please be kind if I helped
jgarzik
Legendary
*
Offline Offline

Activity: 1470


View Profile
March 09, 2011, 05:40:35 PM
 #86

oh and guys, you can use the normal poclbm with this pool so if that is suppose to give you better performance, why can't we just use that?

The modified poclbm does not give you better performance -- more hashes per second -- nor does it find more shares than the unmodified.


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Raptorblaze
Newbie
*
Offline Offline

Activity: 15


View Profile
March 09, 2011, 05:41:27 PM
 #87

oh and guys, you can use the normal poclbm with this pool so if that is suppose to give you better performance, why can't we just use that?

The average person isn't that creative Smiley My efficiency on the stats page is low because i was having trouble getting their miner to work at first. Totally forgot the .exe name was poclbm-mod, not just poclbm in the batch file....*facepalm*  Hope they send me my payments soon, i've been running for almost 13 hours now and haven't seen anything. More information on the payment system would be appreciated.
Edit: Just to clarify, I recall reading something about slush's pool requiring more confirmations for each block than actually necessary. The number for default confirmations (i believe...) was 120? which would put it at ~20 hours per confirmation. So I'm not getting impatient at this point.

Donate: 12tBZRNcf4NaGVDzhyV1Hm1Zb2a6RdyZYH
nster
Full Member
***
Offline Offline

Activity: 126



View Profile
March 09, 2011, 05:44:52 PM
 #88

oh and guys, you can use the normal poclbm with this pool so if that is suppose to give you better performance, why can't we just use that?

The average person isn't that creative Smiley My efficiency on the stats page is low because i was having trouble getting their miner to work at first. Totally forgot the .exe name was poclbm-mod, not just poclbm in the batch file....*facepalm*  Hope they send me my payments soon, i've been running for almost 13 hours now and haven't seen anything. More information on the payment system would be appreciated.

We haven't found a block yet so we don't get paid yet... and the difficulty increased so we have even less chance to get a block now >.>

167q1CHgVjzLCwQwQvJ3tRMUCrjfqvSznd Donations are welcome Smiley Please be kind if I helped
Raptorblaze
Newbie
*
Offline Offline

Activity: 15


View Profile
March 09, 2011, 05:48:54 PM
 #89

oh and guys, you can use the normal poclbm with this pool so if that is suppose to give you better performance, why can't we just use that?

The average person isn't that creative Smiley My efficiency on the stats page is low because i was having trouble getting their miner to work at first. Totally forgot the .exe name was poclbm-mod, not just poclbm in the batch file....*facepalm*  Hope they send me my payments soon, i've been running for almost 13 hours now and haven't seen anything. More information on the payment system would be appreciated.

We haven't found a block yet so we don't get paid yet... and the difficulty increased so we have even less chance to get a block now >.>

Yeah I was just perusing the Block solved history, I'm hoping to upgrade my miner with birthday money (No criticism, I'm turning 19 and still get birthday money) next week on Thursday.

Donate: 12tBZRNcf4NaGVDzhyV1Hm1Zb2a6RdyZYH
Raptorblaze
Newbie
*
Offline Offline

Activity: 15


View Profile
March 09, 2011, 06:42:00 PM
 #90

oh and guys, you can use the normal poclbm with this pool so if that is suppose to give you better performance, why can't we just use that?

The modified poclbm does not give you better performance -- more hashes per second -- nor does it find more shares than the unmodified.


Let me check to make sure I'm understanding this right:
Both clients do approximately the same in terms of mining
The modified client significantly reduces the load on the server
A reduced load on the server allows more users to join the pool
More users in the pool allows the pool as a whole to find blocks more quickly

I'm not seeing the disadvantage here....
Edit:Sorry for the double post!

Donate: 12tBZRNcf4NaGVDzhyV1Hm1Zb2a6RdyZYH
jgarzik
Legendary
*
Offline Offline

Activity: 1470


View Profile
March 09, 2011, 06:52:28 PM
 #91

oh and guys, you can use the normal poclbm with this pool so if that is suppose to give you better performance, why can't we just use that?

The modified poclbm does not give you better performance -- more hashes per second -- nor does it find more shares than the unmodified.


Let me check to make sure I'm understanding this right:
Both clients do approximately the same in terms of mining
The modified client significantly reduces the load on the server
A reduced load on the server allows more users to join the pool

Is the pool remotely near capacity?  If not, then it makes zero difference.


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
March 09, 2011, 06:53:15 PM
 #92

Let me check to make sure I'm understanding this right:
Both clients do approximately the same in terms of mining
The modified client significantly reduces the load on the server
A reduced load on the server allows more users to join the pool
More users in the pool allows the pool as a whole to find blocks more quickly

I'm not seeing the disadvantage here....

(I simply cannot stay outside)

Yes, less load on server for +/- same total pool hashrate. But you (as a miner) are not motivated to have huge hashrate on server, you're motivated to have high OWN hashrate. Higher pool hash rate does not make your payouts higher (only more steady). So with long ask rate to server, you're cutting your effective hashrate and losing some valid shares because you work on stale jobs.

bombo999
Member
**
Offline Offline

Activity: 107


View Profile
March 09, 2011, 07:06:24 PM
 #93

hey slush ... perhaps if you spent more time working on your own pool it might re-open for registration sooner
Raptorblaze
Newbie
*
Offline Offline

Activity: 15


View Profile
March 09, 2011, 07:10:30 PM
 #94

hey slush ... perhaps if you spent more time working on your own pool it might re-open for registration sooner
This

Also, I'm in favor of an idea that doesn't limit the number of participants as much as yours with little disadvantages to the user themself, which this seems to do.

Donate: 12tBZRNcf4NaGVDzhyV1Hm1Zb2a6RdyZYH
neptop
Sr. Member
****
Offline Offline

Activity: 314


View Profile
March 09, 2011, 09:12:31 PM
 #95

View your profile at:
http://www.bitcoinpool.com/users.php?u=xxx

...is wrong, it is user.php Wink

BitCoin address: 1E25UJEbifEejpYh117APmjYSXdLiJUCAZ
martok
Full Member
***
Offline Offline

Activity: 140


View Profile
March 09, 2011, 10:21:10 PM
 #96

I'm not sure the modified poclbm does this. By looking at the code it doesn't seem to but maybe a compromise would be to use the "efficient" miner but if a block comes back as invalid, we submit a new getwork and start working on a new block. If a block is invalid, no sense continuing on the existing getwork right?
geebus
Sr. Member
****
Offline Offline

Activity: 258



View Profile WWW
March 09, 2011, 11:06:11 PM
 #97

So you admit that your pool too favors faster miners when you specifically (incorrectly in every way except your one shortsighted emotions over statistics way) chided Slush's pool for doing so in your OP.

"Testing with" and "favoring" are two different things. We pay CPUs and GPUs the same amount for each share. We don't "favor" either one over the other.


Feel like donating to me? BTC Address: 14eUVSgBSzLpHXGAfbN9BojXTWvTb91SHJ
geebus
Sr. Member
****
Offline Offline

Activity: 258



View Profile WWW
March 09, 2011, 11:25:05 PM
 #98

(I simply cannot stay outside)

Yes, less load on server for +/- same total pool hashrate. But you (as a miner) are not motivated to have huge hashrate on server, you're motivated to have high OWN hashrate. Higher pool hash rate does not make your payouts higher (only more steady). So with long ask rate to server, you're cutting your effective hashrate and losing some valid shares because you work on stale jobs.

Maybe your pool wouldn't be in the situation it is in now if it had less network traffic against it.

Our version of poclbm does NOT lower the hashrate of anyone using it. Theoretically, or otherwise. It gains shares at the same speed, and as long as we're accepting the shares, it doesn't negatively impact the user in any way, but benefits us greatly.

Even if a small percentage (and it's small, < .55%) of shares are stale, we can still allow 10 new users for every 1 user that runs our miner due to the reduction in server load.

To be fair, a more efficient pool server means that costs per miner are lower and those savings "can" (and currently are) be passed on from the pool operator to the miners.

The problem is that the way that this pool has implemented their efficiency gains comes at the cost of increased percentages of Stale (unpaid) wasted processing power. And to make it worse, it specifically causes slower miners to incur the worst of this increase of Stales.

We've been completely open about why we said it was more efficient. We've been completely open about what our definition of efficient was... Our definition just happened to be the same as the dictionary's definition of efficient.

Yes, it is for the benefit of the server. We charge NOTHING to participate however, so there is no benefit to the "operators" aside from being able to participate in a pool that functions the way we want it to...

And no, the slower miners don't see any negative impact, because we accept shares, and pay them for shares for (CurrentBlock) and (CurrentBlock - 1). If a block is solved every 600 seconds, it would take them 1200 seconds to have their new shares for a getwork become stale.

If 1200 seconds is too slow for you to submit I share, I apologize, but I might suggest upgrading from your PIII to save you some trouble.


Feel like donating to me? BTC Address: 14eUVSgBSzLpHXGAfbN9BojXTWvTb91SHJ
xenon481
Sr. Member
****
Offline Offline

Activity: 406



View Profile
March 09, 2011, 11:35:05 PM
 #99

So you admit that your pool too favors faster miners when you specifically (incorrectly in every way except your one shortsighted emotions over statistics way) chided Slush's pool for doing so in your OP.

"Testing with" and "favoring" are two different things. We pay CPUs and GPUs the same amount for each share. We don't "favor" either one over the other.

Your pool asks the miners to keep a high Share/GetWork ratio. In order to accomplish this, your pool requests that miners process the entire solution space of every single GetWork before requesting another GetWork. This means that the slower a miner, the more likely that that miner's solutions will be Stale.

If it takes a slow miner 300 seconds (5 minutes) to process through an entire GetWork's solution space (say a Core2 Quad CPU Miner), and if a block was solved by anyone in the entire BitCoin network even a full minute after the miner requested the GetWork, then that miner has been sitting there processing for 4 full minutes completely wasting the miner's time and electricity.

This increase in Stale Processing can lead to a very significant amount of wasted processing power, wasted electricity, and lack of pay for miners.

Even the miner in the OP (~160MHash/Sec) is requesting a GetWork once every 26 seconds instead once every 5 seconds as is the default on many miners. That's 5 times longer during which the work can become Stale. Now imagine taking that 5 seconds and multiplying it by 60 to get 300 seconds for a fairly fast CPU Miner. That is 60x the time during which the work can become Stale.

So, yes, your pool favors faster miners over slower miners by requesting that miners process the entire GetWork solution space and thus giving slower miners a significantly higher percentage of Stales than faster miners.

Tips Appreciated: 171TQ2wJg7bxj2q68VNibU75YZB22b7ZDr
xenon481
Sr. Member
****
Offline Offline

Activity: 406



View Profile
March 09, 2011, 11:38:00 PM
 #100

And no, the slower miners don't see any negative impact, because we accept shares, and pay them for shares for (CurrentBlock) and (CurrentBlock - 1). If a block is solved every 600 seconds, it would take them 1200 seconds to have their new shares for a getwork become stale.

That is not what is stated in the OP.

Quote from: FairUser
- Anti-fraud protection.  We only accept shares from the current block, in the current round.

Tips Appreciated: 171TQ2wJg7bxj2q68VNibU75YZB22b7ZDr
Pages: « 1 2 3 4 [5] 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 »
  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!