My home kitchen rig (pics are clickable):
http://www.ximages.net/images/55149569002397989291_thumb.jpg
Fans speeds are changed in MSI AB config, maximum 2100rpm, blow out = TY-140 @ 1300rpm, 2 x HD7870 @ 1150/250 + 2 x 7950 @ 1050/250 on stock voltages = 2 x 420Mhash/s + 2 x 520 Mhash/s.

My home PC:
http://www.ximages.net/images/83334997118256058747_thumb.jpg
Very quite, nearly inaudible from 1-2m, 4 x Scythe Slip Streams 120x120x25mm @ 800rpm (PSU, Accelero S-1, blow in, blow out), 1 x Noctua NH-P14 140x140x25mmm (CPU cooler) @ 700rpm, HD7950 @ 950/800 = 475Mhash/s.

On one rig I meet the problem:
after start it prints an error to the log mulltiple times: "cannot get current settings, error -1", after that rig can freeze (i suggest that AMD driver resets).
What does this message mean?
Did anyone meet the same problem?

This rig has 4 x Radeon VII installed, downvolted, at stock memory clock, and it was rock stable before (>1k hours uptime).
Virtual memory is set to 65-70GB that should be enought.

What strap and clocks do you use for 53.2MH ?
My record is 51.2 for Vega 64 and 50.9 for Vega 56@64, clocks 1050/1100, custom timings.

If I simplify this set to:
--RC 44 --RP 13 --RRDS 5 --RRDL 5 --REF 17000 --RFC 248
(with stock --CL 20 --RAS 33 --RCDRD 16 --RCDWR 10 --RTP 5 --FAW 16 --CWL 7 --WTRS 4 --WTRL 9 --WR 16 --WRRD 1 --RDWR 19)
I have the same hashrate on ETHash and it is same stable (or maybe a bit more stable).
I am testing vega56@64 and vega64 cards with samsung memory with resulting hashrate 49.5-51.5 MH/s for memory clocs 1080-1100MHz with driver 19.4.1.
Am I doing anything wrong?
Or lowering other timings helps only on CN algos?

I have 24 vegas.
If I mine ETH, total hashrate is ~1050 MHash/s in EthMan, pool reports 1020-1030 MHash/s average hashrate.
If I mine XMR, total hashrate is ~43 KHash/s in EthMan, pool reports 38.5-39 KHash/s average hashrate.
Rejected shares rate is <0.1% in both cases.
So while CryptoNote mining Pool receives only about 90% shares, I bet it is not normal.
Is there any way to fix it?

I have taken some shared soft PP reg file with 1408/1050 clocks and only lowered the GPU clock.
Settings:
GPU_P0=852;900
GPU_P1=991;900
GPU_P2=1084;900
GPU_P3=1138;900
GPU_P4=1150;900
GPU_P5=1202;900
GPU_P6=1212;905
GPU_P7=1340;905
Mem_P0=167;900
Mem_P1=500;900
Mem_P2=800;900
Mem_P3=1050;900
Fan_Min=10
Fan_Max=4900
Fan_Target=60
Fan_Acoustic=2400
Power_Temp=85
Power_Target=0

So my cards consume about 250W each with 1.8Mh/s hashrate, profit/consumption ratio is not really good.

4 x Vega56 with Vega64 BIOS with clocks 1340/1050MHz @ 900mV, hashrate is ~ 4 x 1.8 Mh/s, power consumption ~= 1050W from the wall.
Same rig with same settings on XMR gives hashrate 4 x 1750MH/s, power consumption ~= 710W from the wall.

Good job, Claymore!

V11.0 is much better for Vegas than V10.2.
V10.2 was ~30% slower than cast/stak.
V11.0 is ~15% slower with default settings and ~10% slower with best manual settings.

Got 1720-1770Hash/s now on Vegas 56/64.

Waiting for next version...

Claymore,
are we going to see a new version of this miner with 1800-2000Hash/s on Vega 56/64 ?

Pressing "0" doesn't force the graphic card to stuck on low P state.
But reconnecting to pool does...
I have reproduced this bug again:
https://image.prntscr.com/image/ODk4rUfXTlCwyS0txlLT5g.jpg (screenshot #1) - internet connection to pool was interrupted, miner reconnected to pool and RX470 is stuck at low P state (466/2000MHz), you can see that pressing "0" doesn't fix this problem, GPU0 is still stuck at 466MHz P state.
https://image.prntscr.com/image/4vZSrEESQU_5WWdpXXz-xg.jpg (screenshot #2) - after screenshot#1 was made, I restart the miner, and GPU0 now works on it's normal clocks (1125/2000MHz).

I can send you log file from miner from that time, when screenshot #1 was made.

Claymore,
I did not check ETH only mode, but in ETH+DCR mode it is easy to reproduce:
1) start mining (no clocks settings in bat file in my case)
2) wait until miner looses connection to pool (you can force it by unpluggung lan cable)
3) wait until miner connects to the pool again (plug in the lan cable)
4) in most cases the graphic card will work in P0/P1/P2 state with low clocks until you restart the miner

I have copyed parts of the log to this post, maybe it will help?
https://bitcointalk.org/index.php?topic=1433925.msg21431939#msg21431939

I have modded and flashed bioses with high GPU clocks in all states, the initial problem is solved.
But some cards need 10-30mV higher GPU voltage for stable work in this case, so power consumption is a bit higher.

Same problem here with my RX470s.
It happens only with blockchain driver nearly each time after Claymore miner reconnects to the pool.
Restarting Claymore miner solves the problem, so I bet Claymore can easily fix this issue.
I have flashed high clocks in all states in bios, but cards need higher voltage now.

I have faced the same problem with new blockchain drivers,
GPUs are stuck in P0, P1 or P2 states (300-600-900 MHZ core clock) after reconnection to pool.
This problem does not happen with old drivers.
So maybe claymore can fix it.
Simple setting -cclock in claymore config doesn't help, maybe writing high clocks in all states in BIOS can help, I have not checked it yet.

I have reproduced this bug some more times.
GPUs are stuck in P0, P1 or P2 states after reconnection to pool.
Should I put same clocks in all states in BIOS?
Or should I force clocks with -cclock option?
Or should we wait fix in miner v10.1?

Metroid,
Clocks, voltages and voltage offset are hardcoded in videocards bioses, so videocards are mining with their "default" settings both before and after reconnect.
Only hashrate drops, all settings remain the same.

This problem is still reproducible with CDM v10.0 and the same blockchain driver.
Rigs with 16.7.3 driver works well for 500+ hours.

Normal hashrate:
00:26:41:263   12ac   ETH - Total Speed: 157.527 Mh/s, Total Shares: 269, Rejected: 0, Time: 01:38
00:26:41:278   12ac   ETH: GPU0 26.059 Mh/s, GPU1 26.316 Mh/s, GPU2 26.297 Mh/s, GPU3 26.301 Mh/s, GPU4 26.260 Mh/s, GPU5 26.293 Mh/s
00:26:41:278   12ac    DCR - Total Speed: 4410.745 Mh/s, Total Shares: 810, Rejected: 14
00:26:41:310   12ac    DCR: GPU0 729.664 Mh/s, GPU1 736.848 Mh/s, GPU2 736.329 Mh/s, GPU3 736.429 Mh/s, GPU4 735.283 Mh/s, GPU5 736.192 Mh/s

Then miner looses connection to pool:
00:31:41:744   12ac   Socket was closed remotely (by pool)
00:31:41:744   12ac   ETH: Connection lost, retry in 20 sec...
00:31:42:009   1210   Socket was closed remotely (by pool)
00:31:42:025   1210    DCR: Connection lost, retry in 20 sec...

After reconnection hashrate is ~2x lower:
00:33:03:981   12ac   ETH - Total Speed: 70.921 Mh/s, Total Shares: 293, Rejected: 0, Time: 01:44
00:33:03:997   12ac   ETH: GPU0 16.093 Mh/s, GPU1 11.812 Mh/s, GPU2 11.813 Mh/s, GPU3 11.818 Mh/s, GPU4 11.796 Mh/s, GPU5 7.589 Mh/s
00:33:04:044   12ac    DCR - Total Speed: 1985.794 Mh/s, Total Shares: 855, Rejected: 14
00:33:04:060   12ac    DCR: GPU0 450.611 Mh/s, GPU1 330.748 Mh/s, GPU2 330.755 Mh/s, GPU3 330.902 Mh/s, GPU4 330.287 Mh/s, GPU5 212.491 Mh/s
...
after 9 hours nothing changes, hashrate is still low:
09:09:49:724   12ac   ETH - Total Speed: 72.822 Mh/s, Total Shares: 1865, Rejected: 1, Time: 10:21
09:09:49:724   12ac   ETH: GPU0 19.089 Mh/s, GPU1 10.880 Mh/s, GPU2 11.818 Mh/s, GPU3 11.818 Mh/s, GPU4 11.811 Mh/s, GPU5 7.406 Mh/s
09:09:49:739   12ac    DCR - Total Speed: 2039.024 Mh/s, Total Shares: 4561, Rejected: 71
09:09:49:739   12ac    DCR: GPU0 534.490 Mh/s, GPU1 304.646 Mh/s, GPU2 330.906 Mh/s, GPU3 330.900 Mh/s, GPU4 330.707 Mh/s, GPU5 207.375 Mh/s

Does anyone have the same problem?

I have noticed a bug with combo ETH Miner v9.8 + AMD Blockchain Aug23 driver.
If miner looses connection to a pool, after reconnection hashrate significially drops.
Restarting the miner solves this problem.
Hasrate before reconnection to pool is ~156MH (26MH x 6 cards) and hashrate after reconnection is ~67MH (7, 11, 11, 7, 11, 18MH).
There was no such a problem with same miner and older drivers.

Claymore, I can send you the log, if it is neccessary.

Yes, and it works with 17.8.1 too.
But I only checked VRM monitoring and voltage offset changing.
Also it is card cpecific, wattool could not change offsets on some exotic non reference cards with unknown VRM controllers.

AMD updated beta for win10x64 (from Aug23) and win7:
http://support.amd.com/en-us/kb-articles/Pages/Radeon-Software-Crimson-ReLive-Edition-Beta-for-[Suspicious link removed]pute-Release-Notes.aspx
Both builds have same version of graphics driver - 22.19.659.0

My test rig with 6 x RX470 Powercolor with hynix memory, clocks 1100/1820, timings from 1375mhz strap, win10x64, claymore 9.8
16.7.3 driver = 149MH/s ETH + 4400MH/s DCR
17.8.1 driver = 149MH/s ETH + 4400MH/s DCR
Aug11 beta = 157MH/s ETH + 4670MH/s DCR
Aug23 beta = 157MH/s ETH + 4670MH/s DCR

Profit boost is ~5.5% in dual-minig mode and ~4% in ETH only mode.

BUT!
I have hardcoded voltage and offset in bioses of my RX470s (1000mV in all fields and offset -16 ~= -100mV), so with old drivers they worked with 900mV in idle, and ~880mV under load.
But new drivers override some voltage settings.
So with no modifications theese RX470 worked with 1080mV and offset -16 ~= 960-980mV under load.
Power consumption increased from ~900W to ~1050W.
Changing offset to -32 (~ -200mV) with good old Wattool v0.92 lowered voltage to desired 860-880mV and power consumption lowered to expected ~900W.
I am going to make a 24-48 hours test, if it works stable, I will force ofsset -32 in bioses...