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

xenon481

sr. member

Activity: 406

Merit: 250

It looks like the lower average block reward is because there are more people solving more blocks more quickly. This should keep your average daily reward the same as before, but your reward from each block will be lower.

Notice that there are almost 900 workers attached when just three days ago there were only ~650 workers attached.

My average block reward has been lower today as well, but this was also my best day for total reward.

Edit:

Quote from: FairUser on February 17, 2011, 07:08:22 PM

How many other people saw "None" for their Payments on the following rounds/blocks?

# Block found Duration Total shares Your reward Block #
1207   2011-02-17 23:46:14   0:00:58   682     none     108812
1206   2011-02-17 23:45:16   0:00:20   178     none     108811

I should have at least seen something on the 1207 round...but didn't. Using a regular miner with a askrate of 5.

I did get a share of 1206 and ended up getting ~0.2575 BTC from it. All that means is that your miner didn't find any shares (solutions at an easier difficulty) within those 20 and 58 seconds that it took to solve those blocks.

theGECK

sr. member

Activity: 411

Merit: 250

Each block was found by a solitary miner in the pool before any other miners could get their work back to the server. But I would like to find out why this would happen as well - I'm seeing a much wider range between minimum and maximum payout on the blocks that I am a part of, and more blocks solved with no shares. If many of us are seeing this, it probably isn't luck, and it might be an issue with the update and how things are calculated.

FairUser

sr. member

Activity: 1344

Merit: 264

bit.ly/3QXp3oh | Ultimate Launchpad on TON

How many other people saw "None" for their Payments on the following rounds/blocks?

# Block found Duration Total shares Your reward Block #
1207   2011-02-17 23:46:14   0:00:58   682     none     108812
1206   2011-02-17 23:45:16   0:00:20   178     none     108811

I should have at least seen something on the 1207 round...but didn't. Using a regular miner with a askrate of 5.

[Tycho]

hero member

Activity: 742

Merit: 500

I'm crunching at ~800 Mh/s and everything was fine until this update.
Now 9 blocks already found by pool and i'm getting about 50% of my normal reward, i don't think it's just a random fluctiation - my progress rate was perfectly straight for previous two days.
It was ok to make donations mandatory, it was ok to delay stats by 2 hours and hide everything, but taking 50% off is certainly not ok for me. I can't even guess now if someone got those BTCs instead of me, or they go directly to pool's owner Sad

slush

legendary

Activity: 1386

Merit: 1097

Quote from: spacediver on February 17, 2011, 06:38:55 PM

I've too got 0E-8 reward (instead of "none") for once, maybe it should be bugreported hereby.

That's not a real "bug", it is just another notation of "zero"

. But you are right, it should display normal number.

spacediver

newbie

Activity: 27

Merit: 0

Greetings everyone miners,
Thanks slush for the great work,

I've too got 0E-8 reward (instead of "none") for once, maybe it should be bugreported hereby.

Yes, lowering estimated reward from f5 to f5 is rather depressing thing to see Wink

, though, waiting for my first mined BTcent to be sent, I have a question/suggestion: would it be reasonable to keep all three a) confirmed b) sent c) total reward values in account profile?...

Thanks again.

myrkul

hero member

Activity: 532

Merit: 500

FIAT LIBERTAS RVAT CAELVM

Is there a point to cpu mining anymore? I thought the idea was to normalize luck over time into a steady trickle.

Now, we're back to luck, since you have to submit your share very close to the solution to get anything.

sadface. Sad

slush

legendary

Activity: 1386

Merit: 1097

Yes, the problem is on the server. I'm solving it, hope it will be better in few minutes.

theGECK

sr. member

Activity: 411

Merit: 250

Ricochet, I have the same setup as you with the miners, and noticed the same thing. The disconnection only lasts for a few seconds, and the message typically says "Problems communicating with bitcoin RPC". It just appeared as I was writing it, so you can use the timestamp on this post to search for any errors or problems, if needed.

Ricochet

sr. member

Activity: 373

Merit: 250

I'm having an odd issue. About once every 2-3 minutes, both of my miners lose the connection to the pool, to reconnect a few seconds later. I don't think it's my Internet connection because I pinged Google continuously during these periods with no packet loss. Pinging http://mining.bitcoin.cz at the same time yields a tiny bit of packet loss and extra delay.

Are there bandwidth issues going on or perhaps should I test more diagnostics on my end? I'm using both m0mchil's GPU miner and ufasoft's SSE2 miner (1 thread) at the same time.

EDIT: Also, if this keeps happening, does that count as a disconnect for the new scoring system? In other words, if this happens every 3 minutes, will every share I contribute count as an "early" share?

bobR

member

Activity: 112

Merit: 10

Quote from: slush on February 17, 2011, 03:49:37 PM

Quote from: bobR on February 17, 2011, 03:45:08 PM

the pay out was so low I spent more on electric
penalizing early shares is not the way to go

...said bobR after three rounds of (probably) bad luck.

(But if you mine using CPU, you are probably right. The electricity cost more than you mine. It is just the nice way how to get your first bitcoins to play with - except Bitcoin Faucet).

maybe it was just luck but 0E-8 pay out sheesh
I don't mind getting a fraction
but thats one step above ZERO

slush

legendary

Activity: 1386

Merit: 1097

I just added some caching of stats on site, because some people like stats too much that they keep their fingers on "F5" key :-). Graphs and hall of fame are generated every hour, stats page is cached for 30 seconds. Profile page is not cached (yet).

pla

member

Activity: 65

Merit: 10

Quote from: bobR on February 17, 2011, 03:45:08 PM

penalizing early shares is not the way to go

They don't get "penalized" - They have no value at all until the pool solves the block. The estimated value means just that, an estimate of what you'd get if the pool solved the block immediately afterward.

Without knowing exactly when the pool will next hit, you can't know an accurate value-per-share. And you can't know exactly when the pool will next hit, sooo...

xenon481

sr. member

Activity: 406

Merit: 250

Quote from: bobR on February 17, 2011, 03:45:08 PM

With the last round I may as well quit
the pay out was so low I spent more on electric

penalizing early shares is not the way to go

Did you not look at the metrics and charts that showed that it averaged out over time?

Edit: Thank you very much, Slush. The amount of analysis you did on this was amazing.

slush

legendary

Activity: 1386

Merit: 1097

Quote from: bobR on February 17, 2011, 03:45:08 PM

the pay out was so low I spent more on electric
penalizing early shares is not the way to go

...said bobR after three rounds of (probably) bad luck.

(But if you mine using CPU, you are probably right. The electricity cost more than you mine. It is just the nice way how to get your first bitcoins to play with - except Bitcoin Faucet).

bobR

member

Activity: 112

Merit: 10

With the last round I may as well quit
the pay out was so low I spent more on electric

penalizing early shares is not the way to go

slush

legendary

Activity: 1386

Merit: 1097

Quote from: hatboyzero on February 17, 2011, 03:09:23 PM

I think there might be an overflow error with the scoring... Look at the total score in the following vs. the contributed shares and CFD...

Well, this is not a bug, this is feature :-). I didn't want to complicate the stuff with score based system in the introduction, but as you are asking...

Using exp(round_time/C) can lead to extremely high numbers. Such big that with many workers and extremely bad pool luck, it may overflow somewhere. So in reality, the score based system is implemented with one optimization, that was not explained yesterday:

The real formula isnt score += exp(round_time/C), but:

Code:

duration = min(round_time, hour_time)
score += exp(duration/C)

where round_time is count of seconds from round beginning and hour_time is count of seconds in current hour.

And every hour, exactly at 0 minute, 0 second +- 50 miliseconds, I'm performing "renormalization". This means that all worker scores are divided by exp(min(3600, round_time)/C).

This has NO IMPACT on score system itself, but helps handling huge numbers in application. So your observation was absolutely correct, because every hour the system score drop to very low number.

Mythoranium

newbie

Activity: 31

Merit: 0

Quote from: slush on February 17, 2011, 11:19:33 AM

Quote from: Mythoranium on February 17, 2011, 08:45:57 AM

The website says that you need a separate user/pass for every worker. What would happen if one would ignore that?

On the server side, every worker has queue of 12 last jobs (by default), which are needed to verify submitted jobs by worker. If you submit a share, but the job was already deleted on the server (by asking 12 next jobs from server in meantime), the share won't be accepted. So, if you're mining only by CPUs, you probably don't need separate workers, as CPU miners does not need such high number of parallel jobs. But I still recommend to use workers - it is easier to track miner problems and you don't need to investigate how much jobs is your worker asking (it does not need to correspond with number of CPU cores). If you are GPU miner, you should definitely use separate workers to not losing shares.

Thanks, slush! That is exactly what I needed to know!

hatboyzero

newbie

Activity: 1

Merit: 0

I think there might be an overflow error with the scoring... Look at the total score in the following vs. the contributed shares and CFD...

Current round started at: 2011-02-17 18:44:29 UTC
Current round duration: 1:16:43
Current shares CFD: 92.30 %
Current Bitcoin block#: 108777
Current server load: 300 getwork/s
Active workers: 877
Total score of current round: 5354.9010
Shares contributed ": 66660
Approx. cluster perf: 60.268 Ghash/s

Ricochet

sr. member

Activity: 373

Merit: 250

That happened with the old scoring system as well, just perhaps not to quite as strong a degree. At least the estimated reward field is back to begin with, heh.

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