...and they are all running through Slush's proxy (one for each, different ports) on an older laptop.
Why are you running separate instances of the proxy? You should only be running 1 instance of the proxy for any number of cubes. I have 3 cubes and 1 instance of the proxy and I get >32GHs on all 3 cubes.
Regarding running slush's proxy on RPi. I haven't seen anyone reporting more than 1 cube on an RPi getting full hashing rate. I tried my 3 cubes on RPi and it pegged the cpu 100% and hash rates were < 16GHs. I have not yet tried bfgminer proxy on RPi. I might get around to trying that tomorrow.
so if you have 3 cubes connected to one single proxy they will appear as one worker to the pool
I actually run 3 instances of bfgminer proxy on my pi, each using about 10% cpu. still way less than slush's so I can use three command lines
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.
I dunno, sounded right to me so I went with it... I'd love to just run one proxy though as it will simplify things... Maybe it's splitting hairs and only a small improvement?