Quote from: stewdk on January 08, 2014, 01:19:22 PM

Quote from: Shaker242 on January 08, 2014, 12:35:13 PM

I've seen a couple posts about stratum proxies only being used for 1 to 2 cubes, but after monitoring my slush proxy while a single cube is running at 31Ghash/s... I'm seeing a very small load, thus one could reason that I should be able to run a lot more cubes through it. I just ordered a couple more, so when they get in... I'll update this with the proxies performance. Based on the numbers I'm seeing, there is no reason the proxies couldn't handle quite a few cubes.

* I am switching everything over from monitoring on SSH to SNMP; so please ignore the "?" on physical memory... the SSH Meminfo 3 shows that only 25% of 1GB is being utilized currently. Load average is < 1, CPU utilization is only 8% and network traffic is only 261kbits/sec (that is 0.03 MB).

The problem with running multiple cubes through a single instance of slush's proxy isn't bandwidth, or even CPU time necessarily (unless you're running it on a raspberry pi). It's when you have the proxy pointed to a pool with vardiff (like slush's pool) and each worker gets assigned a different share difficulty. This happens even if each worker has the same hashing power. The proxy gets confused by different share difficulties per worker (software bug) and doesn't submit any shares with a difficulty lower than the difficulty of the worker with the highest share difficulty assigned by the pool, even if that lower difficulty share is valid for that particular worker. This may seem like a corner case, but it most definitely results in lost/unsubmitted shares, which directly affects your worker hashrate and profits. twib2 reported a 5% increase in total hashrate when switching 5 cubes from a single proxy to a proxy for each cube.

Now that does put things in a different light, thank you. The software's punitive features seem like a pain then; has anyone evaluated running multiple instances of slush's proxy but on different ports... like the --gp 8332, --gp 8333 etc? Or do you believe this would likely not provide better results? I'm curious to try spinning up multiple instances in this case, along with splitting out the workers (obviously) would be a 'work around'? It's not really a big deal, since I'm running VM's anyway... but I'd like to have a systems that's efficient.