Bitcoin Forum
August 17, 2018, 10:08:27 AM *
News: Latest stable version of Bitcoin Core: 0.16.2  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 [239] 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 ... 1145 »
  Print  
Author Topic: [4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool  (Read 4339995 times)
allinvain
Legendary
*
Offline Offline

Activity: 2576
Merit: 1052



View Profile
January 15, 2012, 02:46:08 PM
 #4761


I few days ago my reject ratio was 0.3% and now its 2-3%, and I'm getting a lot of miner idle warnings in phoenix, is this causes by my own settings/system/upgraded phoenix + kernel or is slush getting ddosed again?

What version of phoenix are you running? I used to have the same problem as you until I upgraded to 1.7.3. Also do you have a manually set "ask rate" (in the phoenix command line argument) ?


I don't have a manual set ask rate, I'm using 1.7.3 and this kernel: https://bitcointalk.org/index.php?topic=25135.0

Ah that explains it. There is some bug in the latest phoenix version when running with that kernel (checkout the phoenix thread for details). I would suggest going back to phatk2 to see if it makes a difference.

BOUNTY PORTALS
BLOG
WHERE BOUNTY MANAGEMENT
MEETS AUTOMATION
SIGNATURE CAMPAIGNS
TWITTER
FACEBOOK
MEDIA CAMPAIGNS
AND MORE!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1534500507
Hero Member
*
Offline Offline

Posts: 1534500507

View Profile Personal Message (Offline)

Ignore
1534500507
Reply with quote  #2

1534500507
Report to moderator
1534500507
Hero Member
*
Offline Offline

Posts: 1534500507

View Profile Personal Message (Offline)

Ignore
1534500507
Reply with quote  #2

1534500507
Report to moderator
allinvain
Legendary
*
Offline Offline

Activity: 2576
Merit: 1052



View Profile
January 16, 2012, 03:36:42 AM
 #4762


I few days ago my reject ratio was 0.3% and now its 2-3%, and I'm getting a lot of miner idle warnings in phoenix, is this causes by my own settings/system/upgraded phoenix + kernel or is slush getting ddosed again?

What version of phoenix are you running? I used to have the same problem as you until I upgraded to 1.7.3. Also do you have a manually set "ask rate" (in the phoenix command line argument) ?


I don't have a manual set ask rate, I'm using 1.7.3 and this kernel: https://bitcointalk.org/index.php?topic=25135.0

Ah that explains it. There is some bug in the latest phoenix version when running with that kernel (checkout the phoenix thread for details). I would suggest going back to phatk2 to see if it makes a difference.
Nope, I tried 1.7.2 again with that kernel and its still having issues.

Hmm, ok, next thing to try would be a different mining program. If you get the same issue then it must be the pool or somehow your internet connection. Does this happen on all your miners (if you have more than 1)?

Oh I forgot to mention did you also try 1.7.0?

From what I can gather in this thread: https://bitcointalk.org/index.php?topic=6458.new;topicseen#new

It seems this has something to do with PyOpenCL.

Epoch
Legendary
*
Offline Offline

Activity: 917
Merit: 1000



View Profile
January 16, 2012, 03:47:37 AM
 #4763

Thanks for all the info, going to stick with slush's pool  Grin

In the long run, Slush's pool (like any other) will converge to the same expected payout. Daily variances can be large, weekly as well, so don't base your decisions on that.

For your earlier question about expected per-day payout for a 1Ghash rate: at today's difficulty you can expect to get 0.784BTC (0.8BTC minus the 2% fee that Slush charges). Here's a handy calculator: http://www.alloscomp.com/bitcoin/calculator.php

BTC: 1DJVUnLuPA2bERTkyeir8bKn1eSoRCrYvx
NMC: NFcfHSBBnq622pAr1Xoh9KtnBPA5CUn6id
slush
Legendary
*
Offline Offline

Activity: 1372
Merit: 1019



View Profile WWW
January 16, 2012, 02:45:23 PM
 #4764

Gratz on 10k blocks!

Heh, I didn't noticed that, thanks! :-)

slush
Legendary
*
Offline Offline

Activity: 1372
Merit: 1019



View Profile WWW
January 16, 2012, 02:46:52 PM
 #4765

damn we've been having some bad luck here the last day or so... a couple 7-8 hour blocks.
edit: 1 day pool luck is currently at 39%  Cry

Yep, it was insane day. But we're now at 130% in one day and 99% in seven day average, which is pretty good.

BinoX
Full Member
***
Offline Offline

Activity: 140
Merit: 100



View Profile
January 16, 2012, 02:57:14 PM
 #4766

Hoping that the luck continues Smiley
shad
Full Member
***
Offline Offline

Activity: 148
Merit: 100


View Profile
January 17, 2012, 04:44:44 PM
 #4767

feature request: payout time intervall

my problem is that i want a daily payout, i am doing this right now by setting payout_limit to 7day average, but i am a little unhappy that the intervall in which my payments get send is so variable

i would like somethink like
Quote
if last_payment_time + payment_timeintervall < actual_time && payout_limit > btc_balance then
PAYOUTTIME

i think that is the easiest way to explane about what i think, no language problems in code Cheesy
i think payment_timeintervall should be in days and the payout_limit which already can't be set under 0.01 afaik will secure that there aren't to tiny payouts

what do you think?


15dUzJEUkxgjrtcvDSdsEDkXu7E7RCbNN3
sadpandatech
Hero Member
*****
Offline Offline

Activity: 504
Merit: 500



View Profile
January 18, 2012, 01:35:17 AM
 #4768

Hmm I'm having issues again, using phoenix and phatk modified kernel: https://bitcointalk.org/index.php?topic=25135.0
 -k phatk DEVICE=0 VECTORS2 AGGRESSION=16 WORKSIZE=64 FASTLOOP=false
On a unlocked 6950, running at 930 mhz core and 1430 mhz memory.

It was working perfectly but yesterday my isp did some maintenance and now the program will only mine 9 shares and after that it "hangs"
I tried disabling long polling, went back to phoenix 1.7.2 and tried 2 different modified kernels.

If you are running the latest phatk, try removing the 'FASTLOOP=FALSE' from your arguments.
If that does not change anything try with the normal vectors, aggr, etc. i.e, 'VECTORS AGGRESSION=8 WORKSIZE=256'
That memory sounds awfully high for running vectors2 as well. Though if it worked for you in the past then it may not be the issue. I would try lowering it to about 800 if using vectors2

If you're not excited by the idea of being an early adopter 'now', then you should come back in three or four years and either tell us "Told you it'd never work!" or join what should, by then, be a much more stable and easier-to-use system. - GA
It is being worked on by smart people. -DamienBlack
Mashrock
Jr. Member
*
Offline Offline

Activity: 47
Merit: 0


View Profile
January 18, 2012, 11:23:36 PM
 #4769

Found me a block! woohoo!

slush
Legendary
*
Offline Offline

Activity: 1372
Merit: 1019



View Profile WWW
January 19, 2012, 10:32:32 AM
 #4770

sadpandatech: Thanks for doing mining support! I don't have such experience to help members with hardware...

slush
Legendary
*
Offline Offline

Activity: 1372
Merit: 1019



View Profile WWW
January 19, 2012, 10:34:28 AM
 #4771

feature request: payout time intervall

my problem is that i want a daily payout, i am doing this right now by setting payout_limit to 7day average, but i am a little unhappy that the intervall in which my payments get send is so variable

i would like somethink like
Quote
if last_payment_time + payment_timeintervall < actual_time && payout_limit > btc_balance then
PAYOUTTIME

i think that is the easiest way to explane about what i think, no language problems in code Cheesy
i think payment_timeintervall should be in days and the payout_limit which already can't be set under 0.01 afaik will secure that there aren't to tiny payouts

what do you think?

Yep, I was thinking about it too and I pretty like your proposal. I'll do it soon.

slush
Legendary
*
Offline Offline

Activity: 1372
Merit: 1019



View Profile WWW
January 20, 2012, 03:37:51 PM
 #4772

Newest poclbm miner (git version only, will be released as new version in following days) has nice support for Tor mining. Thank you m0mchil!

1. Install Tor on mining computer. No special configuration is needed, client mode (default) is enough.
2. Example command to run poclbm over Tor:

Code:
./poclbm.py --verbose -d 0 --proxy=localhost:9050 http://username.worker:password@pool57wkuu5yuhzb.onion:8332

That's all! poclbm over Tor supports long polling and ntime rolling and our testing computers achieved ~1% stale ratio, which is pretty good result for mining over high latency network like Tor.

Tor mining have some benefits. Not only that mining is purely anonymous then, but it's also DDoS resilient, because Tor service on the pool is running over secret IP...

As you can see on stats page, there are already some miners connected over the Tor. Happy mining!

Sargasm
Member
**
Offline Offline

Activity: 112
Merit: 10


View Profile
January 21, 2012, 02:58:19 AM
 #4773

I have found some interesting data that seems to point at pretty substantial losses due to pool hopping in early parts of rounds.

Basically I ran a bunch of numbers and I'm looking at some anomalies that would be highly unlikely to be caused by chance.

Since I was seeing what seemed to be much lower numbers than I should have seen on short rounds, I had to do some data analysis with small sample set that had some progressive variance caused by systems going down from time to time.

So, my analysis is off a somewhat normalized figure of 5 chronologically continuous blocks average.  I compared the 5 block normalized average to a percentage figure for individual payouts over or under the mean for all payouts.

It shows that in blocks that move faster, payouts deviate from running averages to the tune of 85.34% against averages.

Larger blocks have a mean average of 104.47%.

You can see the analysis here:

https://docs.google.com/spreadsheet/pub?key=0AhhejNMzWwx8dGpYZE9FYXk3d05MQjVDNUxLcHNXZkE&output=html

If it is pool jumping, it is killing our profits by potentially more than 5%.  The only real other thing it could be is slush.

If it is pool jumping, the solution seems simple.  Distribute an initial set of shares each round based upon the percentage of total shares by user in the round preceding.  The initial set of shares should be determined by estimated shares at current hash rate in the first 5 minutes.

This will suck the piss out of pool jumpers and give the loyal folk here their hard earned full return.

Thoughts?
Sargasm
Member
**
Offline Offline

Activity: 112
Merit: 10


View Profile
January 21, 2012, 03:04:10 AM
 #4774

Whatever it is... it is raping us.
slush
Legendary
*
Offline Offline

Activity: 1372
Merit: 1019



View Profile WWW
January 21, 2012, 09:49:44 AM
 #4775

Basically I ran a bunch of numbers and I'm looking at some anomalies that would be highly unlikely to be caused by chance.

Sargasm, things is more complicated that it seems to be. I never said that there aren't pool hoppers. There are a lot of calculations for various pool models for pool hopping and it's known that score method used on my pool have some minor flaw from the view of pool hopping. Actually only PPS (requires higher fee) and double geometric (very complicated) methods are supposed to be fully hop resistant, but I don't want to open ANY discussion about this now, because everything has been discussed before.

FYI I'm working on rewriting the pool to double geometric method, to satisfy all people who're complaining about even very minor chance of extra gains for pool hoppers. Unfortunately double geometric is _really_ complex method and it does not scale well for large pools. Btw I discussed scalable algorithm of DGM with Meni Rosenfeld on Prague conference...

Back to topic. Although the variance for short rounds is done by pool hoppers, it does not mean it's your loss. It's because you forgot that thanks to pool hoppers, there's higher hashspeed in shorter rounds. Actually the hashrate for long rounds (so hashrate average cleaned from pool hoppers) is around 1350-1400 Ghash, on the beginning of the round there's hashrate slightly over 1500 Ghash, which fits your number pretty well. Don't forget that it's even more complicated, because pool hoppers don't disconnect at same time, but they use various methods and are following various pools. The pool hopping benefit is *teoretically* around 5% of pool hopper profit, BUT hoppers are working on the pool just for very short period of time (depends on selected algorithm, but less than 5 minutes?), which means that their average block reward in absolute numbers is very small comparing with full-time mining. So only 5% of this tiny profit is the real loss for others.

I'm not talking that it isn't a problem. But the real loss done by pool hoppers is insignificant in the global view (it's much lower than natural variance in bitcoin mining itself) and it's better to wait to correct implementation of DGM than hurry and break the reward calculations in some strange way.

Sargasm
Member
**
Offline Offline

Activity: 112
Merit: 10


View Profile
January 21, 2012, 10:24:49 AM
 #4776

Well, perhaps, but those hoppers didn't do the sometimes 4 hours of processing on the server that we did in order to get a shot at a fresh block.

While we're slaving away at calculating that hash...they're off trying to get more than their due many other places.

Anyway, I can solve the problem with a relative degree of ease.

You create another class of shares called 'loyalty shares'.  You create a number of shares equal to the estimated share count at 5 minutes with current has power.

You distribute loyalty shares proportional to the payouts on your last block.

So...

Two things...

1) Pool hoppers would be fucked. (their margins would be reduced to tatters.  If they happend to hop in on a 2 pool that closed in 2 minutes, their share would be super miniscule due to the loyalty shares.

2) It would ease attrition on long length blocks because folks wouldn't get the loyalty shares if they bailed.

This way... instead of your most loyal folks getting shafted in short rounds, we'd end up doing the best.
Sargasm
Member
**
Offline Offline

Activity: 112
Merit: 10


View Profile
January 21, 2012, 10:30:40 AM
 #4777


Back to topic. Although the variance for short rounds is done by pool hoppers, it does not mean it's your loss. It's because you forgot that thanks to pool hoppers, there's higher hashspeed in shorter rounds. Actually the hashrate for long rounds (so hashrate average cleaned from pool hoppers) is around 1350-1400 Ghash, on the beginning of the round there's hashrate slightly over 1500 Ghash, which fits your number pretty well. Don't forget that it's even more complicated, because pool hoppers don't disconnect at same time, but they use various methods and are following various pools. The pool hopping benefit is *teoretically* around 5% of pool hopper profit, BUT hoppers are working on the pool just for very short period of time (depends on selected algorithm, but less than 5 minutes?), which means that their average block reward in absolute numbers is very small comparing with full-time mining. So only 5% of this tiny profit is the real loss for others.

No no... 5% is the net loss.

The loss only on fast blocks is near 25% on average.  

So we're losing 25% of our potential pay off for a 5% gain in performance.  So the miners are netting somewhere around 25% more per hash by hopping pools than we do sticking it out.
slush
Legendary
*
Offline Offline

Activity: 1372
Merit: 1019



View Profile WWW
January 21, 2012, 10:32:25 AM
 #4778

As I said, everything has been discussed before. Adding "loyalty shares" won't work as expected because of low hashrate miners. Are they mining, idling or hopping? Upgrading the rewarding system is definitely the way to go.

Quote
No no... 5% is the net loss.

Please... read all the stuff and don't open the discussion again... Seriously... Edit: I recommend you papers of Meni Rosenfeld, he has very nice calculations for almost every method.

Sargasm
Member
**
Offline Offline

Activity: 112
Merit: 10


View Profile
January 21, 2012, 10:35:59 AM
 #4779

As I said, everything has been discussed before. Adding "loyalty shares" won't work as expected because of low hashrate miners. Are they mining, idling or hopping? Upgrading the rewarding system is definitely the way to go.

So are low hashrate miners having problems in your current system?

Because if your current system is able to handle them, then by distributing loyalty shares each round (for that round only, then they go away) you'd be handicapping by way of the distribution of rewards for the last round.
                                                                                   
Are you having a tough time with your payouts to slow miners now?
slush
Legendary
*
Offline Offline

Activity: 1372
Merit: 1019



View Profile WWW
January 21, 2012, 10:39:29 AM
 #4780

So are low hashrate miners having problems in your current system?

No, they have just higher variance, but it averages out itself (after 1000-10000 shares).

Pages: « 1 ... 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 [239] 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 ... 1145 »
  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!