[4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool

[valladex]

   9285.081 Ghash/s    all that hashing power just came and went, did a large pool go down or is that just "pool hoppers"?

10% difference can well be because of luck spike and will stay for exactly 30min

please excuse my ignorance, i'm a newbie, but are you saying luck increases the hash power, i noticed it went up the other (exceptional) day, i put this down to more people joining the pool.

If that's what he's saying then he's so very wrong. We're not talking about the network here. We know how many shares are contributed, so we have a very good estimation of the hashrate.

If the variable difficulty shares were set to extremely high difficulty levels (close to the current network difficulty) then maybe this would be the case and it would be hard to judge the pool's hashrate. But they're not so it isn't.

It doesnt seem logical to me whatsoever that luck would increase hash rate, but i'm a newbie and here to learn what i can, all i can do is ask questions atm. all explanations welcome.

[Resetif]

I already am mining on Slush's Pool 14 hours. Power 2200Mh\s. Why I do not calculate Namecoin?

Unconfirmed reward:0.00000000 NMC
Confirmed reward:  0.00000000 NMC

Connected to stratum. Cgminer 3.1.0

[wedgy2k]

Hi (sorry another noob question)

I've only mined with Slush's pool for BTC and am now taking more of an active interest in the statistics page
(they also seem to be referred to on this thread a lot! lol)

So is the Round duration
Current round duration:   4:58:21
and the
Block duration 0:17:24

The same figure?

IE how long the pool is working to solve 1 block?

So the shorter time being better?

I see earlier in the thread reference's to 3 in an hour (Hatrick!) so are we paying for that with a 5 hour block?

or am i way of the mark here?

[KNK]

OK look here http://bitcoin.sipa.be/speed-lin-2k.png (about the luck spikes) and pay attention to the 8 hour average - it jumps for over 20% (60TH to 100TH), while 1 day average is more stable at ~75-80Th

Why is it so: you get a work to hash by trying 2^32 nonces with it and this will take for your hardware (let's say) 5sec, but it may return from 0 up to 2^32 valid shares. On average (hashing for a long time) you will get 1 share for each getwork (1 every 5sec), but accidentally you hit a getwork that returns 5 shares in the same 5sec - it looks like you have 5 times faster miner, because of the luck spike. After few seconds your average hashrate goes back to normal, as you don't get such works regularly.

It is the same for the pool - some miner submits more shares, than his speed, which 'tricks' the pool (for while), that it got higher hasrate

[bobsmoke]

I already am mining on Slush's Pool 14 hours. Power 2200Mh\s. Why I do not calculate Namecoin?

Hi, under system statistics on Slush pool you have Bitcoin blocks and Namecoin blocks..you can look there for NMC,

[autonomous42]

Hey everyone. Look out for round 17979. It maybe another round in which people get stilted on their earnings. I have a new theory about it. It started when I was watching my account page. I saw the estimated reward drop from a typical .003 or so to .00000001. Then over the course of 30 minutes it eked up to .00000007, then .00000015, .00000240, and get close to my usual. What was going on at the time, however, was the total score for the round had not reset in a good 15-20 blocks. I'm not sure yet how often the total score resets but it was a 14-digit number starting in 5 before the fever broke. Some people last time thought it was stratum backing up and not properly reporting shares but it's this danged "hop-proof" mechanic Slush employs! I've got a thing or two to say about that in general, but I think I may have found the bug.

[organofcorti]

OK look here http://bitcoin.sipa.be/speed-lin-2k.png (about the luck spikes) and pay attention to the 8 hour average - it jumps for over 20% (60TH to 100TH), while 1 day average is more stable at ~75-80Th

Why is it so: you get a work to hash by trying 2^32 nonces with it and this will take for your hardware (let's say) 5sec, but it may return from 0 up to 2^32 valid shares. On average (hashing for a long time) you will get 1 share for each getwork (1 every 5sec), but accidentally you hit a getwork that returns 5 shares in the same 5sec - it looks like you have 5 times faster miner, because of the luck spike. After few seconds your average hashrate goes back to normal, as you don't get such works regularly.

It is the same for the pool - some miner submits more shares, than his speed, which 'tricks' the pool (for while), that it got higher hasrate

No, it's not. We have a much better estimate for the number of hashes submitted to the pool than to the network. You've estimated the variance for the network in a previous post - try estimating it instead with Difficulty = 1 instead of Difficulty = 10 million.

[KNK]

It is no different for the pool - "you hit a getwork that returns 5 shares in the same 5sec - it looks like you have 5 times faster miner"

[vs3]

Hey everyone. Look out for round 17979. It maybe another round in which people get stilted on their earnings. I have a new theory about it. It started when I was watching my account page. I saw the estimated reward drop from a typical .003 or so to .00000001. Then over the course of 30 minutes it eked up to .00000007, then .00000015, .00000240, and get close to my usual. What was going on at the time, however, was the total score for the round had not reset in a good 15-20 blocks. I'm not sure yet how often the total score resets but it was a 14-digit number starting in 5 before the fever broke. Some people last time thought it was stratum backing up and not properly reporting shares but it's this danged "hop-proof" mechanic Slush employs! I've got a thing or two to say about that in general, but I think I may have found the bug.

I noticed the same. I suspect there may have been another DDoS attack as all of my miners got disconnected:



and then 2hrs later:



After the reconnect I noticed that my proxy was connected to 54.225.68.97:3333.
I don't know if it was the same IP before that. I'm guessing that it is possible that some of that pool's IPs  got affected but not all.

all times are GMT-7 - so it started at 07:10:43 UTC and reconnected at 07:16:43 - it lasted almost exactly 6 minutes. Although looking at when results started being rejected - that's almost exactly a minute earlier.

On the good side - this is going to be a pretty large block, so that gave me enough time for my score to restore to normal (in about an hour).

[autonomous42]

On the good side - this is going to be a pretty large block, so that gave me enough time for my score to restore to normal (in about an hour).

That's the thing, Slush's hop-resistant algorithm only really works well on short rounds. On occasion when we've had <5 minute rounds I can make a killing but there is nearly no difference in reward between a 2-hour round and a (soon-to-be) 6-hour round. Is that a small/medium miner thing, or can bigger miners corroborate? I get about 1.8 Gh/s between me and my buddy. On a PPS pool you get what you work for but here, because the score metric resets every so often, everyone is pretty much capped for any given round. At this 10.1M difficulty the highest reward on a single round I've gotten was .00576. Everything the same, a 6-hour round should absolutely pay better than a 1-hour. More work, more uptime, higher cost of running.

[sunriselad]

Thing is, besides the recent single block, it seems to be working fine for everyone else ... and that's a lot!

[vs3]

(...) Everything the same, a 6-hour round should absolutely pay better than a 1-hour. More work, more uptime, higher cost of running.

Why should it pay more? Whether it takes 24sec or 11hrs to find a block - at the end of the round it always brings exactly the same amount - 25BTC (currently).

Aside from that - I agree about the second part - shorter rounds are more profitable. But that's luck.

[Xanthon]

On the good side - this is going to be a pretty large block, so that gave me enough time for my score to restore to normal (in about an hour).

That's the thing, Slush's hop-resistant algorithm only really works well on short rounds. On occasion when we've had <5 minute rounds I can make a killing but there is nearly no difference in reward between a 2-hour round and a (soon-to-be) 6-hour round. Is that a small/medium miner thing, or can bigger miners corroborate? I get about 1.8 Gh/s between me and my buddy. On a PPS pool you get what you work for but here, because the score metric resets every so often, everyone is pretty much capped for any given round. At this 10.1M difficulty the highest reward on a single round I've gotten was .00576. Everything the same, a 6-hour round should absolutely pay better than a 1-hour. More work, more uptime, higher cost of running.

You need to know how block mining works.

It doesn't matter how long it took to find a block, a block will always contain ~25BTC. It's all about luck. Slush's score system even things out over time.

If it's proportionate returns you are looking for, you're at the wrong pool. The PPS system will suit you more.

[Resetif]

I already am mining on Slush's Pool 14 hours. Power 2200Mh\s. Why I do not calculate Namecoin?

Hi, under system statistics on Slush pool you have Bitcoin blocks and Namecoin blocks..you can look there for NMC,

give me a link - I do not see

[organofcorti]

It is no different for the pool - "you hit a getwork that returns 5 shares in the same 5sec - it looks like you have 5 times faster miner"

And when that happens for thousands of miners? They certainly don't get the same "luck".

Pool is 10Thps. Assume pool D = 1. That's 2328.306 D1 shares per second. Hashrate is averaged over 30 minutes, so that's ~ 2328.306 * 30 * 60 = 4190951 shares.

Use this page to calculate a 95% confidence interval, which results in  4186940.51 to 4194965.33 shares per half hour. That's about  +/- 0.1% variablilty with 95% confidence.

Let assume average pool D = 100 (ridiculously high, consider this an upper bound), so 2.328306 shares per second, and ~ 4190 shares per half hour. This bumps the variability up to +/- 3%.

To get anywhere near your 10Thps +/- 10% figure, the average pool D has to be about 1000. This has to be even higher as the hashrate increases.

tl;dr pool hashrate variability is not significantly affected by the luck of the individual miners.

[KNK]

I do not agree, but i do not want to argue, so i will just point that for normal distribution ( https://en.wikipedia.org/wiki/Normal_distribution ) after normalization, it doesn't matter if the difficulty is 1 or 10M - you have the same variance in % as you have the same standard deviation, only a different mean value

[ewitte]

API2 forwards me to stratum how do I force getwork with guiminer?  Having issues at work think they updated the firewall stratum doesn't seem to work for ANY pool need to move everything to the backup line but don't want to wait 3 days until I go back out.

[organofcorti]

I do not agree, but i do not want to argue, so i will just point that for normal distribution ( https://en.wikipedia.org/wiki/Normal_distribution ) after normalization, it doesn't matter if the difficulty is 1 or 10M - you have the same variance in % as you have the same standard deviation, only a different mean value

The expected number of shares in a given time period is not normally distributed,it's Poisson distributed, so normalisation matters - not that it's advisable to do this with a discrete probability distribution. Did you attempt to calculate results for yourself? I provided you with the link for that purpose.

You could try this too: http://organofcorti.blogspot.com/2012/10/71-variable-pool-difficulty.html

It's about pool difficulty, but you can see how it applies to this discussion.

tl;dr: The higher your hashrate : difficulty ratio, the lower your variance.

Edit: When you write "i do not want to argue" I read that as "I don't want to find out if I'm wrong or right". Come on - man up!

If you can convince me I'm wrong I'll happily admit it. That's how science works.

[KNK]

I do not want to clutter this thread and do not have much time for arguing. We are both pretty convinced in our statements, so it will not be quick and easy to make a switch in our opinions.
If you insist, please open a new thread for this and give me the link - i will post some personal observations to backup my point, but still afraid we will endup in agreeing to disagree.

[organofcorti]

I do not want to clutter this thread and do not have much time for arguing. We are both pretty convinced in our statements, so it will not be quick and easy to make a switch in our opinions.
If you insist, please open a new thread for this and give me the link - i will post some personal observations to backup my point, but still afraid we will endup in agreeing to disagree.

You haven't addressed any of my points and haven't a proof or hypothesis of your own, so no, I'm not going to start a thread.

We'll just have to agree that you're wrong and leave it at that