Ethereum Mining – “GPU can’t allocate the DAG in a single chunk”

Update April 2018 – It has been two years since I originally wrote this article, and back then it pertained to the approaching DAG file limit affecting 2 GB cards. We are now 2 years later quickly approaching the end of Ethereum mining on 3 GB GPUs and miners are once again encountering errors such as the GPU can’t allocate the DAG in a single chunk or similar messages, especially when using the Claymore mining software.

I more thoroughly go over this plight in my article The Days of Etehereum Mining are Numbered for 3GB GPUs, but since I have noticed a pickup in Internet searches landing on this page I thought I would add a quick update here as well.

For people who are using Claymore’s miner you can Use the “-eres 0” option in your batch file.
From the Readme:
-eres setting is related to Ethereum mining stability. Every next Ethereum epoch requires a bit more GPU memory, miner can crash during reallocating GPU buffer for new DAG. To avoid it, miner reserves a bit larger GPU buffer at startup, so it can process several epochs without buffer reallocation. This setting defines how many epochs miner must foresee when it reserves GPU buffer, i.e. how many epochs will be processed without buffer reallocation. The default value of -eres is 2.
Making this change in your batch files and ensuring your virtual memory is set to at least 16 GB (if using multiple GPUs) should allow you to continue using your 3GB cards until sometime closer to November of this year (2018) when the hard limit will occur.
Original Content starts below:

When mining “Memory Hard” algorithms such as the Dagger-Hashimoto which is what is used by Ethereum, one of the mechanisms used to make this algorithm ASIC (Application Specific Integrated Circuit) resistant is the dynamic DAG file. The DAG file grows over time to both increase the mining difficulty and to present an ever moving target that requires more and more on-board video card memory to be able to effectively mine.

Early reports of older cards such as the, HD6950, left owners unable to mine due to the fact that while they technically had enough memory 2 GB (2048 MB) of on-board RAM, they could not allocate it all at once, thus becoming unable to mine the algorithm. Recently with block 1,400,000, this problem has now increased to affect even more recent 2 GB GPUs. An error similar to the one below is displayed once this threshold has been reached:

Creating one big buffer for the DAG
Allocating/mapping single buffer failed with: clCreateBuffer(-61). GPU can't
allocate the DAG in a single chunk. Bailing.

This is a known issue that the Ethereum developers have developed a work-around for, however it is not yet in any released version of miner software. The problem is that while there is technically enough memory, the card cannot allocate it all in one go, therefore it errors out.
There is a temporary workaround until an fix is officially released, in that by setting certain environmental variables on your computer you can mitigate the issue. The easiest way to do this is simply by adding a few commands to your miner launch batch (.bat) file. The following .bat file shows these environment variables for Windows:

timeout /t 3
ethminer --farm-recheck 400 -G -F --cl-global-work 16384 --cl-local-work 256

The setx is a command for Windows to set x(environmental) variables for the system to use. In this case we are setting GPU variables to allow the allocation of memory to the maximum available. While some miners have been using a subset of these variables since the scrypt mining days, the last variable “GPU_SINGLE_ALLOC_PERCENT” seems to be the one we will need to address the recent error, in that it allows a single allocation (thread) to use up to the maximum amount of available memory.

A very brief overview of the variables and their available values are as follows:

  • GPU_FORCE_64BIT_PTR   [0 |  1] – When set to 0 this setting allows access to 32-bit address space of memory ~3.8 GB. When set to 1 it allows access to 64-bit address space. While it may sound like a good idea to set it to 1, it may actually hurt performance since then pointer access would require twice the number of clock cycles to complete than it would if left in 32bit mode. Note: For gaming leave this set to 1, especially if you want to use all of your memory in 4GB+ cards.
  • GPU_MAX_HEAP_SIZE   [0 – 100] – By default the memory made available to OpenCL is limited to just 50% of total GPU memory. With this setting it is possible to increase the amount of memory available up to 100%
  • GPU_USE_SYNC_OBJECTS   [0 | 1] – Syncs the System CPU with the GPU actions to improve performance, 0 is thought to lock usage to a single CPU core while 1 is thought to allow access to multiple CPU cores. Since this is a undocumented setting, it is hard to tell for sure. If you see 100% CPU utilization, try the opposite setting,  There is even some debate if this works with Windows at all.
  • GPU_MAX_ALLOC_PERCENT   [0 – 100] – Maximum amount of  memory that can be allocated globally. Needs to be equal to or higher than the next setting.
  • GPU_SINGLE_ALLOC_PERCENT   [0 – 100] – Maximum amount of memory that can be allocated to a single process. This is limited by the above setting, so be sure to increase both.

The “timeout /3” is optional, and simply introduces a slight pause so you can watch for “Value successfully set” messages on launch.

The final line is the familiar launch string for the Ethminer program. The settings are suggested for video cards such as the AMD R9 380 and AMD R7 370 series. A “farm-recheck” value of 400 has shown to be effective with cl-global-work values of 16384 and 8192 which these cards are capable of. The cl-local-work value of 256 is also optimum for these cards and can be set to match the ” CL_DEVICE_MAX_WORK_GROUP_SIZE” value as shown below, in this case it is 256.


You can also look at the “CL_DEVICE_MAX_MEM_ALLOC_SIZE” value, to see what the maximum DAG file your card will support. In this example I am using 2 GB cards, with a maximum usable memory allocation of: 1878490204 bytes (1.878 GB) before I would be unable to mine Ethereum with these anymore.

The current DAG file size is 1.384 GB in size, giving these cards about 500 MB more in DAG file growth before they will no longer be able to mine Ethereum. Do note that there are other algorithms, such as SOIL and EXPANSE that also use the Dagger-Hashimoto algorithm and are currently profitable to mine, so once this point in time arrives it does not necessarily mean the 2 GB cards become worthless, you would just need to switch to another profitable coin.


  1. I have fixed DAG error with completely uninstall AMD Drivers and installation of 14.1beta custom setup – Display Driver only. The newer 14.12 did also not worked. So if you install good AMD display driver and nothing else (Control centers, etc.) – everything must work like it should.

  2. I have Nvidia gtx on laptop and I have the sames issue I tried to edit the batch file but did not fix it what should I do now.

  3. Nothings works. Really, THE UNIQUE SOLUTIONS!
    Please noob, dont comment again about my program. Because you generate many, alot problems for anothers user noobs, like you. Peace!

  4. You need, at least, 8GB Graphic Card, to get work on my miner program.
    Because even if you receive this message: GPU memory.1073741824 bytes of memory found < 4188838016 bytes
    Because if your Graphic card have 4GB probatelly, not have enough memory even yet.

      • According to Claymore in the Bitcointalk thread, he and others have been in contact with AMD to point out a bug in their drivers related to this slowdown. Supposedly there is a patch in the works that will address this.

        However, before getting too excited, realize that since 80-90% of all Ethereum is mined on AMD cards with this bug. And since it is affecting everyone with AMD cards the same, once they patch it everyone will apply it and mining hash rates will increase across the board. This equilibrium will mean you are making the same as you are now even though your miner displays a higher hash rate.

  5. @Nikita Mivlov 3gb or greater cards will still work. the DAG is only 2.05 gb, so it will be a while before the GTX 1060 3gb start flooding ebay. Be careful that you don’t provide advice to those trying to learn that is incorrect. People often search high and low around the internet for a definitive answer. And guesses provided as facts make it difficult for those trying to understand the requirements.

  6. i am using two rx 580s with 8gb but get open cl error 48 cannot create DAG on GPU. even after all the above variables have been set. what to do ?

  7. I appreciate, cause I discovered exactly what I was having a look for.
    You have ended my four day lengthy hunt! God Bless you
    man. Have a great day. Bye

1 Trackback / Pingback

  1. XFX – AMD Radeon R7 370 2GB Review – CryptoYeti

Leave a Reply

Your email address will not be published.


This site uses Akismet to reduce spam. Learn how your comment data is processed.