...
I was mining Eth instead of Vert for awhile, but right now a 280x mines almost twice as fast as 970, so after all the AMD miners hoped on board it was no longer all that profitable. It's about break even with Vert right now though, still sometimes more profitable, regardless of it being slower.
ETH can probably run much faster on the high end cards if some of the memory access can b replaced with computation.
The ET performance depends on the DAG file.. Without a random file, every random acces isside the cached and the hashrate explodes
duh ?! there is no way to get rid of those... otherwise,as Myaguy was explaining, it may possible to calculate some of the dag element hence reducing memory usage
Have you guys considered more compression?
thinking about it, but it isn't really obvious it would help... need to find a compression algorithm which works on it (I tried zipping the file, just to have an idea of what could be done and ended up with a larger file... I was mining Eth instead of Vert for awhile, but right now a 280x mines almost twice as fast as 970, so after all the AMD miners hoped on board it was no longer all that profitable. It's about break even with Vert right now though, still sometimes more profitable, regardless of it being slower.
ETH can probably run much faster on the high end cards if some of the memory access can b replaced with computation.
The ET performance depends on the DAG file.. Without a random file, every random acces isside the cached and the hashrate explodes
Have you guys considered more compression?
) so it seems there isn't much to compress (well 1.2Gb of integers...). For info, for a 780ti to work correctly on windows 8.1, only 1.3% less dag is required (but that 1.3% is still too large to store anywhere that amount of data (too large for either register or texture/shared )The GTX 980 ti with +50% more bandwith has similar performance than a GTX 980 : there should be some bottleneck elsewhere...
an amd 280x has better performance ...
It's not like the algo loads large chunks of contiguous blocks of memory like texture maps. Instead it loads 64 times a 128 byte random chunk, where the index of each can only be found based on the previous one. So the available bandwidth cannot be fully utilized. I've already tried running two of those loops in parallel, but haven't been succesful at that yet.
I think wider memory bus and therefore higher overall bandwidth. In games, nVidia makes that up with compression, but here there nothing to compress in random chunks of 128 bytes of hashed hashes. The effciency of AMD vs NVidia is about the same. i.e for a GTX980, that hashes about 19MH, the theoretical max. hashrate is 224GBps/8KBph = 28MH. 19MH/28MH = 67%. For a 280/X.290/X that hash at about 27MH on average, the theoretical max is 320GBps/8KBph=40MH. 27MH/40MH= 67%.
) 
...
