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

Keep calm. FB is probably just an extra means of information and a little bit of promotion. I think it's a good idea.

Not everyone has (or wants, or is going to set up) Facebook and/or Twitter accounts.

The main source of news for the pool should always be either [1] the pool website itself; or [2] this forum. Sure, FB and Ttr info can be added as a secondary source, but should never marginalize the main ones.

And if you start using facebook for updates and news, I would like to follow the pool on twitter. Maybe it is possible to open an account there as well. Just a wish 

Greetings

facebook page for recent updates and news? i hate facebook. i would rather get updates and news here pls

What does "high" mean? Is you miner connected to LP port? What miner do you use? Please post me a PM.

Edit: I re-checked LP mechanism and everything seems fine. Also all my rigs connected on the pool have pretty low stale ratio (~0.15%).

Is anyone else having high reject rates after you get a longpoll?

I needed some break from work on backends, so today I launched multilanguage support for website. Not all texts are currently translated, especially some emails, but I'll fix it during the time. Currently English, German, Russian and Czech translations are available. If you want pool site in your language and you want help me with it, let me know :-). I'm especially looking for some French or Spanish native speaker...


Yes, it's already on my list. However it will come after DGM.


Yes, this is part of DGM update which is planned in next days.

Slush:

If you get an opportunity, there are two requests for additional details on the website.
1: Can a date/time localization be added?
2: In the statistics page, can an additional field be populated showing the number of shares submitted for past blocks?

Thank you

CrunchyFerrett

As far as I remember, there were two noticable downtimes in last week, both because database maintenance. First was around 30 minutes, second exactly 10 minutes (crunchyferrett :-P). I don't think those two outages can affect overall hashrate in some significant way.

Well, that hashrate on the profile page is just an estimation; hashrate given by your miner will be much more exact. Actually as far as you don't see any connection issues in the miner, don't worry. Pool indicates accepted or rejected shares directly in getwork response, so all possible issues should be catched by your miner.

I've never seen that issue myself.  When I add up all my miners, it always equals what I see on my account page.  I use guiminer, not cgminer tho...

The hash rate shown on the account page has been consistently 20-25% below what my miner tells me it is, I never really gave it much thought. One or the other, or both, are wrong.

Is there any reason why my machine running cgminer (latest version) has my hash rate @ 760mh/s yet the average over the past few weeks has always been down around 550 on the slush pool page??

has the pool been suffering alot of down time? my end seems ok

This is a great pool!

Was EXACTLY 10 minutes by my watch. But who is counting?
:p

My appologies for recent downtime, it was database maintenance (second and final part). Downtime was less than 10 minutes.

That's because I was never asked

Shift-PPLNS is a method invented by DrHaribo of BitMinter which I then refined a bit. I've discussed it briefly in this comment as well as section "PPLNS variants" of AoBPMRS.

Shift here refers not to bit-shift, rather to worker shifts. Shares are grouped into shifts, and miners are rewarded for the shares they submitted in last few shifts rather than the last N shares. Since all shares submitted within a shift are equivalent, there's no need to store the individual shares, rather just the total shares submitted per miner per shift (or more accurately the total pB).

By using a gap of 1 shift between work and reward, it also doesn't matter (on average) whether a share is counted as belonging to one shift or the next. So this works in parallel - each pool instance tallies work per shift for the miners connected to it (because of the gap, it is ok to be a little out of sync with the other instances wrt which is the current shift) and then compute rewards after the fact with the summed data.

Shift-DGM is applying the same principles to DGM. I've never actually worked out the details (again, due to lack of interest), but it should work. The idea is that shares will decay only between shifts rather than within a shift, so you can do it in parallel with out-of-sync instances. Within a shift it's a simple tally of the total pB of shares submitted.

Could you explain how shift-PPLNS and shift-DGM work ? I have seen you use that expression before, but I have never seen you explain it. Are you refering to the version of DGM where the logarithms of the scores are used ?  Using 2 as a logarithm base, addition of exponents would be equivalent to binary shifting.

Can you have distributed DGM with per-node worker scores and "s" variable and then add all the nodes together later ?

PPLNS can work too, but there are a few differences to consider:
1. What most people refer to as PPLNS is the naive variant which isn't completely hopping-proof. There are correct variants but they're slightly harder to implement.
2. PPLNS is potentially more resource-intensive, as it requires a history of shares - DGM only strictly requires keeping track of the score of every miner.
3. DGM can absorb variance, which may or may not be needed or used but it's nice to have the option.
4. In DGM the decay is gradual rather than abrupt, this can be seen as a pro or a con depending on taste.

There's also shift-PPLNS and shift-DGM which work better with a parallel architecture.

OK, BTC payouts working again (I just sent batch of all pending payouts), I'm working on NMC now.

Edit: NMC payouts works as well.