Quote from: J_Dubbs on February 10, 2014, 06:30:50 AM

Quote from: eleuthria on February 10, 2014, 03:59:31 AM

Quote from: J_Dubbs on February 10, 2014, 01:25:38 AM

Quote from: dlefevre on February 09, 2014, 10:30:32 PM

Quote from: J_Dubbs on February 09, 2014, 06:36:21 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.

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.