Blockchain drivers

Oh, to burnish my credentials I should probably mention that I did my thesis work in crypto :-). I did long-integer arithmetic software in SPARC assembly language for RSA for my first thesis and an FPGA implementation of DES (using Xilinx XC4000) for my second thesis.

I have no idea what magic AMD worked in their drivers, I cannot even speculate. For all we know they could have addressed a performance-limiting component that had nothing at all to do with hardware. But per Robert Crovella’s message above, NVIDIA looked at the issue and found that the limiting factor on Pascal-generation GPUs is the TLB capacity. I merely pointed out that if that is the case, this is not something that can be “fixed” by drivers as a TLB is a non-configurable hardware component.

As for the DAG file: Did it exist in its current form at the time those GPUs were designed? How is it that none of the miners used this DAG file to assess the future performance of their (then) new GPUs when they were making their purchasing decisions? I assume there is a vibrant community sharing benchmark results and the like.

The DAG ( Directed Acyclic Graph) file has existed since the creation of ETASH algorithm, it increments in size, this is a crucial file in mining. DAG file size grows over time, exactly every 30.000 blocks (Ethereum). DAG file has to be “loaded” into your GPU memory while mining. If the GPU does not have enough VRAM, then that would be problematic. --> more information here https://ethereum.stackexchange.com/questions/1993/what-actually-is-a-dag with a mathematical explanation of how it works (which you may find interesting)

Miners look at VRAM size when purchasing cards, so for example I chose 6GB (p106/1060) and 8GB (1070) cards to allow for a couple of years worth of mining and allow for DAG file increase in relation to VRAM. Unless disclosed by NVIDIA which it appears they have only now recently done concerning the TLB capacity limitations in relation to DAG file increase, at point of sale the consumer could not have known this would impact performance.

This important point is something NVIDIA would/should have known about especially when producing and marketing cards for this specific purpose of crypto mining like the p104 and p106 mining series. Again to repeat, NVIDIA either had knowledge of this design limitation but failed to advise potential buyers (which is negligence and misleading/misrepresentation) or they did not know about it in which case it is a design flaw/defect - in relation to producing a product for specific crypto mining purposes.

**** I am unable to reply to your post below or further posts from you, because NVIDIA limit to 3 replies, so I will leave it at that.**

none the less in response:

It is quite simple, if you are producing a graphics card for specific application, like crypto mining algorithms and marketing as such, understand the application for which the product is designed for. —> In other words read the white papers, the design papers for the mining algorithm you want to support like ETASH which pre-dates the Pascal Architecture hardware design, understand how it functions and design accordingly to accomodate for any changing variables like DAG file increases which may inadvertantly effect performance. I think you are getting things back to front. You assume that the hardware design pre-date the mining algorithm design. ETASH and its DAG design predates Pascal Architecture. If the p104/p106 could not accomodate the changes in DAG file size then they should have not have been marketed by NVIDIA as use for mining applications.

Once again, I find it strange that AMD seemed to pre-empt this, but NVIDIA failed… tell tale signs of a company with substandard product design team…

1 Like

important point is something NVIDIA would/should have known

I am still pondering how something could have been considered for a 2015 (or thereabouts) hardware design that did not come into existence until 2020 (or thereabouts), especially when the interested party (miners) itself did not consider it when the hardware became available. I will leave it at that.

I will never buy nvidia again. I have more than 100 pieces GTX 1070 . And for mining they’re on the way to garbage. If I buy nvidia again, I know something similar will happen to me again in the future. And nvidia won’t do anything about it as usual.

after epoch 290 gtx 1070 will rise again… at least in ETC…will cut dag size…

epoch already #370 for ETH #382 for ETC right now. #290 is far behind

my bad… its epoch 390 :X…

What is the source of this information? How can i be sure?

1 Like

Useful information. Thank you.

Any update on this topic ?
DAG 4Gb is approaching

will have to mine ETC starting on 28 november…eth no more…

In fact my 6x gtx1060 rig was not affected at all, they keep pushing at 24 and 25 mh…

I also have two 7x gtx 1070 rigs that suffered big hashhate drop, from 31 to 26. (using 75% votage and +500 mem clock).

I also noticed on my desktop (gtx1070ti) no changes, the single 1070ti asus strixx is still working at 33 to 34.

Now I am wondering if bigger rigs with more than 6 gpus might be suffering worse hashrate drops because there is more VRAM allocation needed to buffer this DAG size…

Well, DAG Epoch should hit 4gbs in 19th Dec 20… lets see what happens.

at etc speed is back on…
in eth samething… allways getting less and less by the dag :X

Hello,

Is there any Driver update that could help NVIDIA to TLB to support the larger ETH’s DAG file?

Is Nvidia taking this issue seriously? Miners are angry, when NVIDIA launched the P106 device for crypto, one argument was the VRAM is large enough for the futur DAG, did NVIDIA already knew that the TLB on Pascal would become the limiting factor? at the moment 1080Ti see a loss of about 20% of performance.

I hope the issue is being reviewed and hopefully a SW fix would somehow be possible.