[150+ PH] SlushPool (slushpool.com); World's First Mining Pool

[slush]

1) Could you update the System statistics page on bitcoin.cz to show the block we're currently working on as a group?

What specific stats about current block are you missing? Block history table is, ehrm, block _history_. Operational stats are above. Btw next block number is in my opinion non-relevant for pool stats.

2) If the current block is 100,084 and it is solved by someone else, the next network block would be 100,085.  Does that information get updated with the group or are we all still crunching away @ block 100,084?

Of course miners have up to date information. Miners are asking pool approximately every 5 seconds for new job to crunch.

[1498616771]

1498616771

[1498616771]

1498616771

[1498616771]

1498616771

[1498616771]

1498616771

[FairUser]

1) Could you update the System statistics page on bitcoin.cz to show the block we're currently working on as a group?

What specific stats about current block are you missing? Block history table is, ehrm, block _history_. Operational stats are above. Btw next block number is in my opinion non-relevant for pool stats.

I'm not doubting you, but I noticed a few days ago that *after* the pool got a block, that my bitcoin client didn't get an update that the block was solved for ~4-5 minutes.  I'm just wondering if the opposite could also happen, hence, it be nice to know what block the pool is currently working on.

2) If the current block is 100,084 and it is solved by someone else, the next network block would be 100,085.  Does that information get updated with the group or are we all still crunching away @ block 100,084?

Of course miners have up to date information. Miners are asking pool approximately every 5 seconds for new job to crunch.

I thought so, but I just wanted to be sure. 

[FairUser]

Another question for you.  How many hashes are in a "share"?

[Raulo]

Another question for you.  How many hashes are in a "share"?

2^32=4294967296. A share is a solved block with "difficulty of at least 1 but less than current difficulty (which will earn the pool a block).

[slush]

it be nice to know what block the pool is currently working on.

OK, I added block# to stats page (in next release).

[FairUser]

it be nice to know what block the pool is currently working on.

OK, I added block# to stats page (in next release).

Thank you very much!
Expect donations soon.

[slush]

I just set up high availability application cluster on the server. That means I will be able to upgrade application without any service outage.

(Thanks to amazing Nginx server I set up HA cluster without a second of outage, too :-).

Update: Huh, pool is currently down because of DB memory problems. Sorry for troubles, I'm working on it. That's Murphy law; first real pool outage few minutes after announcement of stability improvements :-).
Update: Memory problems fixed. Service was down for 10-15 minutes.

[fabianhjr]

Cool to know. Also, congratz, a block with just 83 shares xD

[ColdHardMetal]

Cool to know. Also, congratz, a block with just 83 shares xD

That was pretty sick. A new record lol. Beats the previous of 188 I think it was.

 I checked my time stamps and I didn't catch a piece of it unfortunately 

[slush]

I'm going to do a system kernel update. Service will be down for few minutes.

If your miner won't reconnect automatically after then, please update to newest miner version. If you already have newest version and have troubles with miner stability, please ask developers.

[britschler]

If you are user of jgarzik's CPU miner, try also new 'cryptopp_asm32' algorithm. It is working well now and improve performance for many users (hashrate is same or better than in official bitcoin client). Thanks jgarzik!

Yes, changing the algorithm gave me a huge boost:

4way:
HashMeter(0): 16777216 hashes, 291.09 khash/sec
HashMeter(1): 16777216 hashes, 284.03 khash/sec
HashMeter(2): 16777216 hashes, 280.10 khash/sec
HashMeter(3): 16777216 hashes, 278.72 khash/sec

cryptopp:
HashMeter(0): 16777216 hashes, 446.86 khash/sec
HashMeter(1): 16777216 hashes, 434.61 khash/sec
HashMeter(2): 16777216 hashes, 419.85 khash/sec
HashMeter(3): 16777216 hashes, 417.87 khash/sec

[Raulo]

We have new difficulty and the pool has completed 66 blocks since the last change in difficulty. However, with the total number of shares completed (1167791), it should have resulted in 78.65 blocks on average. This might be due to bad luck (Poisson distribution gives about 8% probability of such an outcome) but before the last difficulty change, there were also less blocks than one should expect (see post #312). Such a bad luck twice in a row is rather suspicious. I am wondering (and worrying) if something is (slightly) wrong with the pool server and if some work is duplicated.

Slush, did you check if all the shares are unique or if there are some stale/invalid shares?

[slush]

I am wondering (and worrying) if something is (slightly) wrong with the pool server and if some work is duplicated. Slush, did you check if all the shares are unique or if there are some stale/invalid shares?

I know about this disbalance, too. I'm logging _all_ shares for few days ago (actually it is 355303 logged shares) and I'm working on uncovering possible problems. This can be still explained by probability and luck, but I want to be sure there is nothing bad behind those numbers.

To your question - yes, all shares are unique, except few re-submitted from miners when pool was unstable (yes, sometimes is database overloaded; I'll move pool to standalone server soon to avoid interferences with another services). But those re-submitted shares was not count twice.

So let me play with gathered shares, I'll try to find any possible problems here. I'm also interested, if there is anybody else with large hashing power to ask him if their miners have correct probability distribution.

I'll also publish share logs soon to allow other people to review share stats by self.

[FreddyFender]

278 seconds to find block 100810
9 seconds to find block 100809
52 seconds to find block 100808
88 seconds to find block 100807
342 seconds to find block 100806

Are the cartels onto something here or is this an anomaly?

Some mighty fast blocks, eh?

[slush]

Some mighty fast blocks, eh?

How is this related to pool thread? Those blocks was not found by pool.

[FairUser]

I am wondering (and worrying) if something is (slightly) wrong with the pool server and if some work is duplicated. Slush, did you check if all the shares are unique or if there are some stale/invalid shares?

I know about this disbalance, too. I'm logging _all_ shares for few days ago (actually it is 355303 logged shares) and I'm working on uncovering possible problems. This can be still explained by probability and luck, but I want to be sure there is nothing bad behind those numbers.

To your question - yes, all shares are unique, except few re-submitted from miners when pool was unstable (yes, sometimes is database overloaded; I'll move pool to standalone server soon to avoid interferences with another services). But those re-submitted shares was not count twice.

So let me play with gathered shares, I'll try to find any possible problems here. I'm also interested, if there is anybody else with large hashing power to ask him if their miners have correct probability distribution.

I'll also publish share logs soon to allow other people to review share stats by self.

Just FYI, found these in my log:

02/01/2011 11:01, 49fd10bf, invalid or stale
02/01/2011 11:01, 0d157919, invalid or stale
02/01/2011 12:21, 493e637c, invalid or stale
02/01/2011 16:07, 6d716d59, invalid or stale
02/01/2011 16:07, 293de62e, invalid or stale
02/01/2011 16:10, 751cdf81, invalid or stale
02/01/2011 16:11, 4dc33d31, invalid or stale
02/01/2011 17:13, 5f8cf672, invalid or stale
02/01/2011 17:13, 7e306be7, invalid or stale
02/01/2011 19:00, 4603c922, invalid or stale
02/01/2011 19:01, 469d4616, invalid or stale

Hope this information helps you out somehow.

[FairUser]

Literally just had this show up:

2011-01-03 21:16:03 Found Hash!
Sending to server: {"method":"getwork","params":["00000001cca6575b326247fd9b8aa8
77735d86fb4b7eab51838297660003f7ef00000000f1bdf21a7dca2de2139aa60dae0877c3b2e31 9
f3be6b9c8a346f69251500b1ea4d223c561b0404cb16ae4de900000080000000000000000000000 0
000000000000000000000000000000000000000000000000000000000080020000"],"id":1}
Retrying
Retrying
Retrying
Retrying
Retrying
Error while sending found block to server!
27242 khash/s
2011-01-03 21:16:06 Found Hash!
One or more of the blocks you are working on is stale.
You or the server might be having connection issues.
27931 khash/s
2011-01-03 21:16:23 Found Hash!
One or more of the blocks you are working on is stale.
You or the server might be having connection issues.
27976 khash/s

Now, I know you're working on the server right now, but wouldn't that just be our luck that I find another block (already found 2 blocks in the last week for the server!) and it doesn't get reported?

Do you think that could be the case?
While a "Block" get you 50 BTC when you find it (or the Pooled mining gets it in this case)....so when I see the word "BLOCK", I think 50bitcoins...
Or did puppinpop call all these "blocks" instead of "meta-hashes" or "mini-blocks", which helps confuse the crap out of everyone...IMO.

[Poincare]

 I'm running miners on 18 machines at the moment, each connecting directly to slush's server. 15 are even at the same location. Does the number of connections matter for the performance? If so, maybe we should find a way to proxy the minders? It could give a count of my total M or k hash/s :-)

And off course I'm continously refreshing the Statistics and My bitcoin page. I'm probably not the only one...

[FairUser]

I'm running miners on 18 machines at the moment, each connecting directly to slush's server. 15 are even at the same location. Does the number of connections matter for the performance? If so, maybe we should find a way to proxy the minders? It could give a count of my total M or k hash/s :-)

And off course I'm continously refreshing the Statistics and My bitcoin page. I'm probably not the only one...

I do not know the answer to your question....but...
I ran 64 *CPU* instances on Amazon's EC2 cluster...and it did VERY, VERY little work compared to a decent ATI Video card.
As a matter of fact, I'm going out and building a new box today with a couple ATI cards.

Just FYI...if you're using CPU....save your money, or sell some hardware, and get more GPU's.


 

[slush]

Hope this information helps you out somehow.

Yep, it is because server is overloaded. I'll move pool to standalone server, because it is pointless to tune Drupals, Joomlas and other stuff lying on current server to not interfere with pool...