Bitcoin Forum
September 29, 2016, 05:00:15 PM *
News: Due to DDoS attacks, there may be periodic downtime.
 
   Home   Help Search Donate Login Register  
Poll
Question: What type of pool payouts do you prefer?
Bitcoins - 3152 (80.4%)
Bank transfer / USD - 407 (10.4%)
Gold/silver coins and bars - 359 (9.2%)
Total Voters: 3916

Pages: « 1 ... 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 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 [64] 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 ... 1104 »
  Print  
Author Topic: [40+ PH] SlushPool (slushpool.com); World's First Mining Pool  (Read 3857746 times)
bobR
Member
**
Offline Offline

Activity: 112


View Profile
March 11, 2011, 07:58:35 PM
 #1261

Let's discuss about bitcoinpool.org on it's own thread, thank you.

Btw you can use fairuser's miner with my pool too. It is m0mchil's miner with few bullshits around. Then you can achieve the same 'high efficiency' also with my pool. But I don't recommend this to anybody not because I'm jealous to fairuser's pool, but simply because it is bad for YOU and using this modified miner, you are shooting to your leg. It is mathematically approved.

Like taking from early shares to correct a PROBLEM is right
and What happened to the only 1% charge
free & equal seems better to me
1475168415
Hero Member
*
Offline Offline

Posts: 1475168415

View Profile Personal Message (Offline)

Ignore
1475168415
Reply with quote  #2

1475168415
Report to moderator
1475168415
Hero Member
*
Offline Offline

Posts: 1475168415

View Profile Personal Message (Offline)

Ignore
1475168415
Reply with quote  #2

1475168415
Report to moderator
1475168415
Hero Member
*
Offline Offline

Posts: 1475168415

View Profile Personal Message (Offline)

Ignore
1475168415
Reply with quote  #2

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

Activity: 294



View Profile
March 11, 2011, 10:07:45 PM
 #1262

Devil is in the details. http://bitcoinpool.com/faq.php
Quote
Q: What happens if we solve a block with transaction fees on it? [TOP]

We keep them. Transaction fees are generally fairly small, and since we don't charge donations, we feel it's a small sacrifice to make in order to keep things Free™


I'm pretty sure all mining pools keep the transaction fees. Compared to the 50 BTC payout, they are basically nothing.

Like taking from early shares to correct a PROBLEM is right
and What happened to the only 1% charge
free & equal seems better to me

You're free to use any one of the other pools. Also, you still make as little sense as I remember.
Anonymous
Guest

March 12, 2011, 01:05:47 AM
 #1263

The 2% donation is better than the other pool's 3% donation. We have competition!

We do not force donations on bitcoinpool.com.  That's a big 0%.  Smiley


You get what you pay for.....




slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
March 12, 2011, 05:58:05 AM
 #1264

I'd like to announce new experimental feature, which is available on pool from today: long polling

Current "getwork" protocol is not effective enough - every miner is polling pool for new jobs once per few seconds. More frequent requests makes unnecessary network overhead and may slow down overall hashing speed because of network latency. On other side, longer "ask rate" leads to more stale shares (shares, which cannot be valid blocks, because in meantime new bitcoin block appeared on network).

Long polling is simple extension on top of current getwork protocol. Miner opens second connection to pool and pool keeps this request until new block on bitcoin network come (or up to 60 second timeout). Pool then immediately broadcast new jobs to miners in HTTP response of this "extra" connection. Thanks to this improvement, frequent "ask rate" is not necessary; with long polling mode enabled, miner can crunch hashes for whole nonce range (or 60 second timeout, which come first). This leads to higher mining efficiency, less network overhead and less pool load.

Updated miner software is everything you need to enjoy this feature. Currently, only m0mchil's poclbm miner has long polling support and there are also some known (minor) bugs. Please consider this as public beta testing and report all troubles to me or to m0mchil. Please note that pool is already sending special customized getwork response to support long polling by default, but latest poclbm cannot switch modes from command line yet, so you have to use older poclbm (version before 12/03/2011) to disable long polling feature.

Also all miner developers are welcome to support long polling in their software - it can brings crucial improvement especially for CPU mining.

urizane
Jr. Member
*
Offline Offline

Activity: 56



View Profile
March 12, 2011, 06:40:36 AM
 #1265

OK, I've switched over to m0mchil's OpenCL miner.  Being an nVidia owner, this sets me back only by 3 MHash/s from puddinpop's CUDA RPC miner.
Dude65535
Full Member
***
Offline Offline

Activity: 126


View Profile
March 12, 2011, 07:14:25 AM
 #1266

poclbm is showing several instances of invalid or stale shares 4-25 seconds after a "long poll: new block" message. I assume that shouldn't be happening? I also have cases of a valid share as soon as 1 second after a long poll message.

1DCj8ZwGZXQqQhgv6eUEnWgsxo8BTMj3mT
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
March 12, 2011, 07:34:47 AM
 #1267

poclbm is showing several instances of invalid or stale shares 4-25 seconds after a "long poll: new block" message. I assume that shouldn't be happening? I also have cases of a valid share as soon as 1 second after a long poll message.

Yes, I discovered problem in long polling loadbalancer, it unfortunately sometimes serve jobs from wrong backend (and then submitting those shares to correct backend leads to stale shares). I temporary turned long polling off and I will play with a configuration a little.

urizane
Jr. Member
*
Offline Offline

Activity: 56



View Profile
March 12, 2011, 01:28:37 PM
 #1268

I have a question for slush.  I'm not sure if you're familiar with rpcminer-cuda and its console output, but I'm beginning to wonder if I'll never see a message similar to m0mchil's OpenCL miner relating to stale shares.  The only messages I see are similar to:

Sending to server: {"method":"getwork","params":["<insert insanely long hex blob here>"],"id":1}
Server sent: {"result": true, "id": "1", "error": null}

Is the fact that I'm never seeing "result": false indicating that I don't produce stale shares or is the miner just not telling me about them?  (What I don't know won't hurt me, right?)

Also, since long polling got pulled (no pun intended) I've gone back to the CUDA miner as you can probably tell.  I've changed the ask rate from 4 seconds to 8 seconds and I'm still not seeing any stale messages.
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
March 12, 2011, 01:37:15 PM
 #1269

Sending to server: {"method":"getwork","params":["<insert insanely long hex blob here>"],"id":1}
Server sent: {"result": true, "id": "1", "error": null}

I'm not familiar with this miner, but this dump looks fine for me. Yes, result: false means stale share, so if you don't see them, everything is fine.

With getwork protocol, some rate of stale shares is normal. You can calculate expected share ratio by taking average time between bitcoin blocks and your typical ask rate. Then askrate/avgblocktime = probability to hit stale share. So if you're using default settings, it should be typically something like 5/600 = 0.8%. But this may slightly differ time to time. For example, with current difficulty and hash rate, average time between blocks is longer than 600 seconds (thanks to recent operation of "mystery miner"), which also leads in slightly lower stale rate.

urizane
Jr. Member
*
Offline Offline

Activity: 56



View Profile
March 12, 2011, 02:21:27 PM
 #1270

OK, well the upshot is that I'm producing valid shares, which is great.  I'm just not sure that I've ever seen anything except a valid share running this miner on my machine, even now that I've changed the ask rate to 8 seconds.  Maybe it's just sooo unlikely that I never see it.  Maybe the next time I restart these two miners, I'll dump the output to a text file and search for false.

Also, I'm not too sure I get the "mystery miner" bit, but I have noticed a chunk of time just under 2 hours where 18 blocks were found.  If it keeps up, 2000 blocks might happen really soon.

EDIT: Not long after I posted this, BAM!  I found ONE.

Code:
Sending to server: {"method":"getwork","params":["0000000142c744096ad91d977e2211
b86c8008a4453e8568ab7438f00000705e0000000035cdacbf9cbe69e72df8655d731382a4761630
561eda1ea1c8e6ce45092d9ce94d7b7ce21b00dc313af37b13000000800000000000000000000000
000000000000000000000000000000000000000000000000000000000080020000"],"id":1}
Server sent: {"result": false, "id": "1", "error": null}

It happend at 14:02:17, immediately following a block found at 14:02:11.  I guess that's the proof I was looking for.
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
March 12, 2011, 02:39:31 PM
 #1271

Also, I'm not too sure I get the "mystery miner" bit, but I have noticed a chunk of time just under 2 hours where 18 blocks were found.  If it keeps up, 2000 blocks might happen really soon.

Yes, there was peak in network hashrate last week, somebody pulled ~400Ghash/s into the network. This lead to higher difficulty. Now the network hashspeed is back to lower value, so difficulty is higher than should be for this week. It means that average time between two block is higher than 600 seconds so stale percentage is a bit lower.

Quote
EDIT: Not long after I posted this, BAM!  I found ONE.

Yes, in fact it is quite common Smiley.

snedie
Member
**
Offline Offline

Activity: 112


View Profile
March 13, 2011, 02:09:02 AM
 #1272

Hey Slush,

Just started mining today I heard your pool was apparently the best to be in.

Do you have any tips for new time miners?  Cool
xenon481
Sr. Member
****
Offline Offline

Activity: 406



View Profile
March 13, 2011, 03:11:20 AM
 #1273

poclbm is showing several instances of invalid or stale shares 4-25 seconds after a "long poll: new block" message. I assume that shouldn't be happening? I also have cases of a valid share as soon as 1 second after a long poll message.

Yes, I discovered problem in long polling loadbalancer, it unfortunately sometimes serve jobs from wrong backend (and then submitting those shares to correct backend leads to stale shares). I temporary turned long polling off and I will play with a configuration a little.

Is long polling still off or is it back on? I haven't gotten a single stale since I installed the latest poclbm over 12 hours ago. I had been seeing them about 1/hour before.

Tips Appreciated: 171TQ2wJg7bxj2q68VNibU75YZB22b7ZDr
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
March 13, 2011, 03:16:04 AM
 #1274

Is long polling still off or is it back on? I haven't gotten a single stale since I installed the latest poclbm over 12 hours ago. I had been seeing them about 1/hour before.

Long polling is still off, hope today I'll make a fix for the LP issue. You probably seen more "stale" shares before, because I did some tweaks during those two days and every time I restart server, it refuses currently opened connections.

Do you have any tips for new time miners?  Cool

Welcome on board :-). If is everything working for you, then just sit down and watch your wallet :-).

snedie
Member
**
Offline Offline

Activity: 112


View Profile
March 13, 2011, 07:57:05 PM
 #1275

Hey Slush,

Been mining in your pool for about 19 hours and have close to 10 coins credited (Getting around 0.41785415.coins per block: Is this good/bad/avg?), how long on average is the confirmation time on the blocks before the coins become available for me to use?
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
March 13, 2011, 08:57:18 PM
 #1276

Is this good/bad/avg?

Depends on your hashpower Smiley. If you have 1Mhash/s CPU, it is quite impressive Wink.

Quote
how long on average is the confirmation time on the blocks before the coins become available for me to use?

With typical network speed, it takes around 20 hours. You can see block confirmations on Stats page - when block become 'confirmed', your reward from that block is moved from 'unconfirmed' to 'confirmed' (it is recalculated by server once per hour).

bitjet
Hero Member
*****
Offline Offline

Activity: 556


View Profile
March 13, 2011, 09:14:56 PM
 #1277

Is this good/bad/avg?

Depends on your hashpower Smiley. If you have 1Mhash/s CPU, it is quite impressive Wink.



he;s about 1ghps
snedie
Member
**
Offline Offline

Activity: 112


View Profile
March 13, 2011, 09:16:22 PM
 #1278

Thanks Slush.

I'm currently running at a peak of 1.2Ghash/s, with rates varying between 700Mhash/s to 1.1Ghash/s.

In your pool, am I understanding it correctly in that the longer a user stays connected and the more work the do, they higher the pay out?
xenon481
Sr. Member
****
Offline Offline

Activity: 406



View Profile
March 13, 2011, 09:34:51 PM
 #1279

Thanks Slush.

I'm currently running at a peak of 1.2Ghash/s, with rates varying between 700Mhash/s to 1.1Ghash/s.

In your pool, am I understanding it correctly in that the longer a user stays connected and the more work the do, they higher the pay out?

All shares are worth something. The older that a share is, the more that it degrades in value. As such, the shares that are submitted right at the end of a round are worth the most.

Because the end of a round is indeterminate, there is little to no incentive for waiting to submit shares until towards the end of the round because you don't know when the end of the round will actually be. For all that you know, the round could end 30 seconds after it began. In fact, this has happened many times, even with high difficulty. A round could also take 9+ hours (this has also happened).

The odds that any single miner will find shares towards the beginning of the round or the end of the round are the exact same, regardless of the hashing power of that particular miner. You may find most of your shares at the beginning of this round, and then the next round you find most of your shares towards the end. It all evens out over time with statistical certainty.

It only takes ~1,000 shares (over the miner's entire lifetime, not just since it was last started) for the variance of this score based method to converge tightly with the variance of a standard share based method. For a CPU miner, that would take about 1 week. For a 5970, that could take less than 2 hours.

Tips Appreciated: 171TQ2wJg7bxj2q68VNibU75YZB22b7ZDr
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
March 13, 2011, 09:39:16 PM
 #1280

I'm currently running at a peak of 1.2Ghash/s, with rates varying between 700Mhash/s to 1.1Ghash/s.

Then  your earnings are OK (I didn't recalculate it, but I'm 2.2 and have ~2x higher reward).

Quote
In your pool, am I understanding it correctly in that the longer a user stays connected and the more work the do, they higher the pay out?

Well, it is generally true for all current pools - you don't earn anything when you're disconnected Smiley.

But if you're asking to score based system - it works quite differently than other pools. Extremely shortly - when you disconnect, reward for your contributed shares is going slightly down (is halved every 5 minutes), but when you connect in, it goes also up faster. When you connect in the middle of the round, after few minutes your reward is almost same as if you connected on the round beginning. So the score based system only affect behaviour of connecting/disconnecting, but does not affect your final reward, at least in long term (1000+ shares contributed to the pool by your miner). As you have >1Ghash/s, this does not affect you at all. So don't be affraid with connecting/disconnecting to the pool as you want.

This works as (quite effective Wink) defense against some possible pool attacks. Thanks to score based system, pool can also offer all system statistics in realtime (round start, current shares in round etc). Drawback of this method is that it introduce some bigger variance in reward for CPU users (but in all cases, after 1000+ shares it is statistically without difference).

You can read more details & watch pretty graphs done by cosurgi in previous thread post.

Pages: « 1 ... 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 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 [64] 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 ... 1104 »
  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!