Rejected shares every 4 plus days

I have a rig of 6 gpus. 2 1080s, 1660ti, 2060 super, 2080, 3060ti. I’ve been running Phoenix miner almost the whole time using hive OS. Every 4 days and 10 hours (almost to the minute) I have to restart my miner because it just starts rejecting shares. I go from a 99.99% accepted shares to hundreds rejected. All I have to do is restart the miner and I’m good for another 4+ days.

I tried Trex miner for a few days but did it did not run as well.

Updated hive but it’s been doing it since version 204. Video card drivers updated as well

I’ve tried to use watchdog but can’t figure out good settings to make it restart on its own.

The log is hard to figure out because it seems like the issue is not pin pointed to one card (Maybe I don’t know what I’m looking for).

I’ve also tried adjusting OC settings but it still happens every 4+ days.

Does anyone else experience this issue or have a suggestion on how to fix this?

Thanks for the help

If you mine ETH, every 4 days the dag (epoch) changes, so I think it’s from there.

Often due to a too high OC or the minor manages badly the generation of the new dag

Under Trex you have to put in config “Extra config arguments:”

“gpu-init-mode”: 1
“dag-build-mode”: 2

I use Gminer 2.64 with small oc, i prefere stability and no stale / badshare

Thanks for giving me something to look into. All I ever get is it’s my OC or a temp fix. I’ll have to figure out how to work with the dag on Phoenix but I think you might be on to something.

I don’t work with phoenix because it’s not nvidia optimized, and it’s not one of the best for that on the sharing side, keep in mind that the number of shares is the most important.

I work more with Gminer and Trex with my Nvidia and Teamredminer or lolminer for my AMDs.

In spite of any given me your line of like or your arguments of phoenix, I will look.

And also the OC of the 3060Ti (the others I don’t have)

I was able to find where to and what to use for phoenixminer. For those who might need it I added this to the additional configuration on the miner

-dagrestart 1 (restarts miner with new dag)

DediZones I’m really not to worried about my OC at the moment. They operate at a 99.99% efficiency rate. Until day 4 of mining. If the issue persist then I’ll post them up.

Hi,

Add this in command line or argument

-mcdag 1


-mcdag Reset GPU memory clock to default during DAG generation. Nvidia
only, default: 0 (turned off). This may allow you to set higher memory overclock on your Nvidia cards without risking corrupt DAG
buffer, which can lead to excessive number of stale shares.

 Under Linux this option will execute the daggen.sh script (if present in the current directory) for each GPU, passing the GPU
 index as the first argument, and PCIE bus ID as second argument. The miner will not wait for the daggen.sh script to finish before
 starting to generate the DAGs. Instead it will for a fixed 7 seconds. This allows you to do all the following in the
 daggen.sh: turn off the overclocking of Nvidia GPUs, sleep for 30-60 seconds, and then  re-apply the overclocking of the Nvidia GPUs.

Well I added in what you suggested and I’ve hit the 6 day mark without a miner reset! I don’t want to jinx it but it seems to be working. Thanks for the help.

nice for you man, yes yesterday new dag generation :wink:

Are there dag command for Gminer as well?

Looks like it. Here is a website I found…

Something like this might be what your looking for.

–safe_dag

  • allows you to choose a way to DAG generation.
  • In fast mode (value 1, auto for GTX GPUs) miner generates DAG as quickly as possible, DAG errors are possible at maximum overclocking.
  • In safe mode (value 2, auto for RTX GPUs) miner generates DAG with error control, useful for RTX cards at maximum overclocking.

Thanks, I added it in to see if that eliminate some random error for NVIDIA cards. Do you know why my 5700s would run 2-3mhs lower on GMiner than on TeamRedminer? Trying to get all cards under same miner for high difficulty shares.

They are not doing bad but I typically get 58+ XFX, 57+ Gigabyte, 55+ PowerColor

See share no MH in your rig and pool

the most important is the number of shares in a mining software

I’m not sure I understand what your saying. Are you saying the only thing that matters is the mhs on the pool? That I under stand but my average on the pool before was 415-418mhs now it’s 408. Should I care about the 10mhs if I’m solving more difficult shares?

for make simple:

more share = more ETH = more $$

See Round Share and Reward

My understanding is that team red is better for AMD cards. Maybe they just try to maximize performance on them. I don’t have any AMD so I couldn’t tell you.

DediZone is correct. Although MH/s is important it comes down to how many shares you’re finding. So the real question is do you find more shares between the two miners with higher MH/s or when it’s combined in Gminer. You would think higher Mh/s would yield more shares but it’s not always the case.

I did find this, so if you are getting more difficult shares you are getting paid more for those shares. So larger rigs should get more for less shares. I don’t think that’s always the case though. I had 2 rigs running before and 2 miners on one rig getting 3x the shares and I’m pretty sure I was making more at the time. Could have been a fluke, who knows.

Vardiff Example

And finally, let’s look at this through a basic example:

Let’s say you have 2 workers, RIG A & RIG B.

RIG A has a total of one GPU @ 50 MH/s. The Mining pool sets the Share Difficulty for this worker @ 1250MH. You then, get credited by the pool for all shares that are above 1250MH.

RIG B has a total of 100 MH/s. The Mining pool sets the Share Difficulty for this worker @ 2500 MH.

Both RIG A & RIG B will have approximately the same number of shares sent, but RIG B will receive double the revenue from the pool for the higher difficulty submitted shares.

This topic was automatically closed 416 days after the last reply. New replies are no longer allowed.