Author

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

donator
Activity: 2058
Merit: 1007
Poor impulse control.
seriously smart stuffs

I'm not really interested in kudos, I'm just keen for someone to try it and report back. I'm hoping that if a few regular posters learn how to do this it will help keep freak outs to a minimum.

Give it a try, Scyntech. If there's anything you didn't understand I'll explain it again. Anyone should be able to do this just by following the steps and using wolframalpha, but only if I explained it properly.

Organofcorti,

you do realize that to many the formula you speak of, and the terms you use are a foreign language right ?   (me included)  I took a look at it, but quickly turned away because it reminds me of something I would need a TI-83 calculator for =)

OK, thanks for the feedback. Here's a simplified version:

1. Got to http://mining.bitcoin.cz/stats/
2. Add up all the numbers in the "Total shares" column.
3. Follow each link under "Block #" to find the difficulty at which each block was solved. (For orphaned blocks, assume the same as the last difficulty). Add up all the difficulties from each block.
4. Divide the result of step 2 by the result of step 3. Call this number "X"
5. Go to http://www.wolframalpha.com/
6. In the text box, enter the following, substituting your value for X:

erlang distribution Pr(x <= X) , k=20, lambda=20



So if you calculated X as 1.1, you'd enter:

erlang distribution Pr(x <= 1.1) , k=20, lambda=20


We use  k=20 and lambda=20 since there are twenty blocks on the basic stats page. If you were to use one hundred blocks, change the values to k=100 and lambda=100.


I think if you follow that step by step you should be fine. After that you just need to understand the results, but I'll help you with that once you get this part done.
full member
Activity: 224
Merit: 100
Didn't we just recently calculate how many gigawatts to expect from our flux capacitor?  We've had some luck today.  Just happens to be bad.  Tomorrow is another day.
hero member
Activity: 699
Merit: 504
seriously smart stuffs

I'm not really interested in kudos, I'm just keen for someone to try it and report back. I'm hoping that if a few regular posters learn how to do this it will help keep freak outs to a minimum.

Give it a try, Scyntech. If there's anything you didn't understand I'll explain it again. Anyone should be able to do this just by following the steps and using wolframalpha, but only if I explained it properly.

Organofcorti,

you do realize that to many the formula you speak of, and the terms you use are a foreign language right ?   (me included)  I took a look at it, but quickly turned away because it reminds me of something I would need a TI-83 calculator for =)
donator
Activity: 2058
Merit: 1007
Poor impulse control.
seriously smart stuffs

I'm not really interested in kudos, I'm just keen for someone to try it and report back. I'm hoping that if a few regular posters learn how to do this it will help keep freak outs to a minimum.

Give it a try, Scyntech. If there's anything you didn't understand I'll explain it again. Anyone should be able to do this just by following the steps and using wolframalpha, but only if I explained it properly.
sr. member
Activity: 349
Merit: 250
“Blockchain Just Entered The Real World”

"I don't think anyone sensible would label someone "an idiot" just for looking at 'potential explanations for what looks to be a pattern of "luck" '. What often does get one's goat is when the potential explanations are so wrong headed that they just cloud the issue.

To work out if slush's pool's "luck" is unusual or not:

1. Get an average of difficulty 1 equivalent accepted shares / expected shares (mining difficulty for eachblock) for the last  "n" blocks.
2. Using the Erlang distribution, calculate the CDF using x = the average you calculated, k and lambda both = number of blocks.

You can use Wolfram Alpha if you don't have access to statistical software. Here's an example using a 10 block average average accepted/expected of 1.1:

http://www.wolframalpha.com/input/?i=erlang+distribution+Pr%28x+%3C%3D+1.1%29+%2C+k%3D10%2C+lambda%3D10

In terms of bad luck, if the answer is > 0.99 then that is pretty bad and would happen only once in one hundred reruns of k blocks. Likewise, and answer of 0.9999 would happen only once in ten thousand reruns of k blocks. If you'd averaged the last one hundred blocks and you got 0.9999, there would be good grounds to think something funky is going on. Otherwise, maybe not.

Give it a try and report back, and do ask questions if I haven't been clear.

Doing this is the only way anyone will take your concerns about 'bad luck' seriously."




+1 to whatever this guy said, it reads REALLY smart...LoL.  

seriously smart stuffs
hero member
Activity: 699
Merit: 504

"I don't think anyone sensible would label someone "an idiot" just for looking at 'potential explanations for what looks to be a pattern of "luck" '. What often does get one's goat is when the potential explanations are so wrong headed that they just cloud the issue.

To work out if slush's pool's "luck" is unusual or not:

1. Get an average of difficulty 1 equivalent accepted shares / expected shares (mining difficulty for eachblock) for the last  "n" blocks.
2. Using the Erlang distribution, calculate the CDF using x = the average you calculated, k and lambda both = number of blocks.

You can use Wolfram Alpha if you don't have access to statistical software. Here's an example using a 10 block average average accepted/expected of 1.1:

http://www.wolframalpha.com/input/?i=erlang+distribution+Pr%28x+%3C%3D+1.1%29+%2C+k%3D10%2C+lambda%3D10

In terms of bad luck, if the answer is > 0.99 then that is pretty bad and would happen only once in one hundred reruns of k blocks. Likewise, and answer of 0.9999 would happen only once in ten thousand reruns of k blocks. If you'd averaged the last one hundred blocks and you got 0.9999, there would be good grounds to think something funky is going on. Otherwise, maybe not.

Give it a try and report back, and do ask questions if I haven't been clear.

Doing this is the only way anyone will take your concerns about 'bad luck' seriously."




+1 to whatever this guy said, it reads REALLY smart...LoL.  
donator
Activity: 2058
Merit: 1007
Poor impulse control.
So 37% day luck np happens, 70% week luck yeah hmm.... and 91% month.... we sure something isn't wrong?  Might have to switch soonish myself but rather support spreading out hash power.

I'm never sure, but then people jump on me and say I'm a conspiracy theorist. I dunno, my opinion is our luck will improve once the database issues are resolved, just like last time it choked when we were getting close to 900TH/S. BUT, nobody wants to even consider the possibility that it's an issue backstage on the pool, which honestly is what appears to be happening. I love that "IT guy" mentality where anyone exploring potential explanations for what looks to be a pattern of "luck" is labeled as an idiot.

I dunno, seems very funky.  just look at when everything is going smooth how quickly the confirmations for blocks found go....but when there is a glitch, the blocks take forever to get confirmations.  one block lasts 23 hours to confirm.  how many "website under service" messages have we seen today ?  all points to issues behind the scenes.  I think during bad luck collective hashing power should be pointed to BTCGuild ...LoL.  those guys find blocks left and right...never a sad 30% dry spell for so many days.  in the past  7 days or so our month luck dropped big time.  What the feezy ?

I don't think anyone sensible would label someone "an idiot" just for looking at 'potential explanations for what looks to be a pattern of "luck" '. What often does get one's goat is when the potential explanations are so wrong headed that they just cloud the issue.

To work out if slush's pool's "luck" is unusual or not:

1. Get an average of difficulty 1 equivalent accepted shares / expected shares (mining difficulty for each block) for the last  "n" blocks.
2. Using the Erlang distribution, calculate the CDF using x = the average you calculated, k and lambda both = number of blocks.

You can use Wolfram Alpha if you don't have access to statistical software. Here's an example using a 10 block average average accepted/expected of 1.1:

http://www.wolframalpha.com/input/?i=erlang+distribution+Pr%28x+%3C%3D+1.1%29+%2C+k%3D10%2C+lambda%3D10

In terms of bad luck, if the answer is > 0.99 then that is pretty bad and would happen only once in one hundred reruns of k blocks. Likewise, and answer of 0.9999 would happen only once in ten thousand reruns of k blocks. If you'd averaged the last one hundred blocks and you got 0.9999, there would be good grounds to think something funky is going on. Otherwise, maybe not.

Give it a try and report back, and do ask questions if I haven't been clear.

Doing this is the only way anyone will take your concerns about 'bad luck' seriously.
hero member
Activity: 699
Merit: 504
So 37% day luck np happens, 70% week luck yeah hmm.... and 91% month.... we sure something isn't wrong?  Might have to switch soonish myself but rather support spreading out hash power.

I'm never sure, but then people jump on me and say I'm a conspiracy theorist. I dunno, my opinion is our luck will improve once the database issues are resolved, just like last time it choked when we were getting close to 900TH/S. BUT, nobody wants to even consider the possibility that it's an issue backstage on the pool, which honestly is what appears to be happening. I love that "IT guy" mentality where anyone exploring potential explanations for what looks to be a pattern of "luck" is labeled as an idiot.

I dunno, seems very funky.  just look at when everything is going smooth how quickly the confirmations for blocks found go....but when there is a glitch, the blocks take forever to get confirmations.  one block lasts 23 hours to confirm.  how many "website under service" messages have we seen today ?  all points to issues behind the scenes.  I think during bad luck collective hashing power should be pointed to BTCGuild ...LoL.  those guys find blocks left and right...never a sad 30% dry spell for so many days.  in the past  7 days or so our month luck dropped big time.  What the feezy ?

I'm not sure who you talk to, but if you look at the BTCguild thread, You'll see that they are all commenting on a bad luck streak as well.

30% worth i think not.   don't get me wrong...like slush pool...just hate this "bad luck" streak.  i paid too much to get jalapeno paydays.
hero member
Activity: 490
Merit: 501
So 37% day luck np happens, 70% week luck yeah hmm.... and 91% month.... we sure something isn't wrong?  Might have to switch soonish myself but rather support spreading out hash power.

I'm never sure, but then people jump on me and say I'm a conspiracy theorist. I dunno, my opinion is our luck will improve once the database issues are resolved, just like last time it choked when we were getting close to 900TH/S. BUT, nobody wants to even consider the possibility that it's an issue backstage on the pool, which honestly is what appears to be happening. I love that "IT guy" mentality where anyone exploring potential explanations for what looks to be a pattern of "luck" is labeled as an idiot.

I dunno, seems very funky.  just look at when everything is going smooth how quickly the confirmations for blocks found go....but when there is a glitch, the blocks take forever to get confirmations.  one block lasts 23 hours to confirm.  how many "website under service" messages have we seen today ?  all points to issues behind the scenes.  I think during bad luck collective hashing power should be pointed to BTCGuild ...LoL.  those guys find blocks left and right...never a sad 30% dry spell for so many days.  in the past  7 days or so our month luck dropped big time.  What the feezy ?

I'm not sure who you talk to, but if you look at the BTCguild thread, You'll see that they are all commenting on a bad luck streak as well.
hero member
Activity: 699
Merit: 504
So 37% day luck np happens, 70% week luck yeah hmm.... and 91% month.... we sure something isn't wrong?  Might have to switch soonish myself but rather support spreading out hash power.

I'm never sure, but then people jump on me and say I'm a conspiracy theorist. I dunno, my opinion is our luck will improve once the database issues are resolved, just like last time it choked when we were getting close to 900TH/S. BUT, nobody wants to even consider the possibility that it's an issue backstage on the pool, which honestly is what appears to be happening. I love that "IT guy" mentality where anyone exploring potential explanations for what looks to be a pattern of "luck" is labeled as an idiot.

I dunno, seems very funky.  just look at when everything is going smooth how quickly the confirmations for blocks found go....but when there is a glitch, the blocks take forever to get confirmations.  one block lasts 23 hours to confirm.  how many "website under service" messages have we seen today ?  all points to issues behind the scenes.  I think during bad luck collective hashing power should be pointed to BTCGuild ...LoL.  those guys find blocks left and right...never a sad 30% dry spell for so many days.  in the past  7 days or so our month luck dropped big time.  What the feezy ?
member
Activity: 66
Merit: 10
Wow! My miner found a block. Number 285163. A first for me.

Mine found 2 a couple days ago throughout a single day and my rig is microscopic in comparison to what I see out there. Is that equivalent lightning striking twice?

How do you check to see if your miner was the one that found a block?
full member
Activity: 224
Merit: 100
Wow! My miner found a block. Number 285163. A first for me.

Mine found 2 a couple days ago throughout a single day and my rig is microscopic in comparison to what I see out there. Is that equivalent lightning striking twice?
sr. member
Activity: 322
Merit: 250
So 37% day luck np happens, 70% week luck yeah hmm.... and 91% month.... we sure something isn't wrong?  Might have to switch soonish myself but rather support spreading out hash power.

I'm never sure, but then people jump on me and say I'm a conspiracy theorist. I dunno, my opinion is our luck will improve once the database issues are resolved, just like last time it choked when we were getting close to 900TH/S. BUT, nobody wants to even consider the possibility that it's an issue backstage on the pool, which honestly is what appears to be happening. I love that "IT guy" mentality where anyone exploring potential explanations for what looks to be a pattern of "luck" is labeled as an idiot.
hero member
Activity: 494
Merit: 500
So 37% day luck np happens, 70% week luck yeah hmm.... and 91% month.... we sure something isn't wrong?  Might have to switch soonish myself but rather support spreading out hash power.
legendary
Activity: 3836
Merit: 4969
Doomed to see the future and unable to prevent it
Hi guys, thx for all the help so far. I have the proxy running but I get all rejects. Any Idea what I'm doing wrong?

Also If this is the wrong thread for help on this just say so and I'll bugger off. Wink


C:\Mining\Mining_Proxy>mining_proxy -o nobl.poolerino.com -p 3344


Are you using the proxy from Slush's pool for scrypt based mining? With what hardware? I assume a GPU. I use ASICs for Slush with that proxy, my server has an ATI GPU and digs for doggie coins with cgminer. I'm not so sure that proxy you are using works with scrypt coins.

Yes it is Scrypt. I came to that same conclusion and have been looking for an alternative proxy. Looking into bfgminer right now.

I want to thank all you guys for your help and not bashing a n00b for my ignorance. You all seem like a great bunch, wish I had started BTC when I had the chance rather than losing my nut folding back then. Smiley

EDIT:  GOT IT!!!!

For anyone that this comes up in a search this is the stratum proxy for scrypt branch.

https://github.com/CryptoManiac/stratum-mining-proxy/blob/master/README.md

Example strings.

mining_proxy -pa scrypt -o nobl.poolerino.com -p 3344

Code:
C:\Mining\Mining_Proxy>mining_proxy /?
usage: mining_proxy [-h] [-o HOST] [-p PORT] [-sh STRATUM_HOST]
                    [-sp STRATUM_PORT] [-oh GETWORK_HOST] [-gp GETWORK_PORT]
                    [-nm] [-rt] [-cl CUSTOM_LP] [-cs CUSTOM_STRATUM]
                    [-cu CUSTOM_USER] [-cp CUSTOM_PASSWORD]
                    [--blocknotify BLOCKNOTIFY_CMD] [--socks PROXY] [--tor]
                    [-t] [-v] [-q] [-i PID_FILE] [-pa POW_ALGO]
mining_proxy: error: unrecognized arguments: /?

C:\Mining\Mining_Proxy>mining_proxy -pa scrypt -o nobl.poolerino.com -p 3344
2014-02-10 18:31:47,943 WARNING proxy jobs. # C extension for midstate n
ot available. Using default implementation instead.
2014-02-10 18:31:48,375 INFO proxy mining_proxy.main # Stratum proxy version: 1.
3.0
2014-02-10 18:31:48,375 INFO proxy mining_proxy.main # Trying to connect to Stra
tum pool at nobl.poolerino.com:3344
2014-02-10 18:31:48,377 INFO proxy mining_proxy.main # Setting PoW algo: scrypt
2014-02-10 18:31:48,516 INFO stats stats.print_stats # 1 peers connected, state
changed 1 times
2014-02-10 18:31:48,516 INFO proxy mining_proxy.on_connect # Connected to Stratu
m pool at nobl.poolerino.com:3344
2014-02-10 18:31:48,516 INFO proxy mining_proxy.on_connect # Subscribing for min
ing jobs
2014-02-10 18:31:48,651 INFO proxy mining_proxy.main # -------------------------
----------------------------------------------
2014-02-10 18:31:48,653 INFO proxy mining_proxy.main # PROXY IS LISTENING ON ALL
 IPs ON PORT 3333 (stratum) AND 8332 (getwork)
2014-02-10 18:31:48,654 INFO proxy mining_proxy.main # -------------------------
----------------------------------------------
2014-02-10 18:31:48,655 INFO proxy client_service.handle_event # Setting new dif
ficulty: 32
2014-02-10 18:31:48,657 INFO proxy client_service.handle_event # New job 7432 fo
r prevhash 83631151, clean_jobs=True
2014-02-10 18:32:47,332 INFO proxy client_service.handle_event # New job 7433 fo
r prevhash 83631151, clean_jobs=False
2014-02-10 18:32:51,036 INFO proxy client_service.handle_event # New job 7434 fo
r prevhash 0492592e, clean_jobs=True
2014-02-10 18:33:51,056 INFO proxy client_service.handle_event # New job 7435 fo
r prevhash 0492592e, clean_jobs=False
2014-02-10 18:34:51,131 INFO proxy client_service.handle_event # New job 7436 fo
r prevhash 0492592e, clean_jobs=False
2014-02-10 18:35:22,634 INFO proxy client_service.handle_event # New job 7437 fo
r prevhash 94b09ce0, clean_jobs=True
2014-02-10 18:35:44,907 INFO proxy client_service.handle_event # New job 7438 fo
r prevhash f7aebce5, clean_jobs=True
2014-02-10 18:35:47,426 INFO proxy client_service.handle_event # New job 7439 fo
r prevhash 557dbc9f, clean_jobs=True
2014-02-10 18:36:18,996 INFO proxy client_service.handle_event # New job 743a fo
r prevhash 878275ad, clean_jobs=True
2014-02-10 18:37:19,010 INFO proxy client_service.handle_event # New job 743b fo
r prevhash 878275ad, clean_jobs=False
2014-02-10 18:37:38,213 INFO stats stats.print_stats # 2 peers connected, state
changed 1 times
Unhandled Error
Traceback (most recent call last):
  File "twisted\python\log.pyo", line 84, in callWithLogger

  File "twisted\python\log.pyo", line 69, in callWithContext

  File "twisted\python\context.pyo", line 118, in callWithContext

  File "twisted\python\context.pyo", line 81, in callWithContext

--- ---
  File "twisted\internet\selectreactor.pyo", line 150, in _doReadOrWrite

  File "twisted\internet\tcp.pyo", line 203, in doRead

  File "twisted\internet\tcp.pyo", line 209, in _dataReceived

  File "stratum\protocol.pyo", line 174, in dataReceived

  File "stratum\protocol.pyo", line 185, in lineReceived

stratum.custom_exceptions.ProtocolException: Cannot decode message 'POST / HTTP/
'.1
2014-02-10 18:37:38,213 INFO stats stats.print_stats # 1 peers connected, state
changed 1 times
2014-02-10 18:37:43,670 INFO proxy client_service.handle_event # New job 743c fo
r prevhash 6077b113, clean_jobs=True
2014-02-10 18:38:22,380 INFO proxy client_service.handle_event # New job 743d fo
r prevhash 156f7f93, clean_jobs=True
2014-02-10 18:39:22,378 INFO proxy client_service.handle_event # New job 743e fo
r prevhash 156f7f93, clean_jobs=False
2014-02-10 18:40:22,403 INFO proxy client_service.handle_event # New job 743f fo
r prevhash 156f7f93, clean_jobs=False
2014-02-10 18:40:49,799 INFO proxy client_service.handle_event # New job 7440 fo
r prevhash a6f28f99, clean_jobs=True
2014-02-10 18:41:36,270 INFO proxy client_service.handle_event # New job 7441 fo
r prevhash 639d366b, clean_jobs=True
2014-02-10 18:42:00,046 INFO proxy getwork_listener.render_POST # Worker 'Vikebe
er.8800gs' subscribed for LP
2014-02-10 18:42:04,099 INFO proxy client_service.handle_event # New job a6a4 fo
r prevhash 15b92ad5, clean_jobs=True
2014-02-10 18:42:04,101 INFO proxy getwork_listener._on_lp_broadcast # LP broadc
ast for worker 'Vikebeer.8800gs'
2014-02-10 18:42:04,108 INFO proxy getwork_listener.render_POST # Worker 'Vikebe
er.8800gs' subscribed for LP
2014-02-10 18:42:24,453 INFO proxy client_service.handle_event # New job a7be fo
r prevhash 733fffc1, clean_jobs=True
2014-02-10 18:42:24,453 INFO proxy getwork_listener._on_lp_broadcast # LP broadc
ast for worker 'Vikebeer.8800gs'
2014-02-10 18:42:24,463 INFO proxy getwork_listener.render_POST # Worker 'Vikebe
er.8800gs' subscribed for LP
2014-02-10 18:42:46,572 INFO proxy client_service.handle_event # New job a8d8 fo
r prevhash 50fcaaa4, clean_jobs=True
2014-02-10 18:42:46,573 INFO proxy getwork_listener._on_lp_broadcast # LP broadc
ast for worker 'Vikebeer.8800gs'
2014-02-10 18:42:46,582 INFO proxy getwork_listener.render_POST # Worker 'Vikebe
er.8800gs' subscribed for LP
2014-02-10 18:43:09,750 INFO proxy client_service.handle_event # New job a9f1 fo
r prevhash fb7b94dc, clean_jobs=True
2014-02-10 18:43:09,750 INFO proxy getwork_listener._on_lp_broadcast # LP broadc
ast for worker 'Vikebeer.8800gs'
2014-02-10 18:43:09,759 INFO proxy getwork_listener.render_POST # Worker 'Vikebe
er.8800gs' subscribed for LP
2014-02-10 18:43:20,227 INFO proxy jobs.submit # Submitting 55abd80b
2014-02-10 18:43:20,451 INFO proxy getwork_listener._on_submit # [223ms] Share f
rom 'Vikebeer.8800gs' accepted, diff 32
2014-02-10 18:43:20,453 INFO proxy client_service.handle_event # New job ab07 fo
r prevhash c8d12b55, clean_jobs=True
2014-02-10 18:43:20,453 INFO proxy getwork_listener._on_lp_broadcast # LP broadc
ast for worker 'Vikebeer.8800gs'
2014-02-10 18:43:20,460 INFO proxy getwork_listener.render_POST # Worker 'Vikebe
er.8800gs' subscribed for LP
2014-02-10 18:43:23,177 INFO proxy client_service.handle_event # New job ac1c fo
r prevhash 60533032, clean_jobs=True
2014-02-10 18:43:23,180 INFO proxy getwork_listener._on_lp_broadcast # LP broadc
ast for worker 'Vikebeer.8800gs'
2014-02-10 18:43:23,187 INFO proxy getwork_listener.render_POST # Worker 'Vikebe
er.8800gs' subscribed for LP
2014-02-10 18:43:28,953 INFO proxy jobs.submit # Submitting 9dd9d4e0
2014-02-10 18:43:29,088 INFO proxy getwork_listener._on_submit # [134ms] Share f
rom 'Vikebeer.8800gs' accepted, diff 32
2014-02-10 18:44:23,223 INFO proxy client_service.handle_event # New job ad47 fo
r prevhash 60533032, clean_jobs=False
2014-02-10 18:44:33,061 INFO proxy jobs.submit # Submitting 75cbc3bd
2014-02-10 18:44:33,224 INFO proxy client_service.handle_event # Setting new dif
ficulty: 16.0
2014-02-10 18:44:33,224 INFO proxy client_service.handle_event # New job adcb fo
r prevhash 60533032, clean_jobs=False
2014-02-10 18:44:33,226 INFO proxy getwork_listener._on_submit # [164ms] Share f
rom 'Vikebeer.8800gs' accepted, diff 16
2014-02-10 18:44:37,928 INFO proxy client_service.handle_event # New job ae5e fo
r prevhash c972e9ce, clean_jobs=True
2014-02-10 18:44:37,928 INFO proxy getwork_listener._on_lp_broadcast # LP broadc
ast for worker 'Vikebeer.8800gs'
2014-02-10 18:44:37,937 INFO proxy getwork_listener.render_POST # Worker 'Vikebe
er.8800gs' subscribed for LP
2014-02-10 18:45:01,365 INFO proxy jobs.submit # Submitting 1deaa5bb
2014-02-10 18:45:01,502 INFO proxy getwork_listener._on_submit # [136ms] Share f
rom 'Vikebeer.8800gs' accepted, diff 16
2014-02-10 18:45:34,065 INFO proxy jobs.submit # Submitting cea9b3d5
2014-02-10 18:45:34,203 INFO proxy getwork_listener._on_submit # [138ms] Share f
rom 'Vikebeer.8800gs' accepted, diff 16
2014-02-10 18:45:37,953 INFO proxy client_service.handle_event # New job af83 fo
r prevhash c972e9ce, clean_jobs=False
2014-02-10 18:46:38,023 INFO proxy client_service.handle_event # New job b0ae fo
r prevhash c972e9ce, clean_jobs=False
2014-02-10 18:47:09,805 INFO proxy client_service.handle_event # New job b1d1 fo
r prevhash e4483b7b, clean_jobs=True
2014-02-10 18:47:09,806 INFO proxy getwork_listener._on_lp_broadcast # LP broadc
ast for worker 'Vikebeer.8800gs'
2014-02-10 18:47:09,815 INFO proxy getwork_listener.render_POST # Worker 'Vikebe
er.8800gs' subscribed for LP
2014-02-10 18:47:19,444 INFO proxy jobs.submit # Submitting 6d8e55be
2014-02-10 18:47:19,578 INFO proxy getwork_listener._on_submit # [131ms] Share f
rom 'Vikebeer.8800gs' accepted, diff 16
2014-02-10 18:48:09,813 INFO proxy client_service.handle_event # New job b2ff fo
r prevhash e4483b7b, clean_jobs=False
2014-02-10 18:48:14,585 INFO proxy client_service.handle_event # New job b417 fo
r prevhash c6524277, clean_jobs=True
2014-02-10 18:48:14,585 INFO proxy getwork_listener._on_lp_broadcast # LP broadc
ast for worker 'Vikebeer.8800gs'
2014-02-10 18:48:14,595 INFO proxy getwork_listener.render_POST # Worker 'Vikebe
er.8800gs' subscribed for LP
2014-02-10 18:48:41,487 INFO proxy client_service.handle_event # New job b537 fo
r prevhash b5251f34, clean_jobs=True
2014-02-10 18:48:41,487 INFO proxy getwork_listener._on_lp_broadcast # LP broadc
ast for worker 'Vikebeer.8800gs'
2014-02-10 18:48:41,496 INFO proxy getwork_listener.render_POST # Worker 'Vikebe
er.8800gs' subscribed for LP
2014-02-10 18:49:35,217 INFO proxy client_service.handle_event # New job b661 fo
r prevhash c4a044fd, clean_jobs=True
2014-02-10 18:49:35,217 INFO proxy getwork_listener._on_lp_broadcast # LP broadc
ast for worker 'Vikebeer.8800gs'
2014-02-10 18:49:35,224 INFO proxy getwork_listener.render_POST # Worker 'Vikebe
er.8800gs' subscribed for LP
2014-02-10 18:49:44,270 INFO proxy jobs.submit # Submitting 9c56aa55
2014-02-10 18:49:44,420 INFO proxy getwork_listener._on_submit # [149ms] Share f
rom 'Vikebeer.8800gs' accepted, diff 16
2014-02-10 18:50:24,779 INFO proxy client_service.handle_event # New job b78b fo
r prevhash 2541f0ca, clean_jobs=True
2014-02-10 18:50:24,779 INFO proxy getwork_listener._on_lp_broadcast # LP broadc
ast for worker 'Vikebeer.8800gs'
2014-02-10 18:51:17,519 INFO proxy client_service.handle_event # New job b8b2 fo
r prevhash 9316d35f, clean_jobs=True


Used old 8800gs to test with (my htpc svid out card) so don't use these cudaminer settings.

C:\cudaminer-2013-12-18\Cudaminerx64\cudaminer.exe -H 2 -i 1 -l L24x3  -o 127.0.0.1:8332 -O UserName.worker:password

Code:
           *** CudaMiner for nVidia GPUs by Christian Buchner ***
                     This is version 2013-12-18 (beta)
        based on pooler-cpuminer 2.3.2 (c) 2010 Jeff Garzik, 2012 pooler
               Cuda additions Copyright 2013 Christian Buchner
           My donation address: LKS1WDKGED647msBQfLBHV3Ls8sveGncnm

[2014-02-10 18:41:59] 1 miner threads started, using 'scrypt' algorithm.
[2014-02-10 18:42:00] Long-polling activated for http://127.0.0.1:8332/lp
[2014-02-10 18:42:00] GPU #0: GeForce 8800 GS with compute capability 1.1
[2014-02-10 18:42:00] GPU #0: interactive: 1, tex-cache: 0 , single-alloc: 0
[2014-02-10 18:42:00] GPU #0: using launch configuration L24x3
[2014-02-10 18:42:00] GPU #0: GeForce 8800 GS, 4608 hashes, 6.11 khash/s
[2014-02-10 18:42:04] LONGPOLL detected new block
[2014-02-10 18:42:04] GPU #0: GeForce 8800 GS, 46080 hashes, 13.52 khash/s
[2014-02-10 18:42:24] LONGPOLL detected new block
[2014-02-10 18:42:24] GPU #0: GeForce 8800 GS, 285696 hashes, 14.05 khash/s
[2014-02-10 18:42:46] LONGPOLL detected new block
[2014-02-10 18:42:46] GPU #0: GeForce 8800 GS, 311040 hashes, 14.02 khash/s
[2014-02-10 18:43:09] LONGPOLL detected new block
[2014-02-10 18:43:09] GPU #0: GeForce 8800 GS, 324864 hashes, 14.03 khash/s
[2014-02-10 18:43:20] GPU #0: GeForce 8800 GS, 142848 hashes, 13.82 khash/s
[2014-02-10 18:43:20] accepted: 1/1 (100.00%), 13.82 khash/s (yay!!!)
[2014-02-10 18:43:20] LONGPOLL detected new block
[2014-02-10 18:43:20] GPU #0: GeForce 8800 GS, 2304 hashes, 5.51 khash/s
[2014-02-10 18:43:23] LONGPOLL detected new block
[2014-02-10 18:43:23] GPU #0: GeForce 8800 GS, 34560 hashes, 12.84 khash/s
[2014-02-10 18:43:28] GPU #0: GeForce 8800 GS, 76032 hashes, 13.54 khash/s
[2014-02-10 18:43:29] accepted: 2/2 (100.00%), 13.54 khash/s (yay!!!)
[2014-02-10 18:44:21] GPU #0: GeForce 8800 GS, 746496 hashes, 14.10 khash/s
[2014-02-10 18:44:33] GPU #0: GeForce 8800 GS, 154368 hashes, 13.82 khash/s
[2014-02-10 18:44:33] accepted: 3/3 (100.00%), 13.82 khash/s (yay!!!)
[2014-02-10 18:44:37] LONGPOLL detected new block
[2014-02-10 18:44:38] GPU #0: GeForce 8800 GS, 66816 hashes, 13.47 khash/s
[2014-02-10 18:45:01] GPU #0: GeForce 8800 GS, 327168 hashes, 14.02 khash/s
[2014-02-10 18:45:01] accepted: 4/4 (100.00%), 14.02 khash/s (yay!!!)
[2014-02-10 18:45:34] GPU #0: GeForce 8800 GS, 460800 hashes, 14.09 khash/s
[2014-02-10 18:45:34] accepted: 5/5 (100.00%), 14.09 khash/s (yay!!!)
[2014-02-10 18:46:33] GPU #0: GeForce 8800 GS, 845568 hashes, 14.15 khash/s
[2014-02-10 18:47:09] LONGPOLL detected new block
[2014-02-10 18:47:09] GPU #0: GeForce 8800 GS, 506880 hashes, 14.09 khash/s
[2014-02-10 18:47:19] GPU #0: GeForce 8800 GS, 131328 hashes, 13.83 khash/s
[2014-02-10 18:47:19] accepted: 6/6 (100.00%), 13.83 khash/s (yay!!!)
[2014-02-10 18:48:08] GPU #0: GeForce 8800 GS, 693504 hashes, 14.12 khash/s
[2014-02-10 18:48:14] LONGPOLL detected new block
[2014-02-10 18:48:14] GPU #0: GeForce 8800 GS, 82944 hashes, 13.60 khash/s
[2014-02-10 18:48:41] LONGPOLL detected new block
[2014-02-10 18:48:41] GPU #0: GeForce 8800 GS, 377856 hashes, 14.03 khash/s
[2014-02-10 18:49:35] LONGPOLL detected new block
[2014-02-10 18:49:35] GPU #0: GeForce 8800 GS, 758016 hashes, 14.13 khash/s
[2014-02-10 18:49:44] GPU #0: GeForce 8800 GS, 124416 hashes, 13.80 khash/s
[2014-02-10 18:49:44] accepted: 7/7 (100.00%), 13.80 khash/s (yay!!!)







newbie
Activity: 29
Merit: 0
Wow! My miner found a block. Number 285163. A first for me.
full member
Activity: 224
Merit: 100
Winner winner chicken dinner. We have a live one on the line. whooot!
newbie
Activity: 32
Merit: 0
It's a lucky 50pence , here  Wink
full member
Activity: 224
Merit: 100
Those blocks it's chewing on must be pure gristle. Upping the ante with my lucky quarter.
newbie
Activity: 32
Merit: 0
Let it be... the 'hoppers' will 'hop' and our shares will go up.
Chill, it's simple Maths. We WILL return AVERAGE luck over the longer term.
 Cool
Jump to: