Today I had a hour and half long round end up invalid so it's not such a huge deal but I have also seen a 4 hour long round going invalid. That's a good chunk of the day gone bad.
I'm not complaining, I just want to know what happens and why a round ends up invalid and what is the justification of it?
Though 253746 is showing invalid on the Pool page, it is valid for Slush on Blockchain. Happening a lot lately -- must be a bug in the server code. |
|
|
|
|
Hmmm, looks like it's almost time to take a break while waiting for the BFL 60 -- or at least get a Raspberry hooked up. Profitability after energy cost on my FPGAs is down to a couple bucks a day.
|
|
|
|
|
19695 2013-08-20 16:36:14 2:42:38 83893598 11780 0.00344829 253220 25.20305002 invalid
Shows relayed by Slush and valid on Main Chain -- fix plz. Any idea why the pool servers are starting to throw these errors?
|
|
|
|
Now it appears that they are both confirmed instead of invalid. Why tese happens, again two in a row ?
19682 2013-08-19 22:47:11 2:19:51 71506708 208054 0.06592060 253091 25.37953223 invalid
19681 2013-08-19 20:27:20 2:21:40 71930298 210595 0.07538372 253075 25.28987285 invalid
Hopefully Slush will do some troubleshooting. Both of these blocks showing valid on main chain. Stealth Slush  |
|
|
|
Why tese happens, again two in a row ?
19682 2013-08-19 22:47:11 2:19:51 71506708 208054 0.06592060 253091 25.37953223 invalid
19681 2013-08-19 20:27:20 2:21:40 71930298 210595 0.07538372 253075 25.28987285 invalid
Hopefully Slush will do some troubleshooting. Both of these blocks showing valid on main chain. |
|
|
|
2 invalid blocks in a row  19659 2013-08-18 00:43:31 0:24:25 12918777 3385 0.00626088 252722 25.00000000 invalid 19658 2013-08-18 00:19:06 0:41:44 21756147 5705 0.00652499 252730 25.44870012 invalid 252730 is reported as valid on Blockchain and attributed to Slush. Hopefully Slush will fix this one. The 252722 is defo a weird late one, and not found on Blockchain. |
|
|
|
I have reached and passed by payout threshold but didn't get paid this time around. Anyone else having issues with payout?
I seem to be in the same boat. I decided to temporarily suspend mining and zero my account at Slush, so did the following steps: - increased the payout threshold to a value higher than total reward (i.e. confirmed + unconfirmed) - stopped all miners - waited till all reward bacame confirmed - waited some more - decreased the payout threshold to a value below the current total (==confirmed) reward. The automatic payment was executed some time later, but I do not see this transaction in my bitcoin-qt. I will try to rescan the transaction chain before bothering Slush with it. Can't remember for sure, but I think the payments are sent without a transaction fee -- if true, it can take some time for it to be picked up in a block. I've seen 24+ hour transactions on Blockchain. |
|
|
|
I'm wondering. we have a run of bad luck and people leave for greener pastures. Our hashrate settles down and our luck starts improving. People see our luck improve and come back. Gradually increasing hashrate continues to feed good luck. Eventually, hashrate gets as big as it is going to get. Luck starts to equalize. People consider a little bad luck to be an indicator and start moving away. Gradually decreasing hashrate manifests the appearance of a run of bad luck until we are back to the normal lower rate. Luck eventually stabilizes and repeat.  Sure does seem that way. |
|
|
|
|
14+ hours doesn't mean the pool is broken -- look at the network stats: Slush at 24.3 THash is only 4% of network. The ASIC's are definitely arriving.
|
|
|
|
This is also affected by increases in our Hashrate. If our hashrate goes up your return will go down. But, it should be offset by increasing the number of blocks we find. You really can't tell much looking at each individual block, your graph 7 day average is a better indicater.
OK, so you're saying it was a coincidence that this hashrate increase, at the apex of my going from >expected to <expected happened while my miners were having a nap. I wonder what the odds are. How does the hashrate relate to the shares per block being different? I can't see how that works. If the pool hash rate stays the same while the network hash rate increases, the pool's chance of finding a block decreases, i.e., it will take longer on average for the pool to find a block. Similarly, if the pool hash rate is increasing while the network hash rate stays the same, the pool's chance of finding a block increases, resulting in shorter round times. Now, if your hash rate stays the same while the pool's hash rate increases, your share of the pot decreases because your payout is based in part on your_shares_submitted_during_round divided by pool_shares_submitted_during_round. Your lower payout will be offset a bit if the pool has an increasing hash rate because the pool will find on average, more blocks. |
|
|
|
|
I think slush gotta add another server or two to keep up with 23+ Thash for the pool and increasing competition on the network.
|
|
|
|
What is going on? Can't connect to the pool. Workers that are already connected are fine, but if you disconnect, you won't be able to connect again!
If you're using cgminer (might work with other apps), try starting it 3-4 times as fast as you can click -- usually one of the instances will link up, then just kill the ones that didn't. |
|
|
|
I've joined with single 7850 GPU and making 0.01 BTC a day which isn't bad. There were two minor incidents that I'd like an answer to.
First, yesterday I heard my GPU cranking really loud and upon inspection I was getting several hundred stale (connections?) in GUIMiner. At this time my account showed 0 hash rate. So I restarted my miner and everything came back to normal. I'd like to understand what happened there and what I can do to avoid it or possibly burning out my GPU.
Second, today everything was humming along and at the end of my work day I checked my account and it sowed last share 7 hours ago. I don't think I had made any contribution during this time. However my GUIMiner was clicking just normal showing 352 MH/S - In statistics, I have no shares from 19195 to 19199 while GUIMiner seem to be running normal. So I'd also like to find out what happened here?
I'm getting some USB ASIC chips on Monday and plan on changing over to BFGMiner. Is this the right thing to do with slush's pool?
Appreciate any input and keep up the good work.
When I used guiminer, I found one or more gpu's needed a stop/restart about every 12 hours or they'd go off into never-never land, and a complete kill and reload of the app about every 3 days kept it from crashing. Now I use cgminer for my gpu workers and bfgminer for my fpga/asic workers. cgminer gives me the same start-stop control over my gpus that guiminer did, without guiminer's frequent hangs, plus other controls not directly accessible in the guiminer app like temp cutoffs per gpu and fail-overs. Last I used guiminer, it would not support fpga/asic workers -- don't know if it does now -- so use bfgminer since it usually auto-detects fpga/asic devices, and if it doesn't, you can force it to scan any usb ports it missed. I could use bfgminer for my gpus, too, but have been too lazy to change my cgminer .bat files to bfgminer. |
|
|
|
paraipan, just an idea to use math to put things in perspective: we can take the two rounds in question 19079 and 19080, and group them separately with the 10 rounds before and after each. then we will use a formula to see the variance between the two groups.
take rounds 19069 - 19079 and add them together. we'll call this 'x' then take rounds 19080 - 19090 and add them together. we'll call this 'y'
then plug the numbers into this formula
((x-y)/(x+y))*100=
if done correctly, that number is your % of variance between rounds 19069-79 and rounds 19080-90.
it should be between 5 and -5
if it's inside of that range then the scoring system is working properly
if it's outside that range then o crap, something's gone wrong. (probably a mistyped number, double check your work!)
I just did this myself, and my variance was 3%, meaning i scored 3% more in rounds 19069-79 vs rounds 19080-90
and i'm a slowwww miner, which means i could actually have greater variance (from 20 to -20) but my variance was only 3, so that's pretty darn good.
At least 20% of all statistical inferences (0.93 confidence factor) are based on false premises, including what I have just stated. |
|
|
|
I hope and pray that the 4 Th/s never comes back ever again. It vanished after causing the difficulty to skyrocket. I am sure the pool luck will improve in the hours to come.
It just moved to another pool is all -- difficulty would've gone up no matter where they were mining, and it would be nice to have them back with us. |
|
|
|
Question: Suggested difficulty option box.
What is the point in this box? It optional but then if its optional dose it really matter? I'm running just 4 Block Erupters on Slush's Pool should I change my setting and if so to what?
For those with large amount of hash power, setting a higher difficulty will reduce the network bandwidth consumed by submitted shares. You don't have enough hashpower for it to matter. I wouldn't worry about it. So just curious at what point would you need to set a higher difficulty? How many Mhash/s are we talkin'? I know what the website suggests according to Mhash/s but is this realistic? What have others experienced? When you set a value there, it tells the servers "Don't send me anything less than this." The maximum is whatever diff the server decides to send. For example, one of my miners is set for diff 2 -- most shares I get are between 2-1000, but I often get shares as high as 10M to work. Not really. The difficulty value you set in your client tells your client to send only shares of that difficulty (and higher) to the server. And it tells the server that you will be doing so. The server will than count each your difficulty 2 (or higher) share as two difficulty 1 shares (when you set the difficulty to 2, of course). Your network traffic is then lower, and lower is also your demand on the server capacity. The server makes no decision about what difficulty it sends you. It in fact can't do anything like that. You don't get shares as high as 10M to work. You don't get any shares to work on from the server. The server gives you some data to work on, and it's a matter of your fortune to find a share. When your client is set to send shares of diff 1, it sends all shares it finds to the server. To find one such basic share you have to compute 2 32 hashes at average. When you set the difficulty to a higher number, only shares of that difficulty (and higher, of course) are sent to the server. This is useful when your share rate would be too (unnecesarily) high with shares of diff 1. Thanks for the clarification |
|
|
|
Question: Suggested difficulty option box.
What is the point in this box? It optional but then if its optional dose it really matter? I'm running just 4 Block Erupters on Slush's Pool should I change my setting and if so to what?
For those with large amount of hash power, setting a higher difficulty will reduce the network bandwidth consumed by submitted shares. You don't have enough hashpower for it to matter. I wouldn't worry about it. So just curious at what point would you need to set a higher difficulty? How many Mhash/s are we talkin'? I know what the website suggests according to Mhash/s but is this realistic? What have others experienced? When you set a value there, it tells the servers "Don't send me anything less than this." The maximum is whatever diff the server decides to send. For example, one of my miners is set for diff 2 -- most shares I get are between 2-1000, but I often get shares as high as 10M to work. |
|
|
|
Ooooh, now that's an idea -- unfortunately, as a Bitcoin miner, I'm self-employed. Oh, well ....
Are you? Are you mining solo? :-) OK, let's modify the above example, when you don't feel yourself "employed" by Slush. ;-) If you're self-employed, you get money for some goods or services. Then, when you don't deliver your goods or services, you're not paid. OK now? ;-) Yup, I get "official" money (or other things of value) from the BTC I produce by mining. In a pool we're all self-employed, including the pool operator. For example, Slush is self-employed -- he sells network and accounting services to pool members. We can either pay fees to Slush (or some other pool operator) for access to his node on the Bitcoin network and his accounting services to tally our shares of the blocks we collectively mine via his node, or we can save those fees by going solo, setting up our own nodes and doing our own accounting -- then we can generate even more income by selling access to our nodes to others, and helping them with their accounting (for a fee, of course!). My current thinking is that 2% for Slush's services is reasonable and well worth the time and energy it would take to operate solo. Might think differently if I had a few Terahash to dig with. |
|
|
|
In the long run, you're "punished" just to the extent you're down. When you won't come to your work, you won't be paid. Or would you like something like paid holidays? Ooooh, now that's an idea -- unfortunately, as a Bitcoin miner, I'm self-employed. Oh, well .... |
|
|
|
I sadly left the pool and started litecoin mining, I get 30% more that way.
It was nice being there with you guys !
Have you seen total network ? All time record right now : Network total 244.415 Thash/s
Get ready for a difficulty increase of at least 20% in 800 blocks, thanks to asics :/
take care people !
I moved my gpus over already -- wish my FPGAs had enough active memory to run scrypt while I'm waiting for my ASICs. Good luck, maybe I'll see you in WeMineLTC pool (web: https://www.wemineltc.com/index, forum: https://bitcointalk.org/index.php?topic=169249.0). |
|
|
|
|
Show Posts
