Re: PhoenixMiner 4.7c: fastest Ethereum/Ethash miner with lowest devfee (Win/Linux)
⭐ Merited by pbfarmer (1)
Also plenty of people with 4gb polaris cards are hitting dag limits. Im one of them. My 6 card rigs have been online for years until now. Issue started around dag 285 on ETC. ETH gave the same issues but later because the dag is slightly behind. I run windows 10 with Claymore connected to Nicehash dagger/hash pools. Virtual mem is set to 98gb. When the rigs were being fed ETH jobs they would mine no issue but as soon as the pool would switch to ETC it could not load the dag and would sit restarting the miner until Nicehash would switch back to ETH or whatever dagger/hash coin they are pushing. Did a couple Windows 10 reinstalls just to be sure I wasn't having any corruption or OS issues.
the case you describe here: dag is being generated - it gets written into the GPU memory, but then you need do free up all the memory to allocate another(different) DAG. there're many factors that can fail - intensive mem writes on overclocked and already heated GPU, memory free up and allocation can also fail easily, driver can be an issue and not only the miner app... so...it all however doesn't mean that you can mine eth on 2gb gpus - it's total nonsense. very simple: you need DAG(over 2 GB size) for algo to work, if somehow you manage to do segmentation and put only "relevant"(
) parts of the dag to the current calculations - you'll kill all possibilities of producing any meaningful results by constantly bottlenecking around reloading the dag parts into memory. in any case you are highly welcome to substantiate your incredible claims.
Look I get it. But it worked, in April, with the dag being over 2gb. It's quite possible that last bit of what you stated is what was going on. Card gave a very low hashrate, about 1.2mhs. I had set some settings in the bios I cant recall them except Legacy when installing the OS. Still working to figure out what I had done in April.
The following happened: the gpu(s) share the virtual mem address space with the host. Gpus already support using host-side mapped memory. Your allocation(s) were split across gpu mem pages and host mem pages by the driver. Many of your reads from the gpu was actually performed over PCIe, returning data from host mem. This is the cause of your crap hashrate.
Normally you see this behavior when youre juuuust pushing past the 4GB or 8GB limit, ie the full vram capacity on the gpu. The driver still allows the allocation but part(s) of the buffer will hit host side mem over PCIe, not proper gpu vram. Ive seen it a ton of times in CN mining when you push the nr allocated pads too hard. Seeing the driver allocating 60% of the DAG off-gpu is very surprising, but assuming youre not BSing, that is what happened. Still wont produce any useful hashrates so not really useful in the end anyway.