Topic: [4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool - page 419. (Read 4382755 times)
February 10, 2014, 09:25:51 AM
second maintanance for the mining page today. Is there any Problem we should know about?
February 10, 2014, 07:38:47 AM
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.
Also If this is the wrong thread for help on this just say so and I'll bugger off.
Code:
C:\Mining\Mining_Proxy>mining_proxy -o nobl.poolerino.com -p 3344
[/quote]
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.
February 10, 2014, 06:53:40 AM
I bet the conspiracy theorists and complainers that ran to another pool are kicking themselves now, especially since the hashrate fell by about 10% and our payouts went up.
Alas, they'll be back, refreshed and ready to carry on with their daft accusations next time we have a big dip in the luck. 
The drops and then rises in hast rate are surreal. Statistically there is no benefit on 'pool hopping'. No matter what 'luck' exists anywhere. All very random, there must be more tin foil helmet wearing peeps out there that I ever imagined.
Statistically, there is a benefit to pool-hopping at Slush's pool. http://organofcorti.blogspot.com.au/2012/08/42-slushs-score-method-and-miner.html
Kudos, and point taken. Just not sure that for my 100Gh/s such a statistically small, and tortuous to explain benefit is really worn it.
Another one for the big boys to do, I guess. Though still, knowing when to 'hop' in and out is the element of 'luck' which is still intangible.
Nonetheless, informative!
Thanks you.
However ... "Though still, knowing when to 'hop' in and out is the element of 'luck' which is still intangible"
No, otherwise pool-hopping wouldn't work. I didn't publish it in the post, but I wrote an empirical function which determines when you should stop submitting shares. It depends on the pool hashrate, the current mining difficulty, and th constant "c" in Slush's reward algorithm.
and will data centres with multi terrahash capacity use this to maximise there gain? .............. ...............?
Anyone can. When I mined and tried the strategy, I'd get around 5 to 10% more than expected, consistently. You don't need to have a large hashrate to do this, just automated software that tells your miner when to leave and mine else where.
February 10, 2014, 06:49:26 AM
After reading some of these recent posts I was wondering. Is Slush's Pool the place for my 5 Gh/s? or should be looking at a different pool for such a low hash rate?
February 10, 2014, 06:49:17 AM
One thing to note is that only the proxy tool supports longpoll on the cubes, for blades it doesn't matter. I don't really know what longpoll is, but the info I got on another thread was each cube works best if it is running on a dedicated launch of the proxy tool, and the way to separate them is with using a different port switch for each.
I have two cubes now and I run them both through one bfgminer proxy on a PI that is running another instance of bfgminer that I have ten blades proxying through. The two cubes both run at nearly 27.5 Gh/s even though longpoll isn't supported. At least in my case it really seems like the longpolling doesn't seem relevant.
I've heard some say that the PI can only handle "a couple of blades" but I've never found this to be the case at all. It's not straining the Raspberry PI... it only runs at about .3 load. There isn't a load on the CPU or memory in ASIC mining. My PI should run be able to run quite a few more cubes or whatever "blade v4" happens to be.
What is your efficiency percentage? Pretty sure on bfgminer as proxy my cubes were topping out at around 27gh/s and 85% efficiency. Running separate proxy.exe for each I'm getting 31gh/s and 97% efficiency on low clock, fwiw... My rack of blades doesn't behave like this and they run fine on bfgminer as proxy, in fact they seem to run better than running through the proxy.exe.
Just for the record...the "Efficiency %" is a meaningless number on Stratum in bfgminer/cgminer. It serves no purpose whatsoever.
Ok, but when my efficiency % says 85% and the cube won't hit 30gh/s on BFGminer, but then using the proxy tool I get 97% efficiency and over 30gh/s it kinda does actually matter. What are you basing your well-researched conclusions on? Exactly how does it not serve a purpose? I believe it has to do with the amount of successful shares relative to power consumption, either way the feedback loop seems meaningful to me because when it's low my gear won't hash to it's fullest.
Well, I just checked and I get about 97.8% efficiency on both cubes. My mileage on this apparently varies from the norm.
I am using bgminer 3.3.0 if that is an interesting tidbit. I also am sure to follow the advice that folks like Silentsonicboom give on this, and I take the cubes apart and make sure the heat syncs are snug. They *do* often have heat syncs that are not tight.
EDIT: Another thing that might be of interest is that I have a setup where everything (the blades, the cubes, and the PI) are all on one dedicated 10/100 switch. I wonder if that is a factor in how these things communicate with the PI. There is a whole heck of a lot of traffic that doesn't have to go over to other parts of my LAN that way.
February 10, 2014, 06:21:14 AM
I bet the conspiracy theorists and complainers that ran to another pool are kicking themselves now, especially since the hashrate fell by about 10% and our payouts went up.
Alas, they'll be back, refreshed and ready to carry on with their daft accusations next time we have a big dip in the luck. The drops and then rises in hast rate are surreal. Statistically there is no benefit on 'pool hopping'. No matter what 'luck' exists anywhere. All very random, there must be more tin foil helmet wearing peeps out there that I ever imagined.
Statistically, there is a benefit to pool-hopping at Slush's pool. http://organofcorti.blogspot.com.au/2012/08/42-slushs-score-method-and-miner.html
and will data centres with multi terrahash capacity use this to maximise there gain? .............. ...............?
February 10, 2014, 06:11:34 AM
I bet the conspiracy theorists and complainers that ran to another pool are kicking themselves now, especially since the hashrate fell by about 10% and our payouts went up.
Alas, they'll be back, refreshed and ready to carry on with their daft accusations next time we have a big dip in the luck. The drops and then rises in hast rate are surreal. Statistically there is no benefit on 'pool hopping'. No matter what 'luck' exists anywhere. All very random, there must be more tin foil helmet wearing peeps out there that I ever imagined.
Statistically, there is a benefit to pool-hopping at Slush's pool. http://organofcorti.blogspot.com.au/2012/08/42-slushs-score-method-and-miner.html
Kudos, and point taken. Just not sure that for my 100Gh/s such a statistically small, and tortuous to explain benefit is really worn it.
Another one for the big boys to do, I guess. Though still, knowing when to 'hop' in and out is the element of 'luck' which is still intangible.
Nonetheless, informative!
February 10, 2014, 05:45:13 AM
I bet the conspiracy theorists and complainers that ran to another pool are kicking themselves now, especially since the hashrate fell by about 10% and our payouts went up.
Alas, they'll be back, refreshed and ready to carry on with their daft accusations next time we have a big dip in the luck. The drops and then rises in hast rate are surreal. Statistically there is no benefit on 'pool hopping'. No matter what 'luck' exists anywhere. All very random, there must be more tin foil helmet wearing peeps out there that I ever imagined.
Statistically, there is a benefit to pool-hopping at Slush's pool. http://organofcorti.blogspot.com.au/2012/08/42-slushs-score-method-and-miner.html
February 10, 2014, 04:36:10 AM
I bet the conspiracy theorists and complainers that ran to another pool are kicking themselves now, especially since the hashrate fell by about 10% and our payouts went up.
Alas, they'll be back, refreshed and ready to carry on with their daft accusations next time we have a big dip in the luck. The drops and then rises in hast rate are surreal. Statistically there is no benefit on 'pool hopping'. No matter what 'luck' exists anywhere. All very random, there must be more tin foil helmet wearing peeps out there that I ever imagined.
February 10, 2014, 01:38:14 AM
FWIW, I dug up the post that guided me on the Cubes, after reading this I setup separate proxies using a different port and worker for each. From my own experimentation I also believe this is the best way to run the cubes:
Link: https://bitcointalksearch.org/topic/m.4369389
Longpoll is currently not implemented in the bfgminer getwork proxy, so that will result in low efficiency / lots of stales. Using slush's proxy, cubes do appear as separate workers to the pool when running a single instance of slush's proxy, however, I can't recommend that either. While playing around with slush's proxy and the stratum-mining pool software, I discovered that if you have multiple cubes connected to one instance of slush's proxy, then the proxy will get the share difficulties confused and only submit shares that meet the highest difficulty requirements of all workers.
Based on the above findings, currently the best setup is ONE INSTANCE OF SLUSH'S PROXY PER CUBE, however much cpu time that ends up using. I really wish longpoll would be implemented in the bfgminer getwork proxy soon... Either that, or the cube firmware should be updated to support stratum natively.
Based on the above findings, currently the best setup is ONE INSTANCE OF SLUSH'S PROXY PER CUBE, however much cpu time that ends up using. I really wish longpoll would be implemented in the bfgminer getwork proxy soon... Either that, or the cube firmware should be updated to support stratum natively.
Link: https://bitcointalksearch.org/topic/m.4369389
February 10, 2014, 01:32:26 AM
One thing to note is that only the proxy tool supports longpoll on the cubes, for blades it doesn't matter. I don't really know what longpoll is, but the info I got on another thread was each cube works best if it is running on a dedicated launch of the proxy tool, and the way to separate them is with using a different port switch for each.
I have two cubes now and I run them both through one bfgminer proxy on a PI that is running another instance of bfgminer that I have ten blades proxying through. The two cubes both run at nearly 27.5 Gh/s even though longpoll isn't supported. At least in my case it really seems like the longpolling doesn't seem relevant.
I've heard some say that the PI can only handle "a couple of blades" but I've never found this to be the case at all. It's not straining the Raspberry PI... it only runs at about .3 load. There isn't a load on the CPU or memory in ASIC mining. My PI should run be able to run quite a few more cubes or whatever "blade v4" happens to be.
What is your efficiency percentage? Pretty sure on bfgminer as proxy my cubes were topping out at around 27gh/s and 85% efficiency. Running separate proxy.exe for each I'm getting 31gh/s and 97% efficiency on low clock, fwiw... My rack of blades doesn't behave like this and they run fine on bfgminer as proxy, in fact they seem to run better than running through the proxy.exe.
bfgminer is junk with cubes. I get 35gh/s with overclocked cubes. when I point them at slush proxy I get 37-38gh/s.
so I stopped using bfgminer. I like the gui and all but losing 10% for a fancy gui isnt worth it
^
Truth
February 10, 2014, 01:30:50 AM
One thing to note is that only the proxy tool supports longpoll on the cubes, for blades it doesn't matter. I don't really know what longpoll is, but the info I got on another thread was each cube works best if it is running on a dedicated launch of the proxy tool, and the way to separate them is with using a different port switch for each.
I have two cubes now and I run them both through one bfgminer proxy on a PI that is running another instance of bfgminer that I have ten blades proxying through. The two cubes both run at nearly 27.5 Gh/s even though longpoll isn't supported. At least in my case it really seems like the longpolling doesn't seem relevant.
I've heard some say that the PI can only handle "a couple of blades" but I've never found this to be the case at all. It's not straining the Raspberry PI... it only runs at about .3 load. There isn't a load on the CPU or memory in ASIC mining. My PI should run be able to run quite a few more cubes or whatever "blade v4" happens to be.
What is your efficiency percentage? Pretty sure on bfgminer as proxy my cubes were topping out at around 27gh/s and 85% efficiency. Running separate proxy.exe for each I'm getting 31gh/s and 97% efficiency on low clock, fwiw... My rack of blades doesn't behave like this and they run fine on bfgminer as proxy, in fact they seem to run better than running through the proxy.exe.
Just for the record...the "Efficiency %" is a meaningless number on Stratum in bfgminer/cgminer. It serves no purpose whatsoever.
Ok, but when my efficiency % says 85% and the cube won't hit 30gh/s on BFGminer, but then using the proxy tool I get 97% efficiency and over 30gh/s it kinda does actually matter. What are you basing your well-researched conclusions on? Exactly how does it not serve a purpose? I believe it has to do with the amount of successful shares relative to power consumption, either way the feedback loop seems meaningful to me because when it's low my gear won't hash to it's fullest.
February 10, 2014, 01:15:34 AM
One thing to note is that only the proxy tool supports longpoll on the cubes, for blades it doesn't matter. I don't really know what longpoll is, but the info I got on another thread was each cube works best if it is running on a dedicated launch of the proxy tool, and the way to separate them is with using a different port switch for each.
I have two cubes now and I run them both through one bfgminer proxy on a PI that is running another instance of bfgminer that I have ten blades proxying through. The two cubes both run at nearly 27.5 Gh/s even though longpoll isn't supported. At least in my case it really seems like the longpolling doesn't seem relevant.
I've heard some say that the PI can only handle "a couple of blades" but I've never found this to be the case at all. It's not straining the Raspberry PI... it only runs at about .3 load. There isn't a load on the CPU or memory in ASIC mining. My PI should run be able to run quite a few more cubes or whatever "blade v4" happens to be.
What is your efficiency percentage? Pretty sure on bfgminer as proxy my cubes were topping out at around 27gh/s and 85% efficiency. Running separate proxy.exe for each I'm getting 31gh/s and 97% efficiency on low clock, fwiw... My rack of blades doesn't behave like this and they run fine on bfgminer as proxy, in fact they seem to run better than running through the proxy.exe.
bfgminer is junk with cubes. I get 35gh/s with overclocked cubes. when I point them at slush proxy I get 37-38gh/s.
so I stopped using bfgminer. I like the gui and all but losing 10% for a fancy gui isnt worth it
February 09, 2014, 10:59:31 PM
One thing to note is that only the proxy tool supports longpoll on the cubes, for blades it doesn't matter. I don't really know what longpoll is, but the info I got on another thread was each cube works best if it is running on a dedicated launch of the proxy tool, and the way to separate them is with using a different port switch for each.
I have two cubes now and I run them both through one bfgminer proxy on a PI that is running another instance of bfgminer that I have ten blades proxying through. The two cubes both run at nearly 27.5 Gh/s even though longpoll isn't supported. At least in my case it really seems like the longpolling doesn't seem relevant.
I've heard some say that the PI can only handle "a couple of blades" but I've never found this to be the case at all. It's not straining the Raspberry PI... it only runs at about .3 load. There isn't a load on the CPU or memory in ASIC mining. My PI should run be able to run quite a few more cubes or whatever "blade v4" happens to be.
What is your efficiency percentage? Pretty sure on bfgminer as proxy my cubes were topping out at around 27gh/s and 85% efficiency. Running separate proxy.exe for each I'm getting 31gh/s and 97% efficiency on low clock, fwiw... My rack of blades doesn't behave like this and they run fine on bfgminer as proxy, in fact they seem to run better than running through the proxy.exe.
Just for the record...the "Efficiency %" is a meaningless number on Stratum in bfgminer/cgminer. It serves no purpose whatsoever.
February 09, 2014, 08:25:38 PM
One thing to note is that only the proxy tool supports longpoll on the cubes, for blades it doesn't matter. I don't really know what longpoll is, but the info I got on another thread was each cube works best if it is running on a dedicated launch of the proxy tool, and the way to separate them is with using a different port switch for each.
I have two cubes now and I run them both through one bfgminer proxy on a PI that is running another instance of bfgminer that I have ten blades proxying through. The two cubes both run at nearly 27.5 Gh/s even though longpoll isn't supported. At least in my case it really seems like the longpolling doesn't seem relevant.
I've heard some say that the PI can only handle "a couple of blades" but I've never found this to be the case at all. It's not straining the Raspberry PI... it only runs at about .3 load. There isn't a load on the CPU or memory in ASIC mining. My PI should run be able to run quite a few more cubes or whatever "blade v4" happens to be.
What is your efficiency percentage? Pretty sure on bfgminer as proxy my cubes were topping out at around 27gh/s and 85% efficiency. Running separate proxy.exe for each I'm getting 31gh/s and 97% efficiency on low clock, fwiw... My rack of blades doesn't behave like this and they run fine on bfgminer as proxy, in fact they seem to run better than running through the proxy.exe.
February 09, 2014, 05:30:32 PM
One thing to note is that only the proxy tool supports longpoll on the cubes, for blades it doesn't matter. I don't really know what longpoll is, but the info I got on another thread was each cube works best if it is running on a dedicated launch of the proxy tool, and the way to separate them is with using a different port switch for each.
I have two cubes now and I run them both through one bfgminer proxy on a PI that is running another instance of bfgminer that I have ten blades proxying through. The two cubes both run at nearly 27.5 Gh/s even though longpoll isn't supported. At least in my case it really seems like the longpolling doesn't seem relevant.
I've heard some say that the PI can only handle "a couple of blades" but I've never found this to be the case at all. It's not straining the Raspberry PI... it only runs at about .3 load. There isn't a load on the CPU or memory in ASIC mining. My PI should run be able to run quite a few more cubes or whatever "blade v4" happens to be.
February 09, 2014, 03:56:47 PM
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.
Also If this is the wrong thread for help on this just say so and I'll bugger off.
Code:
C:\Mining\Mining_Proxy>mining_proxy -o nobl.poolerino.com -p 3344
2014-02-09 15:40:04,392 WARNING proxy mining_proxy.main # Stratum proxy version:
1.5.2
2014-02-09 15:40:04,394 WARNING proxy mining_proxy.main # Trying to connect to S
tratum pool at nobl.poolerino.com:3344
2014-02-09 15:40:04,536 INFO stats stats.print_stats # 1 peers connected, state
changed 1 times
2014-02-09 15:40:04,538 INFO proxy mining_proxy.on_connect # Connected to Stratu
m pool at nobl.poolerino.com:3344
2014-02-09 15:40:04,539 INFO proxy mining_proxy.on_connect # Subscribing for min
ing jobs
2014-02-09 15:40:04,677 WARNING proxy mining_proxy.main # ----------------------
-------------------------------------------------
2014-02-09 15:40:04,678 WARNING proxy mining_proxy.main # PROXY IS LISTENING ON
ALL IPs ON PORT 3333 (stratum) AND 8332 (getwork)
2014-02-09 15:40:04,680 WARNING proxy mining_proxy.main # ----------------------
-------------------------------------------------
2014-02-09 15:40:04,681 INFO proxy client_service.handle_event # Setting new dif
ficulty: 32
2014-02-09 15:40:04,684 INFO proxy client_service.handle_event # New job 69eb fo
r prevhash 015bc6d3, clean_jobs=True
2014-02-09 15:40:13,753 INFO proxy client_service.handle_event # New job 69ec fo
r prevhash 51449bcd, clean_jobs=True
2014-02-09 15:40:17,243 INFO proxy client_service.handle_event # New job 69ed fo
r prevhash 0ea94c57, clean_jobs=True
2014-02-09 15:40:50,599 INFO proxy client_service.handle_event # New job 69ee fo
r prevhash 0ea94c57, clean_jobs=False
2014-02-09 15:40:54,444 INFO proxy client_service.handle_event # New job 69ef fo
r prevhash ccaea273, clean_jobs=True
2014-02-09 15:41:54,464 INFO proxy client_service.handle_event # New job 69f0 fo
r prevhash ccaea273, clean_jobs=False
2014-02-09 15:42:54,497 INFO proxy client_service.handle_event # New job 69f1 fo
r prevhash ccaea273, clean_jobs=False
2014-02-09 15:43:54,533 INFO proxy client_service.handle_event # New job 69f2 fo
r prevhash ccaea273, clean_jobs=False
2014-02-09 15:43:59,726 INFO proxy client_service.handle_event # New job 69f3 fo
r prevhash 115a9906, clean_jobs=True
2014-02-09 15:44:57,822 INFO proxy client_service.handle_event # New job 69f4 fo
r prevhash c8df6893, clean_jobs=True
2014-02-09 15:45:57,881 INFO proxy client_service.handle_event # New job 69f5 fo
r prevhash c8df6893, clean_jobs=False
2014-02-09 15:46:10,204 INFO stats stats.print_stats # 2 peers connected, state
changed 1 times
2014-02-09 15:46:10,206 ERROR protocol protocol.dataReceived # Processing of mes
sage failed
Traceback (most recent call last):
File "stratum\protocol.pyo", line 185, in dataReceived
File "stratum\protocol.pyo", line 216, in lineReceived
'rotocolException: Cannot decode message 'POST / HTTP/1.1
2014-02-09 15:46:10,207 INFO stats stats.print_stats # 1 peers connected, state
changed 1 times
2014-02-09 15:46:10,207 INFO stats stats.print_stats # 2 peers connected, state
changed 1 times
2014-02-09 15:46:10,217 ERROR protocol protocol.dataReceived # Processing of mes
sage failed
Traceback (most recent call last):
File "stratum\protocol.pyo", line 185, in dataReceived
File "stratum\protocol.pyo", line 216, in lineReceived
'rotocolException: Cannot decode message 'POST / HTTP/1.1
2014-02-09 15:46:10,217 INFO stats stats.print_stats # 1 peers connected, state
changed 1 times
2014-02-09 15:46:10,219 INFO stats stats.print_stats # 2 peers connected, state
changed 1 times
2014-02-09 15:46:10,220 INFO stats stats.print_stats # 1 peers connected, state
changed 1 times
2014-02-09 15:46:10,221 INFO stats stats.print_stats # 2 peers connected, state
changed 1 times
2014-02-09 15:46:10,223 INFO stats stats.print_stats # 1 peers connected, state
changed 1 times
2014-02-09 15:46:10,224 INFO stats stats.print_stats # 2 peers connected, state
changed 1 times
2014-02-09 15:46:19,236 INFO proxy client_service.handle_event # New job d088 fo
r prevhash 5cb331fa, clean_jobs=True
2014-02-09 15:46:19,247 INFO stats stats.print_stats # 1 peers connected, state
changed 1 times
2014-02-09 15:46:19,263 INFO proxy client_service.handle_event # New job d1ab fo
r prevhash 5cb331fa, clean_jobs=False
2014-02-09 15:46:57,056 INFO stats stats.print_stats # 2 peers connected, state
changed 1 times
2014-02-09 15:46:59,163 INFO proxy stratum_listener.submit # [599ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:46:59,178 INFO proxy client_service.handle_event # New job d2e5 fo
r prevhash fcc8f87f, clean_jobs=True
2014-02-09 15:46:59,201 INFO proxy client_service.handle_event # New job d40a fo
r prevhash fcc8f87f, clean_jobs=False
2014-02-09 15:47:04,710 INFO proxy stratum_listener.submit # [140ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:47:06,946 INFO proxy stratum_listener.submit # [216ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:47:07,375 INFO proxy stratum_listener.submit # [138ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:47:10,009 INFO proxy stratum_listener.submit # [140ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:47:13,164 INFO proxy stratum_listener.submit # [138ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:47:14,466 INFO proxy stratum_listener.submit # [763ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:47:19,361 INFO proxy stratum_listener.submit # [138ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:47:19,951 INFO proxy stratum_listener.submit # [138ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:47:24,308 INFO proxy stratum_listener.submit # [138ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:47:25,187 INFO proxy stratum_listener.submit # [141ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:47:25,905 INFO proxy stratum_listener.submit # [134ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:47:31,055 INFO proxy client_service.handle_event # New job d53a fo
r prevhash d7f20c22, clean_jobs=True
2014-02-09 15:47:31,075 INFO proxy client_service.handle_event # New job d65c fo
r prevhash d7f20c22, clean_jobs=False
2014-02-09 15:47:33,596 INFO proxy client_service.handle_event # Setting new dif
ficulty: 64
2014-02-09 15:47:33,598 INFO proxy client_service.handle_event # New job d6eb fo
r prevhash d7f20c22, clean_jobs=False
2014-02-09 15:47:33,599 INFO proxy stratum_listener.submit # [163ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:47:34,183 INFO proxy stratum_listener.submit # [177ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:47:34,581 INFO proxy stratum_listener.submit # [138ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:47:39,174 INFO proxy stratum_listener.submit # [138ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:47:40,928 INFO proxy stratum_listener.submit # [138ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:47:43,474 INFO proxy stratum_listener.submit # [136ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:47:44,888 INFO proxy stratum_listener.submit # [139ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:47:57,707 INFO proxy stratum_listener.submit # [145ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:47:58,078 INFO proxy stratum_listener.submit # [137ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:48:03,625 INFO proxy stratum_listener.submit # [140ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:48:09,134 INFO proxy stratum_listener.submit # [138ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:48:12,573 INFO proxy stratum_listener.submit # [139ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:48:15,221 INFO proxy stratum_listener.submit # [696ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:48:19,948 INFO proxy stratum_listener.submit # [136ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:48:27,197 INFO proxy stratum_listener.submit # [138ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:48:27,437 INFO proxy client_service.handle_event # New job d79a fo
r prevhash d9bb6311, clean_jobs=True
2014-02-09 15:48:27,710 INFO proxy stratum_listener.submit # [138ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:48:29,723 INFO proxy stratum_listener.submit # [138ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:48:33,900 INFO proxy stratum_listener.submit # [139ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:48:35,858 INFO proxy stratum_listener.submit # [138ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:48:46,697 INFO proxy stratum_listener.submit # [138ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:48:48,930 INFO proxy stratum_listener.submit # [161ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:48:55,617 INFO proxy stratum_listener.submit # [143ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:48:56,510 INFO proxy stratum_listener.submit # [152ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:49:02,394 INFO proxy stratum_listener.submit # [150ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:49:13,154 INFO proxy stratum_listener.submit # [139ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:49:27,438 INFO proxy client_service.handle_event # New job d8d2 fo
r prevhash d9bb6311, clean_jobs=False
2014-02-09 15:49:35,025 INFO proxy client_service.handle_event # Setting new dif
ficulty: 128
2014-02-09 15:49:35,026 INFO proxy client_service.handle_event # New job d963 fo
r prevhash d9bb6311, clean_jobs=False
2014-02-09 15:49:35,026 INFO proxy stratum_listener.submit # [167ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:49:35,648 INFO proxy stratum_listener.submit # [151ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:49:45,243 INFO proxy stratum_listener.submit # [141ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:49:52,266 INFO proxy stratum_listener.submit # [138ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:50:09,578 INFO proxy stratum_listener.submit # [134ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:50:25,184 INFO proxy stratum_listener.submit # [141ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:50:27,479 INFO proxy client_service.handle_event # New job da11 fo
r prevhash d9bb6311, clean_jobs=False
2014-02-09 15:50:29,683 INFO proxy stratum_listener.submit # [137ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:50:38,388 INFO proxy stratum_listener.submit # [138ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:50:40,944 INFO proxy stratum_listener.submit # [136ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:50:42,368 INFO proxy stratum_listener.submit # [138ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:50:51,589 INFO proxy stratum_listener.submit # [138ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:51:11,061 INFO proxy stratum_listener.submit # [139ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:51:12,618 INFO proxy stratum_listener.submit # [138ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:51:16,069 INFO proxy stratum_listener.submit # [138ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:51:27,500 INFO proxy client_service.handle_event # New job db4a fo
r prevhash d9bb6311, clean_jobs=False
2014-02-09 15:51:38,956 INFO proxy client_service.handle_event # New job dc71 fo
r prevhash 0773d034, clean_jobs=True
2014-02-09 15:51:38,976 INFO proxy client_service.handle_event # New job dd96 fo
r prevhash 0773d034, clean_jobs=False
2014-02-09 15:51:41,375 INFO proxy client_service.handle_event # Setting new dif
ficulty: 256
2014-02-09 15:51:41,375 INFO proxy client_service.handle_event # New job de25 fo
r prevhash 0773d034, clean_jobs=False
2014-02-09 15:51:41,378 INFO proxy stratum_listener.submit # [170ms] Share from
'VikeBeer.7870XT' REJECTED: (-2, u'Share is above target', None)
2014-02-09 15:52:14,697 INFO proxy client_service.handle_event # New job decb fo
r prevhash 0b98dc1f, clean_jobs=True
2014-02-09 15:52:14,711 INFO stats stats.print_stats # 1 peers connected, state
changed 1 times
2014-02-09 15:52:19,302 INFO stats stats.print_stats # 2 peers connected, state
changed 1 times
2014-02-09 15:52:19,302 ERROR protocol protocol.dataReceived # Processing of mes
sage failed
Traceback (most recent call last):
File "stratum\protocol.pyo", line 185, in dataReceived
File "stratum\protocol.pyo", line 216, in lineReceived
'rotocolException: Cannot decode message 'POST / HTTP/1.1
2014-02-09 15:52:19,309 INFO stats stats.print_stats # 1 peers connected, state
changed 1 times
2014-02-09 15:52:19,453 INFO stats stats.print_stats # 2 peers connected, state
changed 1 times
2014-02-09 15:52:19,457 ERROR protocol protocol.dataReceived # Processing of mes
sage failed
Traceback (most recent call last):
File "stratum\protocol.pyo", line 185, in dataReceived
File "stratum\protocol.pyo", line 216, in lineReceived
'rotocolException: Cannot decode message 'POST / HTTP/1.1
2014-02-09 15:52:19,460 INFO stats stats.print_stats # 1 peers connected, state
changed 1 times
2014-02-09 15:52:19,607 INFO stats stats.print_stats # 2 peers connected, state
changed 1 times
2014-02-09 15:52:19,611 INFO stats stats.print_stats # 1 peers connected, state
changed 1 times
2014-02-09 15:52:19,612 INFO stats stats.print_stats # 2 peers connected, state
changed 1 times
2014-02-09 15:52:19,615 INFO stats stats.print_stats # 1 peers connected, state
changed 1 times
2014-02-09 15:52:19,618 INFO stats stats.print_stats # 2 peers connected, state
changed 1 times
2014-02-09 15:52:19,759 INFO stats stats.print_stats # 1 peers connected, state
changed 1 times
2014-02-09 15:52:34,246 INFO proxy client_service.handle_event # New job dff7 fo
r prevhash c0743f27, clean_jobs=True
2014-02-09 15:52:34,267 INFO proxy client_service.handle_event # New job e11d fo
r prevhash c0743f27, clean_jobs=False
2014-02-09 15:52:36,698 INFO proxy mining_proxy.on_shutdown # Shutting down prox
y...
2014-02-09 15:52:36,700 INFO proxy mining_proxy.on_disconnect # Disconnected fro
m Stratum pool at nobl.poolerino.com:3344
2014-02-09 15:52:36,701 INFO stats stats.print_stats # 0 peers connected, state
changed 1 times
C:\Mining\Mining_Proxy>
February 09, 2014, 01:36:21 PM
Question. I have 3 gpu's is it worth pointing at this pool or should I stay with the alts?
With GPU's you are definitely not for BTC (or any other SHA256) mining at this point, no matter which pool.Even if your power is free GPU won't get you enough for withdrawal any time soon and if you want to donate your work to some pool, then pick your own favourite.
thx for the quick reply.
BTW is the mining proxy only for this pool or is it configurable?
I believe that you have to recompile to change where the proxy points. But i might be wrong. There is a thread fro the Slush proxy.
This is the one i've been reading.
http://mining.bitcoin.cz/mining-proxy-howto
You can use it with any pool. Just run the exe with /? (if I'm not mistaken), to print the help. Then give it the necessary arguments to connect to another pool.
I guess you running blades or cubes. I use two different methods, right now I'm using bfgminer as a mining proxy.
like this: bfgminer -o stratum.bitcoin.cz:3333 -u your.username -p minerpassword --http-port 8332 --api-listen
It's the --http-port flag that makes bfgminer to a proxy.
To mine at ghash with the mining_proxy made by slush: mining_proxy.exe -o uk1.ghash.io -p 3333
One thing to note is that only the proxy tool supports longpoll on the cubes, for blades it doesn't matter. I don't really know what longpoll is, but the info I got on another thread was each cube works best if it is running on a dedicated launch of the proxy tool, and the way to separate them is with using a different port switch for each.
February 09, 2014, 11:06:14 AM
Depends on whether other pools/miners are adding power even faster, which appears to be the case.
Until the difficulty changes this is not the case - if other pools add more power they will just find blocks more often, but will not affect our times in any way ... only after the difficulty changes we will be affected.If a pool is X Th/s and the whole network is Y Th/s at the time when difficulty changes (i.e. diff is based on Y) it will find 144*X/Y blocks daily.
If the network remains at Y Th/s all pools will find 144 block daily.
If the network is Y+100Th/s (and those 100Th/s were added to another pool) our pool will still find the same amount of blocks per day, but the whole network will find more - 144*Y/(Y+100Th) and those excess blocks will go to that other pool
February 09, 2014, 10:05:55 AM
Just because they're paranoid doesn't mean that someone's not out to get them!
Jump to: