Topic: [4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool - page 1130. (Read 4381920 times)

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 .

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.

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. :/

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.

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

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

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

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 ;-).

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.

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.


 
 

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

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

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.

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.


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

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.

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?

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.

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

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.

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.


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 .

Thanks for answering my questions.


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.

Oh, thanks gene for explanation. I'll consider startssl certificate again.