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

[slush]

Active workers (at least one share in last hour): 0

Yes, this and "connected: No" in hall of fame are known bugs. I'll fix it soon, now I'd like to finish long polling and related updates.

[1713979419]

1713979419

[1713979419]

1713979419

[1713979419]

1713979419

[1713979419]

1713979419

[1713979419]

1713979419

[urizane]

I'm not sure about the "connected: No" thing, but as far as the Active Workers count is concerned, it may have to do with something I've noticed.  I've seen that soon after a round ends, the workers on my account page show a last submitted share time typically far longer than when they actually submitted a share.  I haven't looked at it closely enough to determine if it's a time zone thing or not, but I have seen the my account page show last submitted times within the last 30 seconds, refresh the page 2 minutes later (consequently a new round begins during that time), and then it says the last submitted share is hours ago rather than 2 and a half minutes ago.  Just a thought as to why the active workers count (within the last hour) drops to zero when a new round begins.

[slush]

I'm not sure about the "connected: No" thing, but as far as the Active Workers count is concerned, it may have to do with something I've noticed.  I've seen that soon after a round ends, the workers on my account page show a last submitted share time typically far longer than when they actually submitted a share.  I haven't looked at it closely enough to determine if it's a time zone thing or not, but I have seen the my account page show last submitted times within the last 30 seconds, refresh the page 2 minutes later (consequently a new round begins during that time), and then it says the last submitted share is hours ago rather than 2 and a half minutes ago.  Just a thought as to why the active workers count (within the last hour) drops to zero when a new round begins.

Yes, all those bugs are related to single thing, to the update of "last submit timestamp" for each worker, which is currently incorrect (it is only correct immediately after processing the last block); I'll fix that, it just need little workaround. All this is because I optimized data structures for writing instead of for reading  (as there are tens or hundreds of writes per second, but only few readings), so reading exact timestamp for every worker cannot be so "cheap" in all cases. I have to do some postprocessing (denormalization) on the dataset to allow fast reading of them. But this bug does not affect mining core and calculating rewards in any case.

[Thndr]

I was just wondering if 70Mhash/s with a GPU is decent with a RadeonHD 5670, or if there could be things that would significantly improve it. Using poclbm-gui with "-v -w128 -f 120" as the options

[urizane]

70 Mhash/s seems quite reasonable at stock clocks.  From what I've seen, lowering the -f parameter should net you something, although very slight.  It will reduce desktop performance, however.  Maybe m0mchil's Python OpenCL miner thread would net you better answers.

[urizane]

Slush, I have an oddball question, just out of curiosity.  How much does a submitted share require you to store in a database?  Actually, I would just be interested in knowing how big of an effect that round of nearly 500,000 submitted shares really taxed the whole system when it was processed.  That sounds like a crazy task for the server to have to go through, especially if you have to commit on the order of 2kB per submitted share or something like that.  Umm...I guess that would be something like 1GB of random data spread across 500,000 entries, or something like that.  Maybe that's a little off, but it sure sounds like a mess.  Would a 4GB RAM drive help or am I way off?

[[Tycho]]

Slush, I have an oddball question, just out of curiosity.  How much does a submitted share require you to store in a database?  Actually, I would just be interested in knowing how big of an effect that round of nearly 500,000 submitted shares really taxed the whole system when it was processed.  That sounds like a crazy task for the server to have to go through, especially if you have to commit on the order of 2kB per submitted share or something like that.  Umm...I guess that would be something like 1GB of random data spread across 500,000 entries, or something like that.  Maybe that's a little off, but it sure sounds like a mess.  Would a 4GB RAM drive help or am I way off?

Server can just discard all the shares if they aren't suitable for current difficulty :)
Even if we want to store all the shares in inefficient JSON format, that would be ~25 Mb for 500 000.

[aistto]

What is the reason of decreasing BTC minig?
difficulty doesn't change. hash rate of pool increase, but my payment for each block down to 30-40% in last 2 days.
why?

[comboy]

What is the reason of decreasing BTC minig?
difficulty doesn't change. hash rate of pool increase, but my payment for each block down to 30-40% in last 2 days.
why?

Increased hash rate means your hash rate becomes smaller part of the whole hash rate. So more often blocks, but you get less from them. Better look at daily reward.

[slush]

Better look at daily reward.

...which will be also low for today, because we hit few extra long rounds.

Edit: Finally the day wasn't so bad, pool found 5 blocks in the row (firstly in history?) few minutes before midnight. Yes, that's the probability .

[demonofelru]

Hey Slush totally random question for you feel free to not answer if you want.  I see you are from Prague I have heard there is a pink tank or something there my friend told me about it have you ever seen this "pink tank"?

[slush]

Hey Slush totally random question for you feel free to not answer if you want.  I see you are from Prague I have heard there is a pink tank or something there my friend told me about it have you ever seen this "pink tank"?

Hehe, everybody in Czech knows Pink tank #23. But it isn't on Smíchov for more than 15 years, they removed it long before I came to Prague. So no, I never seen it .

Btw it was done by David Černý, a little controversal artist . I like also his Dead Horse which is hanging 20 meters from my office. Both artworks are tightly related to Czech history and mentality.

[demonofelru]

Oh so they took it down? I was planning on seeing if I ever got enough money for a vacation in europe.  Maybe I'll see the horse then instead.

[slush]

Oh so they took it down? I was planning on seeing if I ever got enough money for a vacation in europe.  Maybe I'll see the horse then instead.

It's in (I think military) museum, but I never been here.

[datathe1st]

Slush, last night my account showed 9.9 BTC confirmed and unconfirmed.  Now it shows only 9.34

How is this possible?


Also last night I had around 0.6 BTC confirmed.  Now it is 0.00358097 BTC


What is going on?  



I think I get it.  Once paid out they get removed from my confirmed amount.  Ahh.  Sorry about that


Ooookay new problem - Problem communicating with bitcoin RPC...

[aistto]

What is the reason of decreasing BTC minig?
difficulty doesn't change. hash rate of pool increase, but my payment for each block down to 30-40% in last 2 days.
why?

Increased hash rate means your hash rate becomes smaller part of the whole hash rate. So more often blocks, but you get less from them. Better look at daily reward.

daily reward less than ever before...


slush gave answer

...which will be also low for today, because we hit few extra long rounds.

[dacoinminster]

It would be sweet to see GHash/Second in the hall of fame.

# Blocks found weights the hall toward people who have been mining for longer.

[SmokeTooMuch]

hm why is the site offline ?

edit: nevermind.

[marcus_of_augustus]

Slush, now that your pool shares are heavily weighted to those found late in the round what is to stop miners cheating by joining late in the round to cash in on all the easy money then?

By this, I mean that they only join your pool when a round has already gone on for longer than the average time for your pool to find a block. So at present they join your pool after ~50 mins into the round, and at other times go solo or with one of the "equal" share pool.

[Dude65535]

A round that has been running for a long time has no better odds of finding a block in the given time period than a new round would.