read genoils answer for that 1080 problem;
https://devtalk.nvidia.com/default/topic/962406/gtx-1080-very-bad-result-for-mining/------------------------------------------------
GENOIL SAYS,
Hey Etar/Etayson,
No, neither Claymore nor myself were able to fix it using C++. The fix is in Pascal + WDDM2.1 + right drivers.
Going by the reports, it seems that the random read bug fix (more or less known over here as the TLB trashing issue) works better for GDDR5 than for GDDR5X. Or the people reporting such low numbers to you just haven't got the right combination of OS/drivers.
But the GDDR5X issue is something different. Even on Linux, where the TLB trashing is not happening at current memory allocation sizes for the algorhitm in question, we get only about 22MH/s hashrate, equivalent to about 55% of theoretical max. bandwidth, whereas the 1070 does about 27MH/s, which is about 84%.
I did a bit of research into this a while ago and I can't remember whom I was discussing this with back then, but at the time we were speculating about the GDDR5X being stuck in DDR mode instead of the new QDR, effectively halving the memory bandwidth. This was pretty much in line with the measurements.
Ultimately, there's not so much you can do about this.
------------------------------------------------
main problem is :
Both 1070/1080 have 8 memory controllers (each is 32-bit wide = 4 bytes)
1070 > GDDR5 @
2000 MHz - 8n prefetch (over 2 memory cycles) = 8*4 = 32 bytes in a 2 cycle transaction (or 2000*4 per cycle= 8 GHz)
1080 >
GDDR5x @ 1251 MHz - 16n prefetch (over 2 memory cycles) = 16*4 = 64 bytes in a 2 cycle transaction (or 1251*8 per cycle=10 GHz)
