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...
Topic: [4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool - page 1136. (Read 4382760 times)
January 03, 2011, 05:10:55 PM
January 03, 2011, 04:18:21 PM
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.
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.
January 03, 2011, 04:16:09 PM
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.
January 03, 2011, 10:39:22 AM
Some mighty fast blocks, eh?
How is this related to pool thread? Those blocks was not found by pool.
January 03, 2011, 10:19:47 AM
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?
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?
January 03, 2011, 07:19:08 AM
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.
January 03, 2011, 02:35:52 AM
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, did you check if all the shares are unique or if there are some stale/invalid shares?
January 01, 2011, 11:28:04 AM
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
January 01, 2011, 10:50:09 AM
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.
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.
December 31, 2010, 01:24:29 AM
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
December 30, 2010, 11:03:20 PM
Cool to know. Also, congratz, a block with just 83 shares xD
December 30, 2010, 06:31:40 PM
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.
(Thanks to amazing Nginx server I set up HA cluster without a second of outage, too :-).
Update: Memory problems fixed. Service was down for 10-15 minutes.
December 30, 2010, 06:16:06 PM
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.
December 30, 2010, 04:27:17 PM
it be nice to know what block the pool is currently working on.
OK, I added block# to stats page (in next release).
December 30, 2010, 03:05:21 PM
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). December 30, 2010, 02:51:52 PM
Another question for you. How many hashes are in a "share"?
December 30, 2010, 02:50:21 PM
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.
December 30, 2010, 05:18:15 AM
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.
Quote
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.
December 29, 2010, 08:10:59 PM
Slush, got two questions for you.
1) Could you update the System statistics page on bitcoin.cz to show the block we're currently working on as a group?
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?
I had 3.48 bitcoins when I woke up today! Thanks for the awesome work!
1) Could you update the System statistics page on bitcoin.cz to show the block we're currently working on as a group?
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?
I had 3.48 bitcoins when I woke up today! Thanks for the awesome work!
December 29, 2010, 03:39:09 PM
After adding diagnostics to cpuminer, I have gotten several 'getwork' failures with HTTP status code '502' when connecting to your mining pool:
What's their timestamps? 502 means service is temporary down. It happen time to time. Today it was because I had DDoS attack on server (another service, but server load was >30 for short time). I'm sorry for this, but re-submitting shares again in short period should solve it.
Jump to: