It would only be the right way if the cards were worth nothing.   However I suspect they are worth something, and the more you use them and the longer you wait, they are worth less and less.

And the vast majority of Americans and Europeans are paying US>10c/kWh.  Even up here in the Great White North, you'll only find rates substantially below that in Manitoba and Quebec (and maybe still in some parts of Labrador).  In the big American cities, electricity is over US 20c/kWh.

And when I checked your numbers, it looks like you're only factoring the electricity costs, and nothing for depreciation.

I suspect you're in somewhere like Washington state, which has some of the lowest electricity costs in North America.  So if you're in Grant County, sure mining ETH is clearly profitable, but for the other 99.9% of the population, it ain't so easy to make money mining.

http://www.hydroquebec.com/data/documents-donnees/pdf/comparison-electricity-prices.pdf

It takes some time, but you can find most of the info in this and other threads on bitcointalk.  For example, you have to be very careful changing CAS timing, since one part of the strap contains the mode register settings that program the actual GDDR chips, and another part of the strap programs the memory controller CAS timings.  Wolf noted that you can usually get away with the two timings being one clock cycle off, but any more than that and you are pretty much guaranteed to get a crash.

Not a full dump, but some of the key strap timings:
https://github.com/nerdralph/amdmeminfo

@MoneroCrusher I know you already found my amdmeminfo fork, so this is more for other readers of this thread.

You don't need four wavefronts to saturate the VALU.  I explained that in an old blog post:
"Note that some sources state that full SIMD occupancy requires four waves, when it is technically possible with just one wave using only vector instructions."
http://nerdralph.blogspot.com/2017/02/inside-amd-gcn-code-execution.html

I realized a long time ago that the key to optimal ETHASH performance is not getting more waves, it's optimizing the pattern memory accesses across the CUs to avoid contention.

Maybe they mean the VU31P and not the 13P?  The 31P has 4GB of HBM2 memory, which would be better for equihash than the VU9P.

Monero(Cryptonight) can't be compared to ethash, as the algorithms are very different.  If you are actually interested in understanding ethash (& equihash) look at my posting history as I've analyzed both in-depth as well as done a lot of kernel coding.  Ethash also doesn't have botnets like Monero, which is likely where much of the hashrate drop came from after the fork.

You're basically doing a better job proving yourself wrong.  GPUs have been back-ordered due to high demand from mining; AMD can't ramp up production fast enough to keep up with demand.
"Revenue was $1.65 billion, up 40 percent year-over-year and 23 percent quarter-over-quarter, driven primarily by higher revenue in the Computing and Graphics segment."
http://ir.amd.com/news-releases/news-release-details/amd-reports-first-quarter-2018-financial-results

It's correct for what it is reporting.  As you pointed out, often people are just looking at the power consumption of the GPU, from the output side of the VRM.  Power to the input side of the VRM will be ~10% higher, and there is a separate VRM for the RAM.  There's usually one or two more power rails as well, but their power consumption is minor compared to the GPU & RAM.

The performance/efficiency tradeoff in ethash is becoming less significant with newer hardware.  With a R9 290 card it was very difficult to maximize performance without increasing power consumption.  With Polaris, where performance is mainly limited by memory and not the core clock, it is much easier to get near peak performance with minimal power.

That said, I think there is room for some tangible improvements in ethash (and probably cryptonight) mining efficiency through optimizing the mining kernel.  For example a Rx 580 doesn't need active 36 CUs to do 30Mh/s; it's closer to 1 CU per Mh.

Equihash (zcash) has more room for optimization in an ASIC than ethash.  The first round in equihash is dominated by blake hash speed, which is much faster in an ASIC than a GPU (and Bitmain already has blake miners).  The subsequent rounds can be significantly faster with a modest-sized multi-banked SRAM.  Something with 256 banks of 1KB should be at least 2x faster than a Rx 480, even if the ASIC is clocked below 1Ghz.

It works fine for GCN3 (i.e. Tonga).

It's not quite as good as Polaris, because the AMDGPU driver seems to use fixed voltage tables with Tonga rather than EVV.
You also need to watch out for the ACPI bug that causes powerplay to fail.  It seems BIOS and slot dependent, so you might not encounter it.  I had problems with the the 16x slot on H97 anniversary boards, and after trying a couple different BIOS versions I gave up and just use the 5 1x slots.

Money.  ~$10M/day is made mining ETH now.  A year ago it was ~$1M/day, and 15 months ago it was <$500K/day.
Bitmain's ethash miner is not going to have a significant impact, because unlike bitcoin and sia mining, it requires large amounts of RAM.  The costs of the RAM significantly exceeds the costs of the ASICs.
At US$450, ETH is now 1/3 of it's peak in Jan, and that is what is having the biggest impact on mining and GPU demand.  Summer is coming in the Norther Hemisphere, which means miners with expensive electricity costs will be shutting down rigs.  Unless the price of ETH climbs back over $1000, I predict the GPU shortage will be over by mid-summer, and GPU cards will be readily available at their MSRP.

Last summer I shut down my mining rigs.  For the summer of 2016, there was decent money to be made on ETH mining, so I moved my rigs to the garage.

I'm getting close to releasing the first beta of my new ethereum miner, and have been thinking about the program output.
I don't think people generally care about new jobs, so printing the hash of a new job will be limited to debug builds (or maybe a debug option in release builds).
Obviously per-GPU hashrate will be reported.  Solutions, failures, and rejects will be reported, and I'm thinking of making them per-GPU instead of aggregate like ethminer does.

Is there anything else that a miner needs to output, or that it definitely shouldn't output?  I'm wondering if program runtime is useful.  The output logs will be timestamped, so it will be easy to see if the miner is still running by looking at the output tail.

At this time I'm concerned only with basic output.  After the beta is stable and working, I'll look at adding other output like fan speeds and temperatures.

Try mining with a small dag (i.e. Ubiq, Expanse).  Part of the issue is the memory controller isn't as efficient as GCN3 and later, but most of the issue is the large DAG size combined with 4K pages causing TLB misses.
I haven't tried it, but the 2M page support should work with Linux kernel 4.15, which would make a big difference mining ETH.

Hmmm... I started watching his Vega liquid nitrogen video, and stopped after he said, "as you start going below ambient temperature, you get water ... condensation".
A good scientist knows you get no condensation on a surface that is below the surrounding air temperature and above the dew point.

While recently writing code to generate the Ethereum DAG cache, I realized the algorithm is not fundamentally memory hard.  The memory it uses is basically a look-up table of pre-computed keccak hashes.  As explained on http://keccak.team/, the keccak sponge function is designed to be simpler to implement in silicon (use less chip area) than sha-256.

The DAG cache is made by sequentially running a keccack-512 hash on the seed to fill the cache, then mixing those 64-byte hashes with a few XOR operations.  The sequence of running n-rounds of keccak-512 can be decomposed to an operation that is constant in time, so that 1000 rounds can be computed in approximately the same time as 10 rounds, and with approximately the same amount of silicon area.  In the past this decomposition/optimization of multi-round hashing has been a mostly manual process.  In other words a silicon designer making a circuit that uses a single-round sha-256 and a 3-round sha-256 would need to insert the code (i.e. something like Verilog) for both an optimized single-round and 3-round sha-256.  Ethereum requires over a half-million rounds of keccak-512 to create the DAG cache, so the only practical way this could be designed in hardware would be to generate the code in software.

Why hasn't anyone done this yet?  Well, just because Ethash is not fundamentally memory hard, the alternative is area-hard.  Implementing a half-million different multi-round keccak-512 functions in silicon would take a lot of area.  If each implementation takes 10,000 gates (20 gates per bit), then the ASIC implementation would require at least 5 billion gates.  And that's only for the DAG cache, which is used to create the full DAG by mixing 256 cache entries to create one DAG entry.  The Ethash function itself mixes 64 DAG items, where each item is two consecutive entries that were created from the cache.

So while it is not fundamentally memory-hard, it is effectively memory hard at this time given the huge amount of chip area required to avoid the memory cache.

Although it's not a large sample, I've noticed my Gigabyte cards use 5-10% less power than my MSI cards.  While it could be just coincidence, it's also possible that the Gigabyte cards have a more efficient VRM (faster MOSFETS, lower resistance inductors, etc).  Has anyone come across any video card reviews that test VRM efficiency?  I've found motherboard reviews that look at VRM efficiency, but couldn't find anything for video cards.

I said, "32AW is a multiplier for FAW", not a "multiple of".  So programming memory controller to use 8 for 32AW means 8*FAW, and a value of 6 for FAW means 6*RRD.
Using anything lower than 8 for 32AW should be irrelevant, as should using anything lower than 4 for FAW.

Another complication in finding optimal timings is that they vary slightly according to the memory controller characteristics.  Newer GPUs like Tonga and Polaris have improved memory controllers, likely with deeper queues, which allows more memory accesses to be grouped together in the same bank, reducing the impact of FAW & 32AW.  These newer cards tend to benefit from slightly looser timing (CAS, RRD & FAW) with a higher memory clock.  Older GPUs like Pitcairn seem to be better with a slightly lower memory clock but tighter timing.

If my suspicion about the labels being reversed is correct, and 32AW is a multiplier for FAW, then 6/8 is perfectly fine.  FAW would be 6*RRD, and 32AW would be 8*6*RRD.
That also would better explain the observation that setting what they think is 32AW to zero causes instability.

As for the tool I'm working on, you can get an idea of how it works by looking at my fork of amdmeminfo.
https://github.com/nerdralph/amdmeminfo
I modified it to show runtime strap values.  My tool doesn't just read them, it writes them too.
I believe Yurio is ahead of me in this process with his Windows miner now being able to do runtime timing modifications.
https://github.com/zawawawa/GatelessGateSharp