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

[dooglus]

Thanks for answering my questions.

it is performance optimization, because it's not possible to ask databaase 100x per second to check worker's login/password. So I plan to add periodic reload of those credentials, but even then it will take some time until credentials loaded in memory expire...

Perhaps it would be better to update the in-memory credentials for just that worker at the same time as you update the password in the database.  Then you don't need the periodic reload.

By the way, I looked at your location on the bitcoin map as you suggested.  I used to stand right there regularly waiting for the tramvaj home to Strasnicka.  But now I'm living in Canada, so coming to "pay you a visit" for being "a scammer" isn't really an option.  I don't think the 0.002 BTC you "owe me" would pay for the plane ticket.  Yet.

Chris.

[1713557554]

1713557554

[1713557554]

1713557554

[1713557554]

1713557554

[1713557554]

1713557554

[1713557554]

1713557554

[slush]

Perhaps it would be better to update the in-memory credentials for just that worker at the same time as you update the password in the database.  Then you don't need the periodic reload.

Not so easy. getwork processes are completely independent from website itself. Implement credential timeouts in getwork processes is the simplest way to do it. I still hope it will be enough.

By the way, I looked at your location on the bitcoin map as you suggested.  I used to stand right there regularly waiting for the tramvaj home to Strasnicka.

Yes, Vodickova street is quite good address, it is in the heart of Prague itself . Maybe after few months, you spend only 1BTC for ticket Canada-Prague, we will see .

[BitterTea]

No, when miner report 'found block', it is only found pool share (block with difficulty 1). You have to check website, if you workers have some number in 'blocks' column.

Dang... I'm writing a wrapper app for some Bitcoin stuff (multiple wallets, encryption, backups, pool mining) and I'm parsing out the output to determine hash rate, accepted/rejected etc. I was hoping to be able to keep track of number of blocks found, but oh well.

[slush]

Dang... I'm writing a wrapper app for some Bitcoin stuff (multiple wallets, encryption, backups, pool mining) and I'm parsing out the output to determine hash rate, accepted/rejected etc. I was hoping to be able to keep track of number of blocks found, but oh well.

Well, I can provide some API to retrieve info about user account (with provided login/password, of course). PM me if you are interested.

[tryptamine]

Looks like the pool doesn't take into account partially solved shares. This leads to some inconsistencies (and unfairness), specially when total shares are low, but it's increasingly noticeable as the cluster grows in performance, because there are more chances of not completing a share before the cluster finds a block.

In my case, the cluster has been steadily at around 14-15000mh/s, and I usually get around 0.40BTC per block. On blocks found in a short time this varies a lot: from 0.25BTC to 0.80BTC if I completed a share just after or before, respectively, than most of the miners in the cluster.

I don't know if this is solvable somehow, I use a GPU and the variation tends to even out, but CPU miners are clearly at disadvantage and eventually GPU miners will be affected if the cluster grows large enough.

[BitLex]

what exactly does partially solved share mean?
you either find a winning-hash (equally to solve a block at difficulty 1) and get a share, or you don't.
what kind of partially work is there to take into account?

[davout]

Looks like the pool doesn't take into account partially solved shares. This leads to some inconsistencies (and unfairness), specially when total shares are low, but it's increasingly noticeable as the cluster grows in performance, because there are more chances of not completing a share before the cluster finds a block.

In my case, the cluster has been steadily at around 14-15000mh/s, and I usually get around 0.40BTC per block. On blocks found in a short time this varies a lot: from 0.25BTC to 0.80BTC if I completed a share just after or before, respectively, than most of the miners in the cluster.

I don't know if this is solvable somehow, I use a GPU and the variation tends to even out, but CPU miners are clearly at disadvantage and eventually GPU miners will be affected if the cluster grows large enough.

There's no such thing as a partially completed share... If you're mining at 10 khash/s you're basically playing lottery 10,000 times per second.

[tryptamine]

what exactly does partially solved share mean?
you either find a winning-hash (equally to solve a block at difficulty 1) and get a share, or you don't.
what kind of partially work is there to take into account?

It takes time to get a share, partially means crunching numbers and not getting it before a block is found. That work is discarded and not taken into account.

There's no such thing as a partially completed share... If you're mining at 10 khash/s you're basically playing lottery 10,000 times per second.

That's true mining solo, coop mining you get paid proportionally to your shares.

[fabianhjr]

If you didn't got a share then the next round is more likely to have the share there at the beginning. slush's pool is just easier to get smaller more constant payments.

[davout]

It takes time to get a share, partially means crunching numbers and not getting it before a block is found. That work is discarded and not taken into account.

Well, but if you account for the shares you get just before a block is found it statistically evens out.

There's no such thing as a partially completed share... If you're mining at 10 khash/s you're basically playing lottery 10,000 times per second.

That's true mining solo, coop mining you get paid proportionally to your shares.
[/quote]
Share = easy block, it is the exact same

[cdb000]

Ok, after some messing about, I have 5 5870s in the pool, 4 running at 982MHz, the last running at 980MHz, a total of about 1800 Mhash/sec.

 Experience gained so far:

 32 bit XP doesn't seem happy with more than one 5870. When I managed to get a 2nd 5870 enabled the system because very flakey. It runs a single 5870 with minimal CPU use.
 64 bit XP seems OK with 2 5870s, using minimal CPU to drive them.
 32 bit Win7 seems OK with 2 5870s, but each instance of poclbm.exe uses 100% of a core, so a quadcore with 2 5870s has the CPU 50% busy all the time.

 In the next couple of days I will set out to discover whether 64 bit XP can drive 3 5870s... a problem here might be finding tools to allow clocks to be set for 3 cards in one machine.

 A 5870 running in a PCIe x1 slot seems to be just as fast as one running in a PCIe x16 slot.

 Cheap 5870s are just as fast as expensive ones, but a lot noisier.
 Expensive 5870s are quiet enough to run in the living room where the heat generated does some good.
 Cheap ones need to be in the garage where the noise isn't such an irritation.


 
 

[slush]

Today I implemented new pool features.

1. User's daily reward graph
After login, every user can check his daily reward and his seven days moving average. Everybody can visually check if daily rewards are adequate his hash rate.

2. System daily reward graph
Shows how many bitcoins pool mined every day.

3. Cummulative distribution function of shares
Shows generally overall pool success rate. Blue line shows long-term teoretical share distribution, yellow line is pool reality. Yellow above blue ==> pool is more successful than it should be, yellow under blue ==> otherwise. From collected data you see that currently pool perform little better than it should be in long-term, so hard blocks (with many shares in round) will come, surely :-). Show CDF for pool users was the main goal of this release.

CDF is not calculated from entire pool history, because system has correct data from block 101165 up to now.

Page with graphs is here.

4. Hall of fame
Added page with the most powerfull miners in pool (actually top20). It is stub for another interesting user stats, I hope.

5. Total rewards on profile page
Few users asked me to add unconfirmed+confirmed rewards together to profile page. Personally I don't see much the point, because unconfirmed reward is something what you shouldn't count in (yes, we already had invalid block in pool).

And in the end, my personal appeal to coldbot: Stop pressing F5 for hours and let's do something useful. There won't happen anything magical in your profile page when you download it 10x per second.

[slush]

I'll restrain my twitchy finger, promise. ;-) But please google 'jquery comet'.

I considered something like this, but data are changing with every submitted shares (expected reward, for example). And I'm working on mining server, not on news distribution. When you check profile page every half of hour, you don't miss anything ;-).

[fabianhjr]

I am getting again +80% invalid or stale hashes. Why does this happens?

[slush]

I am getting again +80% invalid or stale hashes. Why does this happens?

Do you have overclocked GPU? Try to lower clock a bit.

Do you use newest miner software? Old versions had troubles sometimes...

[Cdecker]

I'll restrain my twitchy finger, promise. ;-) But please google 'jquery comet'.

I considered something like this, but data are changing with every submitted shares (expected reward, for example). And I'm working on mining server, not on news distribution. When you check profile page every half of hour, you don't miss anything ;-).

The other way is to cache the values in the profile page so only the first hit will actually show something new and the underlying data provider isn't feeling additional load from reloads. Just put a caching timeout of 1-2 minutes.

[fabianhjr]

I am at the newest and it is clocked at stock. As of the version I am sure I have the latest one. This had happened some times before and occurs/fixes magically and randomly. :/

[slush]

I am at the newest and it is clocked at stock. As of the version I am sure I have the latest one. This had happened some times before and occurs/fixes magically and randomly. :/

Well, I'm not a specialist for mining software, but there can be tons of reasons. Enabled crossfire, bad driver version or so. Please ask on #bitcoin-mining or #bitcoin-dev for help.

[slush]

The other way is to cache the values in the profile page so only the first hit will actually show something new and the underlying data provider isn't feeling additional load from reloads. Just put a caching timeout of 1-2 minutes.

Far easiest way is not reload page 10x per second . Site with it's 500 registered users is not big enough and doesn't need any caching layer yet. As I'm working on big sites with many caching layers in my job, I'm enjoying that I see fresh data on every refresh on pool site now .

[zoidial]

Sorry for the "me too!" response, but I also have >80-90% "invalid or stale" on two different computers and two different GPU's (nvidia and ATI) using m0mchil's miner -

this started happening an hour and a half ago, coinciding with slush's update post.  (in case that helps, or is just a terrible coincidence)   

Did some behavior change with this update?  Or is this not related at all?  I don't know enough more, just wanted to throw this out there just in case something is wrong.