I have personally experienced issues running multiple blades and cubes with BFGMiner. Hashrate was reporting about 5-10% slower from BFGMiner interface and blade/cube interface. Additionally, when I was running 10 blades on a single bfgminer instance, 2-3 would lose connection to the proxy and report as dead from bfgminer interface after about 10 hrs of running. I've had multiple users report the same issues, which were resolved by switching to slush's stratum proxy. Based on those results I cannot recommend BFGMiner for blade/cube operation, although I would love to see it working without issue in the future. Unfortunately, I do not have the bandwidth at this time to work with you to determine the cause.
I post this in case others may not be aware as I just learned it myself.
When using the slush stratum proxy you of course need the server ip of the blade/cube to point to the ip of the computer the proxy is running on, but need to use real user_worker:123 for the pool it is pointed at. On multiple blades it would be the same.On bfgminer, you MUST have unique user names for each blade/cube which is different then using slush's. If you don't, you will see a drop of 10 to 20%.
Again I apologize if this is old hat, but I was searching the bfgminer section for "blade" to see what I missed that they were not running at top speed and found this:
https://bitcointalk.org/index.php?topic=168174.msg3391532;topicseen#msg3391532End result is on bfgminer you end up with a PXY for each blade/cube if you don't have a "PXY" for each cube/blade then you have duplicate id.s.
hit "d" for device manager and use the arrows to see what each "logged" user name is.
my blades for example are assigned .40 up so with bfgminer, the user:pass field if just use "bladexx:123" where xx is the ip of the blade to keep them unique and simple.
Sorry if this wasted space.
Thanks for being very supportive to your customers. However, I suggest to be more specific as to which CL or interface (BFGMiner, Slush's proxy or Cube/Blade) these data (highlighted above) are to be applied into and to which specific "fields" (IP, Mask, Gateway, WEB Port, Primary DNS, Secondary DNS, Pool ports, Pool addresses or Miners user:pass) on the Cube/Blade browser-based configuration interface they would be put in. It seems that most of the tutorials/instructions on these forums assume that the reader is a seasoned miner or an accomplished coder; not good for noobs or coding or CLI-challenged or just mainstream less tech-savvy folks (I'm one of them though I've managed to get my miners running inspite of the fact with trial-and-error method and through sheer determination, perseverance and by asking specific questions on here
). The Cube interface alone has at least four fields that deals with IP addresses and it doesn't help when field labels are substituted by a totally different set of terminology (though relatively comprehensible to a very tech-savvy miner). For example: "server ip of the blade/cube" could be misconstrued as any of the IP-related fields on the Cube interface.