Connected to stratum.bitcoin.cz diff 4 with stratum as user *****
website down for me but miner can connect....
Loc:Singapore
Topic: [4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool - page 415. (Read 4382755 times)
February 12, 2014, 01:40:58 AM
February 12, 2014, 01:37:16 AM
website is down for me too, my miners still get shares. looks like mining still works.
February 12, 2014, 01:17:59 AM
Website down for anyone else?
Things that make you go hmmmmm... "luck" my ass
Things that make you go hmmmmm... "luck" my ass
Touché Dubbs!
February 12, 2014, 01:17:21 AM
Yes it is down for me as well - 503
February 12, 2014, 01:14:50 AM
Website down for anyone else?
Things that make you go hmmmmm... "luck" my ass
Things that make you go hmmmmm... "luck" my ass
February 11, 2014, 10:29:51 PM
My guess would be that the Mhash/s* is adjusting since it's on to a new block. That hash rate number is based on "shares so far" on the current block so the bigger rigs probably take over a little faster and then it smooths out as time goes on. Just my theory. I guess it would only be problematic in really fast solved blocks? But I don't think your equipment has any issues if it comes back over a short time.
Thanks for the reply -
I may not have explained as well as I could have. It doesn't seem to me to be a short time (relatively speaking I guess) and not just in blocks that are solved quickly. I usually am running between 96 and 101 Gh/s and my miners are steady within that range until a block is found. Once a block is found and the stat page has the block in 'processing', I am hashing between 85 and 89 Gh/s for the 35 - 40 minutes (or so) it takes to finish processing. I watch for a recovery to the 96 to 101 Gh/s rate and it only comes back after I have a reward posted and 'processing' is no longer displayed for the block. This has happened 7 times in a row that I have made sure to watch. I was going to wait for the current block to finish before posting, but its taking forever
I originally thought it might be adjustment to the new block...and I guess it is still possible, but it just seemed odd that the hash rate dropped right when the block was found and processing started, then came back when processing was finished for every block I watched, no matter the speed of the block. I guess I will make some more observations that are better timed to see if I find more clues.
Thanks again...
Actually I get the opposite effect. When a new block is found my rate seems higher for a little while. It'll show 210-20 at times when I know I am running at a pretty solid 206. I guess the best way to see if it's really affecting your payout is to average shares over time and see if the payouts you are getting equal the average number of shares you are getting? There may be a lag in the database when a new block is found?
EDIT: Just as that block cleared my hash rate went to 220429.682. I only have 206-207 tops here. So I think it needs to recalibrate after each round. Also the pool has gone from 80- 82,?
Ghash/s to 868210.711 Ghash/s over the last 2 days or so. I think a lot of people bailed and then came back. Imagine the work the database has to do to calculate all of these statistics in near real time. I think Slush does a pretty good job. But it's not NASA. There are sure to be some anomoly's. February 11, 2014, 10:21:55 PM
My guess would be that the Mhash/s* is adjusting since it's on to a new block. That hash rate number is based on "shares so far" on the current block so the bigger rigs probably take over a little faster and then it smooths out as time goes on. Just my theory. I guess it would only be problematic in really fast solved blocks? But I don't think your equipment has any issues if it comes back over a short time.
Thanks for the reply -
I may not have explained as well as I could have. It doesn't seem to me to be a short time (relatively speaking I guess) and not just in blocks that are solved quickly. I usually am running between 96 and 101 Gh/s and my miners are steady within that range until a block is found. Once a block is found and the stat page has the block in 'processing', I am hashing between 85 and 89 Gh/s for the 35 - 40 minutes (or so) it takes to finish processing. I watch for a recovery to the 96 to 101 Gh/s rate and it only comes back after I have a reward posted and 'processing' is no longer displayed for the block. This has happened 7 times in a row that I have made sure to watch. I was going to wait for the current block to finish before posting, but its taking forever
I originally thought it might be adjustment to the new block...and I guess it is still possible, but it just seemed odd that the hash rate dropped right when the block was found and processing started, then came back when processing was finished for every block I watched, no matter the speed of the block. I guess I will make some more observations that are better timed to see if I find more clues.
Thanks again...
February 11, 2014, 09:45:45 PM
Luck always looks worse if you average over days instead of blocks. The long rounds take longer, so "luck" looks worse than it should be.
No doubt.. . I check once a day or so. . . If I see 6 blocks looking for confirmations (about 36 hours worth of stuff), then its about average. . . If you only see two or one (like right now), then that means there haven't been a lot of blocks done. . . right now its one block, which means the current block was long enough for most of the earlier rounds to all be confirmed. . .
19 more confirmations and I'm tapped out! Have not seen that since I started mining. This surely has been a funky couple of weeks!
EDIT: Well that 15:25:45 block came in before all my confirmations, so I've still yet to be Tapped!
February 11, 2014, 09:41:48 PM
My guess would be that the Mhash/s* is adjusting since it's on to a new block. That hash rate number is based on "shares so far" on the current block so the bigger rigs probably take over a little faster and then it smooths out as time goes on. Just my theory. I guess it would only be problematic in really fast solved blocks? But I don't think your equipment has any issues if it comes back over a short time.
February 11, 2014, 09:08:17 PM
Hey all - I am unsure as to the normality of the following as I am new to mining, so a little advice would be helpful please...
It appears to me that every time a block is found and the stats page has the 'processing' message for the block that was just found, my hash rate dips 6 - 10 gh/s (not stuck at one interval, when I refresh the screen it varies between 6 & 10 Gh/s).
I noticed the dip on a block about 4 days ago and just passed it off as some sort of network re-adjustment. I bounced the miner client and it didn't help. I looked an hour or so later and everything was normal, so I figured I must have needed a reset. I noticed it again a couple of blocks later and tried the same thing, but watched it more closely. The hashes only came back up after the last block quit processing and showed my BTC reward. I then started to watch for a correlation. After closer notice of the last 7 blocks, every time a block is found I see the trail off in hashes and as soon as it is done processing the hash rate bounces right back. Is this an accepted pool trait or should I be looking at my mining hardware?
- Thanks -
It appears to me that every time a block is found and the stats page has the 'processing' message for the block that was just found, my hash rate dips 6 - 10 gh/s (not stuck at one interval, when I refresh the screen it varies between 6 & 10 Gh/s).
I noticed the dip on a block about 4 days ago and just passed it off as some sort of network re-adjustment. I bounced the miner client and it didn't help. I looked an hour or so later and everything was normal, so I figured I must have needed a reset. I noticed it again a couple of blocks later and tried the same thing, but watched it more closely. The hashes only came back up after the last block quit processing and showed my BTC reward. I then started to watch for a correlation. After closer notice of the last 7 blocks, every time a block is found I see the trail off in hashes and as soon as it is done processing the hash rate bounces right back. Is this an accepted pool trait or should I be looking at my mining hardware?
- Thanks -
February 11, 2014, 07:39:18 PM
Luck always looks worse if you average over days instead of blocks. The long rounds take longer, so "luck" looks worse than it should be.
No doubt.. . I check once a day or so. . . If I see 6 blocks looking for confirmations (about 36 hours worth of stuff), then its about average. . . If you only see two or one (like right now), then that means there haven't been a lot of blocks done. . . right now its one block, which means the current block was long enough for most of the earlier rounds to all be confirmed. . .
February 11, 2014, 07:22:06 PM
91% 30-day luck.. That's pretty awful
yeah, and it was all in the last week essentially that pulled the 30 day average down about 10 points. . . So figure how bad its been the last week and there is your answer. .
Just this week - about 3 of the days this week I am about 1/3 of my normal average, so it has definitely been a very bad run of luck this week. . and its like the hits keep on coming with long block after long block. .
Here's hoping things normalize themselves, but it almost seems like the normalization will occur with the luck metric resetting itself vs us getting better luck to normalize those numbers. . .
Luck always looks worse if you average over days instead of blocks. The long rounds take longer, so "luck" looks worse than it should be.
February 11, 2014, 07:05:24 PM
91% 30-day luck.. That's pretty awful
yeah, and it was all in the last week essentially that pulled the 30 day average down about 10 points. . . So figure how bad its been the last week and there is your answer. .
Just this week - about 3 of the days this week I am about 1/3 of my normal average, so it has definitely been a very bad run of luck this week. . and its like the hits keep on coming with long block after long block. .
Here's hoping things normalize themselves, but it almost seems like the normalization will occur with the luck metric resetting itself vs us getting better luck to normalize those numbers. . .
February 11, 2014, 06:55:16 PM
Except on Pr(x <= 0.99) , k=30, lambda=30 calculation at http://www.wolframalpha.com/input/?i=Pr%28x+%3C%3D+0.99%29+%2C+k%3D30%2C+lambda%3D30 which says 0.839823 ...
Try entering "Erlang distribution" at the front:
Erlang distribution Pr(x <= 0.99) , k=30, lambda=30
February 11, 2014, 06:34:14 PM
...........
Thanks for the Formula's and explanation. I for one will try this. Probably not until the weekend, But I will get back to you with my results.
Thanks for the Formula's and explanation. I for one will try this. Probably not until the weekend, But I will get back to you with my results.
I'll be interested to see how you go. Keep us posted?
OK so here is what I got:
Round 21628 Thru 21657 = 30 Rounds
Total Shares = 78149042396
All blocks solved at Difficulty - 2,621,404,453.06
2,621,404,453.06 * 30 = 78,642,133,591.8
So Total Shares - 78149042396/78,642,133,591.8 (Difficulty * 30) = x
x = .993729936189684
k=30, lambda=30, x=.993729936189684
RESULT = .5105800139110
OK! Now it's up to you to tell me/us what this number means
Thanks
I went trough the same drill and got the same numbers just to corroborate the effort of PostMixer!
Except on Pr(x <= 0.99) , k=30, lambda=30 calculation at http://www.wolframalpha.com/input/?i=Pr%28x+%3C%3D+0.99%29+%2C+k%3D30%2C+lambda%3D30 which says 0.839823 ...
I used: http://www.wolframalpha.com/input/?i=erlang+distribution+Pr%28x+%3C%3D+1.1%29+%2C+k%3D10%2C+lambda%3D10
Replacing (x <= 1.1) with x=.993729936189684
February 11, 2014, 06:25:17 PM
...........
Thanks for the Formula's and explanation. I for one will try this. Probably not until the weekend, But I will get back to you with my results.
Thanks for the Formula's and explanation. I for one will try this. Probably not until the weekend, But I will get back to you with my results.
I'll be interested to see how you go. Keep us posted?
OK so here is what I got:
Round 21628 Thru 21657 = 30 Rounds
Total Shares = 78149042396
All blocks solved at Difficulty - 2,621,404,453.06
2,621,404,453.06 * 30 = 78,642,133,591.8
So Total Shares - 78149042396/78,642,133,591.8 (Difficulty * 30) = x
x = .993729936189684
k=30, lambda=30, x=.993729936189684
RESULT = .5105800139110
OK! Now it's up to you to tell me/us what this number means
Thanks
I went trough the same drill and got the same numbers just to corroborate the effort of PostMixer!
Except on Pr(x <= 0.99) , k=30, lambda=30 calculation at http://www.wolframalpha.com/input/?i=Pr%28x+%3C%3D+0.99%29+%2C+k%3D30%2C+lambda%3D30 which says 0.839823 ...
February 11, 2014, 06:21:15 PM
...........
Thanks for the Formula's and explanation. I for one will try this. Probably not until the weekend, But I will get back to you with my results.
Thanks for the Formula's and explanation. I for one will try this. Probably not until the weekend, But I will get back to you with my results.
I'll be interested to see how you go. Keep us posted?
OK so here is what I got:
Round 21628 Thru 21657 = 30 Rounds
Total Shares = 78149042396
All blocks solved at Difficulty - 2,621,404,453.06
2,621,404,453.06 * 30 = 78,642,133,591.8
So Total Shares - 78149042396/78,642,133,591.8 (Difficulty * 30) = x
x = .993729936189684
k=30, lambda=30, x=.993729936189684
RESULT = .5105800139110
OK! Now it's up to you to tell me/us what this number means
Thanks
I went trough the same drill and got the same numbers just to corroborate the effort of PostMixer!
February 11, 2014, 06:17:37 PM
Completely new to this so if my question is stupid I will say I am sorry now. I have setup cgminer and configured a batch file to run it. I was not able to get the batch file in the knowledgebase to work but I have gotten it launched with this
I:\CGMiner\cgminer.exe -o stratum+tcp://stratum.bitcoin.cz:3333 -u XXXX.worker1 -p MyPassword
However, when I turn on verbose logging I see this...
(5s):0.00 (avg): 0.000h/s |A:0 R:0 HW:0 WV:0.0/m
This makes me suspect its not actually working. So here are my questions:
Is it working and there is simply nothing to work on now?
Is it not working and there is an issue with my batch file?
Is it not working and likely a firewall type issue?
Is there a way to tell how many MHash/s I am running?
Any help would be appreciated. I do see other messages besides the above such as work update received and but my numbers continue to be 0
I:\CGMiner\cgminer.exe -o stratum+tcp://stratum.bitcoin.cz:3333 -u XXXX.worker1 -p MyPassword
However, when I turn on verbose logging I see this...
(5s):0.00 (avg): 0.000h/s |A:0 R:0 HW:0 WV:0.0/m
This makes me suspect its not actually working. So here are my questions:
Is it working and there is simply nothing to work on now?
Is it not working and there is an issue with my batch file?
Is it not working and likely a firewall type issue?
Is there a way to tell how many MHash/s I am running?
Any help would be appreciated. I do see other messages besides the above such as work update received and but my numbers continue to be 0
(5s) and (avg) are your average hashrates for the last 5 seconds and from the program start respectively.
(You can find this information in the CGminer README file.)
So you're running zero MHash/s. So: It's not working.
The other messages can help you in finding the reason.
February 11, 2014, 06:01:01 PM
91% 30-day luck.. That's pretty awful
February 11, 2014, 05:22:00 PM
Running 30Ghs with this long blocks. bad luck brian
Jump to: