Just wondering, what you see on the horizon, Doc - are we going to turn over a new leaf anytime soon? Hit some fast blocks? We've been way below expected average for quite some time now...
My Crystal ball remains opaque, damn it

My long-term stale rate remains at a very decent 0.13%, thanks for all the hard work on the pool server.

Yes, the default config (cgminer.conf) if it's able to find one.

NVidia's dual GPU (GK-104) reported to be scheduled for May.
I don't think AMD will want to trail nVidia's offering longer than a month for both revenue and marketing reasons.

Those insanely expensive enthusiast cards generate the most revenue per unit sold and having spearheaded the introduction of the 28nm GPUs to the market AMD won't delay their dual GPU cards for an extended amount of time and allow nVidia to take the lead by default.

Personally, I'm waiting for June with my mining hardware purchases...

A great idea but much less flexible than a hidden OS.

A vanilla liveCD/USB would need to be reconfigured each time it is launched - you'd need to store the necessary packages somewhere.
Downloading TOR and/or other non-standard tools moments before hiding behind them isn't exactly the best of ideas.
Setting up all the necessary tools each time is not only tedious but error prone - think of the consequences of inadvertently missing a step.

A persistent liveUSB is a great tool able to remember the changed packages and configuration but since it's not full-disk encrypted, its purpose is obvious to any onlooker.

If you deploy TrueCrypt in FDE-mode and create a whole hidden operating system, as long as you don't do something dumb (anyone interested in the topic should carefully study the documention) no force on earth can prove the existence of this OS.
If you're forced to decrypt - e.g. while crossing a border, you decrypt the day-to-day (decoy) system containing no sensitive information.

On Linux you might issue the following one-liner:
wget https://github.com/ckolivas/cgminer/zipball/master && unzip master && cd ckolivas-cgminer* &&  cp ../adl_includes/adl_* ADL_SDK/ && ./autogen.sh && CFLAGS="-O2 -Wall -march=native" ./configure && sleep 4 && make && cp cgminer /opt/bcm/cgminer && cp *.cl /opt/bcm/cgminer && cd .. && rm -r ckolivas-cgminer* && rm master
It's all explained in the README.

On Windows, do yourself a favor and just download the already compiled version.

Oh, one other thing:


Do you know what the difference between "black-hat" and "black-hat style" is? A great deal of knowledge and experience.
Still, black hat hackers do get successfully prosecuted when they break the law.
Don't expect that simply following any guide - no matter how good it might be - will be enough to make you immune.

[Encryption]
The TrueCrypt tutorial seems to be the weakest part of the whole howto. You should really study the documentation and use that tool to its full potential.

Ummm... disabling the swap file?
Ever heard of deploying full disk encryption (FDE) instead?
You need to set up FDE and two operating systems: the overt one (the system to be used for day-to-day activities) and the concealed one (the one with virtual machines and stuff).
This can be easily achieved with TrueCrypt, and unless you screw something up you should maintain plausible deniability.
FDE makes the whole step 3 (Securing Your Hard Drive) pretty much moot.

Be advised to disable standby on a FDE-secured machine - when that machine sleeps, the FDE keys are still in RAM.
If using Windows XP, Server 2003 or earlier, disable hibernation as well - as there is no API for performing crypto operations on the hibernation file, full security cannot be guaranteed.

Don't forget to mention that there are automation settings for that in TrueCrypt preferences.

[Data sanitization]
If the disk needs to be sanitized, do so before messing with encryption. Consequently, step 6 should be moved to position 0 in your tutorial.
Copy the sensitive data to another (encrypted) medium, backup valuable non-sensitive data, and sanitize the drive.

File shredder... really?
Why not just hose the drive with random data? Be advised that everything on the drive is about to go bye-bye.
dd if=/dev/urandom⁽¹⁾ of=/dev/sdX ... ; repeat until satisfied.
If you don't feel comfortable with linux use DBAN.  
If you do that, no force on earth will be able to scrub any old data off that drive.
By all means do install a file shredder in the OS but use it as an emergency tool.

Don't use SSD drives for storing sensitive data - due to the nature of their operation (wear leveling algorithms and controller-level compression) you can never guarantee full erasure.
Don't use damaged hard drives developing bad sectors - once a bad sector has been detected and replaced the only way to write to it is to use specialized low-level software.
SpinRite can be used to reinstate bad sectors into service. It is not cheap, however.

[Cryptography limitations]
Don't expect cryptography to save you if you get identified as the perpetrator of an unlawful act.
Depending on where you live, you might be compelled by law to hand over all decryption keys to the LE (law enforcement) agency.
The investigators might threaten and intimidate you into releasing the keys. Rubber hose cryptanalysis is a powerful tool.

You never mentioned such basic aspects of security as physical security - a LE agency investigating you might plant a (hardware?) key logger or surveillance cameras to capture your precious passwords.
How lamentable will your situation be if you rely solely on TrueCrypt, oh my  

I guess what the last paragraph amounts to is, please don't break the law - for your own best interest.
Let this be my final piece of advice.

Notes:
(1) Frandom is an order of magnitude faster than /dev/urandom. Good stuff.

I believe Gigavps knew what he was talking about when he specified 83W per device.

The power draw of the FPGA can be easily measured using a clamp meter or by feeding it from a well-known PSU you have the efficiency charts for and looking at the kill-a-watt readings.

Running the FPGAs with an ATX PSU has another benefit: the ATX spec mandates very tight voltage regulation - probably much tighter than any wall wart is capable of.
The cleaner the power, the less load is being put on the onboard voltage regulators.

PS. When BFL issued a statement regarding the power usage they were promising 19,3 watts IIRC

Try increasing the memory clocks on that card, that might take care of the screen flicker.
I've encountered such behavior once when I downclocked the memory in the BIOS and ran a Windows7-based test miner.
When I loaded the default vBIOS settings the flickering stopped.

The manufacturer promises 83 amps - that's 996 watts at the +12V output.
As DAT rightly noticed, this is a single rail unit so no additional rail topology issues for you to overcome.

HARDOCP were able to squeeze 100% load out of the unit at 84.9% efficiency (120V AC voltage) but while doing so they measured ripple in excess of 130mV at the 12V output. Temperature delta at exhaust was 20°C.
When using 100V AC input voltage, the ripple rose to an ungainly 390mV - over three times more than that ATX spec allows (120mV max) and six times worse than the Superflower Golden-Green-based Rosewill Lightning 1300W (available for $250 from NewEgg).

The design was clearly beyond its comfort zone when delivering 100% of the advertised load.
Your total load, however, should never exceed 990W (11 singles at 90W). Typically it would be closer to 910W.

You should be able to get away with that PSU but I'm not entirely comfortable recommending it as it's an ATNG-made device - this particular OEM doesn't exactly have a history of stellar-quality builds.
It's a bit of a wild card and it's very hard for me to estimate the longevity under 910W+ load 24/7.
Personally, I'd go with a stronger design - although the price is tempting remember that the FPGAs are very expensive and the $100 saved on the PSU doesn't justify the risk of destroying your singles in a catastrophic PSU failure.


DAT, is this the picture you were looking for? I'm glad to be of help.

My last post in this topic, I swear.

150W is only 12.5A - no contemporary PSU has OCP limit that set low.
While it's true that 150W will always work I'd like to point out that more power will always be available.
The information how much more load the rail can handle is right there on the side of every PSU in the load table: read the amperage, divide it by 12 and voila! - you know how much power you can pull without tripping the OCP.


Please note how counterproductive sticking to 150W per PEG connector is on high-end single rail PSUs miners have heavily invested into: you'd be using less than 40% of the power available through the PEG connector.
Maximizing the number of FPGAs per PSU is very important for anyone building an FPGA farm and following my advice allows to do that cleanly, without using unnecessary cables or gadgets like molex adapters - that was my entire point.


Let me draw an analogy - 640x480 is a standard resolution any monitor in the world should be able to display.
You're saying "Stick to 640x480 and you're guaranteed universal compatibilty".
My advice is "Any contemporary device can do better than that. 640X480 is counterproductive as heck so read the manufacturer's paperwork to find the maximum safe resolution (load per a 12V rail powering the PEG connector) if you need more".

Cryptography as a hobby, Lord save us

The last time incompetent folks⁽¹⁾ tried to tackle cryptography WEP encryption standard for Wi-Fi networks was developed. The authors fell into disgrace and were sorry ever after.
Mind you, WEP did use very decent crypto at the time (the RC-4 stream cipher is "military-grade", it just was employed in the wrong fashion).
Cryptography is a means to an end, not a design goal by itself.

1/10 for not going with a Windows box as the server. That's gotta amount for something - at least the service won't catch a worm all by itself.

Notes:
(1) very competent hardware and radio engineers, just no security experts

You imply that delivering more than 75 watts through the PEG-6 connector is in violation of the spec.
For the n-th time, the spec regulates the GPU, not the connectors.
For reasons already stated, the PEG-6 connector is electrically capable of delivering over 400W and it will do so unless the rail it's feeding from has a lower OCP limit.

As to the merit of the whole discussion, let's assume we're using BFL FPGA devices each drawing 90W.
You imply that a single PEG-6 connector could at most power one such device and would be overloaded doing so (75W vs 90W).

I have shown that the PEG-6 connector can safely run three BFL FPGAs, each of them feeding off its own 12V wire (there are three of those).
All that without "hacking" or "gotchas" you accused me of, all in-spec.

With some additional work (merging the three 12V wires' output together and feeding the FPGAs from that) the same PEG-6 connector can safely power four BFL FPGAs without getting close to manufacturers' ratings for the wires or contacts.

Damn it, it is a QUAD rail PSU you're linking to.
Four 12V rails with their individual OCP limits to worry about instead of one!

Look at the load table:
[  3.3V  |  5V  |  12V1  |  12V2  |  12V3  |  12V4  ]
[  25A   |  25A |  30A   |  30A    |  45A   |   45A   ]

Try actually reading the site you're linking to:
The "Easy Rail" is just meaningless marketroid blabbering with no real life implications.
XFX used to use this keyword to indicate single-rail devices but apparently every PSU they make is now advertized as Easy Rail, no matter the number of rails.

DAT, please... take a deep breath, re-read the spec, and ponder on it for a while.

Current version of the ATX spec abolished the 20 amps per rail limitation.
The 20A per wire limitation still stands but it's so much higher than the 13A Mini-Fit Jr per-contact limitation that it's pretty much moot - we can't violate this limitation without burning the connector first.
This 20A per wire limit is not enforced on hardware level.

A single-rail PSU does not measure the load at any individual DC output, only total OCP (over current protection) is hopefully active (BTW, I never advocated crossing the global OCP).
That's precisely the difference between single rail and multi rail devices: a multi-rail PSU measures load levels at each configured virtual rail.
I said that in the case of a multi rail PSU you need to take the per-rail OCP limit levels into consideration.

I don't like repeating myself but let's look at what I disagreed with you about:

You said that a PEG-6/8 connector is only good for 75/150 watts (6.25/12.5 amps).
Using ATX spec and manufacturer data I proved that neither the wires themselves nor the connectors are limited to such low amperage.
With three 12V wires, the PEG-6 connector is in ATX spec until 60A wire-wise.
The connector contacts max out at 13A thus limit the connector to 39A (468W). I suggested a safer value of 375W as the one to go with.
A multi-rail PSU might impose a current limit on the rail, e.g. 25A (300W) but a single-rail device cannot.
Here are a few examples of how single rail PSUs are wired up internally - take a glance at the PCB pictures, see how the wires are soldered in together.  If you ever took a class in electronics and circuits or electrical engineering the PCB picture should tell you a lot.

I know you're an expert in software and not in hardware but that's really all there is to single rail PSUs. Not exactly rocket science.
A single-rail unit cannot shut off because one of the connectors is overloaded as long as it's not overloaded high enough to trip the global OCP limit.

The ATX spec limits the PCIe devices, not connectors. Re-read it if you don't believe me.
That's the only thing I disagreed with you about.

TL;DR
There's no hacking involved nor "gotchas".
When using a multi-rail unit, you need to be aware of the individual per-rail OCP limits.

In a single-rail device the only limit you need to worry about is global load - a sum of all DC outputs.
A connector consists of wires (the spec mandates 20A per wire limitation but no PSU actually checks that) and contacts (the Mini-Fit Jr HCS are rated at 13A each).
The ATX spec limitation of 75W/150W applies to devices, not to connectors.
Electrically, the PEG-6 connector is capable of 468W. I suggested 80% of that value as a safer load.

Speaking of wires, this is never a good sign:

Each PEG connector should come with its own wire to prevent overloading the PEG connector closest to the PSU.
This is another sign of a manufacturer going cheap.

If I had a PSU like this one and had to push the PEG connectors hard, I'd disassemble the PEG connector and apply solder to the place where both wires are crimped to the contact in order to minimize resistance.

Sorry, you're just plain wrong.

For the ease of explanation and without loss of generality let's assume our PSU is a single rail, non-modular device.
All the wires are soldered at the same place of the PCB.
Ever seen an open PSU, DAT? A whole bunch of 12V wires are soldered in one place, usually using very generous amounts of solder to improve the wire-to-wire electrical interface.
The same goes for ground wires - they all end up at the same spot.
The PSU circuitry doesn't know or care whether it delivers 375W across two PEG connectors and a bunch of molex 4 pin peripheral connectors or just one connector.
The PSU was built for one assumption only: to deliver 100% of the rated power as cleanly as possible - this is a prerequisite for receiving the 80 PLUS certification.

While it is true that the wires themselves have their rated amperage it is much higher than the rating of any commonly used connector and could only pose a problem if the manufacturer used substandard cabling. The spec recommends 18 AWG as the minimum wire gauge and only crappy low-end, low-power units are equipped with 20 AWG wiring when the manufacturer needs to cut corners.

The situation gets slightly more complicated when a multi-rail device is used: you need to know the shutoff threshold for the virtual rail you're drawing power from.

A modular PSU includes an additional potential point of failure - the modular board and connectors.
These are most often the same Mini-Fit Jr, HCS variety as the PEG-6 connector so no problem here.
Should the manufacturer go with some non-standard design, it's up to the user to parse the relevant specs and verify how much power the connectors can deliver.

Cgminer is the one to choose when looking for military grade functionality.
BitMinter's java-based client OTOH is the one to pick when in need of "military grade" ease of use

Thanks for the links Simon.

Ummm... you wouldn't be using a 32-bit version of Windows? x86 Windows is limited to 4 GPUs, you know. That's only two 5970 cards.
Else try out a few Catalyst versions, by all means - I'm surprised you haven't done that already.