The DAG started at 1 GB at the time of the Frontier launch, and increases by approximately 0.73x per year. **That puts the current size at roughly 1.35 GB as of mid-January 2016** (feel free to comment with an exact link if anyone has one).

Following the same crude approximation:

- The 2GB limit will be hit around mid-December 2016
- The 3GB limit will be hit around mid-April 2018
- The 4GB limit will be hit around mid-September 2019

However, it's likely that the switch to PoS will occur long before then.

For what it's worth, **certain GPUs require the DAG to be uploaded in chunks**. You should search on the forums with the name of your card to find if this solution has worked for other users running the same hardware.

**DAG stands for Directed Acyclic Graph**. In Ethereum, a DAG is created every epoch using a version of the Dagger-Hashimoto Algorithm combining Vitalik Buterin's Dagger algorithm and Thaddeus Dryja's Hashimoto algorithm.

There are quite a few places where the DAG is defined in the docs and literature. These are collated below:

From the yellow paper:

...**d** being the current
DAG, a large data set needed to compute the mix-hash...

From Wikipedia:

**Directed Acyclic Graph:**
*image credit David Eppstein*

In mathematics and computer science, a directed acyclic graph (DAG), is a finite directed graph with no directed cycles.
That is, it consists of finitely many vertices and edges, with each
edge directed from one vertex to another, such that there is no way to
start at any vertex v and follow a consistently-directed sequence of
edges that eventually loops back to v again. Equivalently, a DAG is a
directed graph that has a topological ordering, a sequence of the
vertices such that every edge is directed from earlier to later in the
sequence.

From https://github.com/ethereum/wiki/wiki/Ethash-DAG:

...a great huge dataset known as the DAG...

The Ethash algorithm expects the DAG as a two-dimensional array of
uint32s (4-byte unsigned ints), with dimension (n × 16) where n is a
large number. (n starts at 16777186 and grows from there.) Following
the magic number, the rows of the DAG should be written sequentially
into the file, with no delimiter between rows and each unint32 encoded
in little-endian format.

From Vitalik Buterin's (I think) Dagger Paper, Dec 2013:

Dagger, a memory-hard proof of work based on moderately connected
directed acyclic graphs (DAGs, hence the name), which, while far from
optimal, has much stronger memory-hardness properties than anything
else in use today.

Essentially, the Dagger algorithm works by creating a directed acyclic
graph (the technical term for a tree where each node is allowed to
have multiple parents) with ten levels including the root and a total
of 2^25 - 1 values.

From https://github.com/ethereum/wiki/wiki/Mining#so-what-is-mining-anyway:

...calculating the PoW (Proof of Work) requires subsets of a fixed resource dependent on the nonce and block header.
This resource (a few gigabyte size data) is called a DAG. The DAG is
totally different every 30000 blocks (a 100 hour window, called an
epoch) and takes a while to generate.

From https://github.com/ethereum/wiki/wiki/Mining#ethash-dag

a DAG (directed acyclic graph) for the proof of work algorithm

From https://github.com/ethereum/wiki/wiki/Mining#the-algorithm

a large, transient, randomly generated dataset

From https://github.com/ethereum/wiki/wiki/Ethash

The DAG is the "dataset" in this description of the Ethash algorithm, emphasis mine:

- There exists a seed which can be computed for each block by scanning through the block headers up until that point.
- From the seed, one can compute a 16 MB pseudorandom cache. Light clients store the cache.
- From the cache, we can generate
*a 1 GB dataset*, with the property that each item in the dataset depends on only a small number of items from the cache. Full clients and miners store the dataset. The dataset grows linearly with time.
- Mining involves grabbing random slices of the dataset and hashing them together. Verification can be done with low memory by using the cache to regenerate the specific pieces of the dataset that you need, so you only need to store the cache.

## Best Answer

Are you on cards with limited on-board RAM, such as 3GB cards? The DAG size is now 2.48GB and it is possible that your cards can no longer hold the DAG in VRAM.

Also, you should set your Windows page file size to be larger to

`card_vram_capacity * num_of_cards`

. So if you have 6 GPUs with 8GB RAM, set your page file to 48GB at a minimum.