alias rbcm='screen -d -r cgm'

You don't want to go the '-d -R' way because -R would even create an empty screen session which won't help.
If there's no screen session that means cgminer must have died so we need to run the miner-launcher.sh

If for whatever reason the miner software gets unstable and keeps dying every now and then defining
alias nrbcm='screen -d -r cgm || miner-launcher.sh'
might be useful (n as in necro rbcm - raise from the dead if necessary )

I have a strong dislike for cleat text passwords stored in config files.
Access rights need to be very cautiously set on all such files.

True, once the attacker gains shell access, you're in deep trouble.
Your trouble can easily get much deeper, however, when the adversary finds clear-text login credentials in some script or config file (e.g. a password for the corporate database...)

Clear text passwords can really make your day when for whatever reason you're unable to grab the elusive root.

Oh, one other thing.
If having to constantly type screen -r cgm is bugging you, a good solution might be creating an alias in your .bashrc file.
You need to append the following line to ~/.bashrc:
Your system just learned a new command: rbcm (as in reattach bitcoin miner) will be translated to screen -r cgm.
Nifty.

Just keep in mind that when you su as root, you use root's home directory instead of your own so you need to update /root/.bashrc with that alias as well.

I admit it's going overboard but for the sake of elegance and clearly divided code I suggest you go with three files:
/etc/rc.local for autostart,
/usr/local/bin/miner-launcher.sh as a generic launcher you will invoke if you ever need to restart your miner.
/usr/local/bin/startcgminer.sh for launching cgminer. Cgminer technicalities belong here.


/etc/rc.local should include this line, let's keep it clean:
That 60 is passed as a parameter to miner-launcher. It will be used for specifying how long miner-launcher should wait before starting the miner.
The ampersand returns control to rc.local at once, without waiting for the whole minute until miner-launcher is done with its work.


/usr/local/bin/miner-launcher.sh might look something like that:
The miner-launcher might be upgraded to take a username or miner-dependent script as parameters. You could then call miner-launcher.sh startcgminer.sh or miner-launcher.sh 15 startdiablominer.sh to launch your miner of choice.


/usr/local/bin/startcgminer.sh is a good place for the implementation details:

You need to make /usr/local/bin/miner-launcher.sh and /usr/local/bin/startcgminer.sh executable:
chmod +x /usr/local/bin/*miner*.sh

Make sure the files are owned by root (it's insecure to have user-writable executable files in system directories):
chown root:root /usr/local/bin/*miner*.sh


When you kill cgminer, simply invoking miner-launcher.sh will launch a fresh instance of screen for you and execute your favorite miner inside.
Since the -m argument is passed to screen, screen will die together with cgminer.


Am I forgetting something?? Uhmmm... don't think so.
Will this work as is, without any additional tinkering or debugging? This better work or else  

If you have a VPS with a statically-assigned IP somewhere, you could tunnel your dynamic-IP 3G traffic through an easy to configure SSH tunnel.
To the miner it will look like the traffic originates at the whitelisted VPS.

If you don't wish to set up a VPS or if you want to be able to use the API with --api-allow W:127.0.0.1,192.168.1/24" configured (LAN access only) while you're off-site you will need to set up a VPN server.
While configuration-intensive and sometimes tricky to get going, a VPN will massively boost the security of your network - no need to even open the miner's ssh port to the general internet population.
If you're using a mid-to-high end router, it might already have a VPN server built in.

Passwords may not the be the best approach when stored in plain-text form in some config file and not encrypted in transit.

Which part? There is no substituting the command like screen -dmS miner startminer.sh


What can be changed, is the manner in which the above command is invoked - on my Debian-based machines, rather than launch cgminer via /etc/rc.local and call it a day I've set it up to start as a system service. With some scripting this allows me to do control it like any other OS daemon, e.g.

Cgminer is only invoked via an intermediary script, /usr/local/bin/bcm-start.sh, which can launch a whole array of miners (the other ones being phoenix, diabloMiner, and ufasoft's cpuminer)
This way, whatever miner I want to launch, I don't have to mess with the /etc/init.d files.

The X.org server - a prerequisite - is being launched the same exact way.

The logging module is also tightly integrated into the system, logging some pertinent parameters of the mining rig with a 6 minute interval.
Cgminer output is being kept on-record as well so that it is easily accessible should errors crop up and need to be trouble-shot.


To ensure update flexibility and safety, I have been using the following set up:
Four concurrent versions of cgminer can coexist; they are labeled cgminer-stable, -testing, -oldstable, and -oldtesting and reside in their own respective directories.
Upon being installed, a new cgminer compilation is assigned the testing status by default.
Its status can be changed, e.g. to stable at any given time.

All cgminer calls are processed via a symlink named cgminer-current which always links to one of the four directories.

To make sense of four cgminer executables which can in some cases have the same version number but are based on different git commits, I needed to create an automatic cgminer installer (cgminer-update.sh) which creates the version.info file (containing the git version) in the installation directory.
A fresh copy of cgminer source will be downloaded from git, compiled and automatically installed into /opt/bcm/cgminer-testing.


I find it that such a tight integration with the OS is the right approach to take in machines as purpose-built as mining rigs are.
I tried hard to fit miners and miner control into the OS as snugly as possible, to stay true to the "Debian way" - whatever is might be


If anyone's interested, I might write a guide and share some code... just give me some time to do that, a week or two⁽²⁾ as I do have a day job and other real-life commitments...

Does anyone want this?

Notes:
(1) actually, the user is also being changed with su bcminer so that cgminer doesn't run as root which would be a horribly wrong idea from the system security standpoint.
(2) ummm... how does a "4 to 6 weeks" timeframe sound to you, guys?
    

FYI, Thermaltake does not make PSUs, not a single one. They contract the PSUs out to oem manufacturers. The Thunderbolt series is made by Sirfa. Your Toughpower was manufactured by CWT.

Do check the voltages with a multimeter and inspect all connectors visually to make sure no contact was damaged during the installation.
You didn't forget to plug in the 4-pin ATX/ 8-pin EPS connector, did you?

Personally, I wouldn't touch Litecoin with a 10 feet pole...  failing to offer a single feature which Bitcoin would lack it just has no niche in the ecosystem.

Being CPU-mineable is totally irrelevant - when all's said and done it's just another Bitcoin clone but with little to none foothold in the market space.
As a business, why would I choose any of the current alt-coins over Bitcoin?

Hey, he said it was a Windows based machine...

On a more serious note, up to 170W per a 5830 card, 150W for each 5850, 180W for a 100%-loaded 6 core Phenom (up to 270W when overclocked to 4.1 GHz), 20 for fans and drives...
OP should have no less than 1kW of juice at the ready when the cavalry... uhmmm... 5850s arrive.

Naturally, see the Init Display First setting.
The order cards are initialized in is reflected in the BIOS device map (that measly 64k of memory which tends to get clogged up with the unnecessary mobo "goodies").

Some better-behaved bioses actually allow you to choose PEG1 or PEG2 (as in PCI Express Graphics) as the primary device.
I've yet to see a bios allowing me to select any PCIe slot for the primary GPU.

The bounty be damned, I find it more interesting whether the malfunction was caused by the bios flash or mining.

I never damaged any of my cards but there have been failures aplenty reported in the forums.
One user reported 10 out of 10 failed GPUs after 6 months of mining - surely, he must have done something wrong.

Your cards seem to have had an easy life being undervolted and only slightly overclocked.

Since you mention this was a specially crafted BIOS, the failure is either mining-related or just random.

I don't feel like digging through spec sheets, doesn't it take a Faildozer^WBulldozer-based CPU to get amd-vi (AMD equivalent of VT-d)? Ugh...
Intel is even worse as even some of their server-grade CPUs lack VT-d support.

Just run GPUz and check the clocks and voltages.
Post a screenshot here if you're unsure what to look for.

lmao

Provided you don't waste power by e.g. by CPU mining Litecoins, easily.
A 5970 shouldn't pull more than 250 W with its memory underclocked.
With 120 W for the rest of the system, the PSU load would be 82,7% - not unreasonable for a high quality PSU such as the ZT 750W.

Make sure that the CPU power save options (such as SpeedStep or C1E) are enabled in the BIOS.

Did you unlock by reflashing with a 6970 bios?

The 6970 cards use higher-grade memory chips than 6950, thus a bios flash would set higher memory voltages and clocks than the 6950 memory can handle.
This approach is widely known to be potentially lethal to the card, that's why alternative means of unlocking were devised (e.g. the RBE method).
Once the damage is done, nothing short of replacing the failed memory chips can help.

Mining uses next to no memory at all, therefore as long as the physically first memory chip on the card is operational the card will work fine.

Also, remember never to use high overclock settings used for mining for playing games - games use other areas of the chip than only the stream processors which may not like the insanely high clocks.

You're probably guessing right. Don't worry, all in all 266 MHash/s isn't that bad for a 1120 SP card employed in a non-dedicated machine.
For a dedicated rig, however, anything lower than 300 MHash/s is inexcusable unless the card is heavily undervolted.

I really doubt it's the worksize that caused the reject rate to go up. A random packet storm seems more plausible. Care to retry?
If you happen to be using a 12.x drivers X 2.6 sdk combo --vectors 4 and --worksize 128 might boost the hash rate somewhat.

It won't make up for high network latencies and the shares which turn stale in transit.
Give it a try, just don't expect miracles.

It's for the very rare occasion where cgminer might miss an opportunity to score a share when it thinks it is already stale and doesn't send it out but the pool would have accepted it.
The SS counter in cgminer windows tells you how many times cgminer didn't bother with sending a calculated share.

You can't cheat any pool because if the share is indeed stale, the pool will just classify it as such.

P2pool is specific because it uses a much higher difficulty than the rest of the pools, therefore all shares are of a much higher value.


Conman, I don't feel like delving through the code right now but wasn't the fact that --submit-stale influences Utility the reason it's off by default?
I mean the situation where a share that would otherwise be locally discarded gets sent out increasing the [ U] rating even though that share gets tossed away by the pool?

You're a coding monster, Con. With all those updates it's hard to keep up.
Thanks.