[4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool

[dlefevre]

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.

[J_Dubbs]

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.

[eleuthria]

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.

[bspurloc]

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

[J_Dubbs]

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.

[J_Dubbs]

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

[J_Dubbs]

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:

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.

Link: https://bitcointalk.org/index.php?topic=352658.msg4369389#msg4369389

[Trefdraeth]

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. 

[organofcorti]

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

[Trefdraeth]

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! 

[Mudbankkeith]

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?  ..............  ...............?

[dlefevre]

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.

[Scyntech]

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?

[organofcorti]

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.

[Mentalfloss]

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.

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.

[manubar82]

second maintanance for the mining page today. Is there any Problem we should know about?

[KNK]

second maintanance for the mining page today. Is there any Problem we should know about?

Is it necessary to be a problem?
 I guess the devs are adding new functionality or optimizing an old one ... by knowing how sensitive the visitors are it is better to disable the page, than showing a wrong result even for just a fraction of the second.

[eoakland]

I was fortunate enough to be here during the sad spell few days ago, jumped, pool got hot, came back....and I am the cooler----blame me everyone.

got to love these super long, energy consuming, cost more in electrical consumption than actual reward blocks.  sweet chin music in my face !

[necro_nemesis]

second maintanance for the mining page today. Is there any Problem we should know about?

Other than being able to mine bitcoin for profit?

If it's any consolation anytime I've witnessed the site go under maintenace it appears to come back where you would predict it to be at. I assume the site is simply a representation of the mechanics behind the pool's operations which are independant of it.

[dlefevre]

I was fortunate enough to be here during the sad spell few days ago, jumped, pool got hot, came back....and I am the cooler----blame me everyone.

got to love these super long, energy consuming, cost more in electrical consumption than actual reward blocks.  sweet chin music in my face !

Yeah.  I have worked to keep my calm and not jump because of long blocks.  I learned that when I moved from Eclipse to here because Slush was right in the middle of a good string of good luck and I thought it was normal!  Still glad I moved, though.

My personal philosophy is that one of the good reasons to move pools is bad management.  I moved from Eclipse because of a protracted string of bad decisions and a protracted period of time that their system would not pay out properly.  I didn't know at the time that Eclipse has such a close relationship to BFL, so after learning that I will never go back there at all.  You have to have trust in the pool's management as the pool operator has the ultimate control.  If they appear to be dishonest in any way (like BFL's constant dishonesty) then THAT is a good reason to move.