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.
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:
setx GPU_FORCE_64BIT_PTR 0
setx GPU_MAX_HEAP_SIZE 100
setx GPU_USE_SYNC_OBJECTS 1
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_SINGLE_ALLOC_PERCENT 100
timeout /t 3
ethminer --farm-recheck 400 -G -F http://172.16.0.225:8546/miner-09 --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.