That sounds like sp__ is back!

)))))
I would love resolution as then i would just have to switch to your miner without tweaking any cards instead of tweaking 5 rigs with multiple 3070s. Luckily my son has 3070 on this gaming machine so i test here.
I will create a cache of the dag buffer on file. On every new epoc, one of the cards in the rig needs to be able to create the dag buffer. And if the validation fails for the other cards, the program will read from file. Will use around 5GB of harddrive space, but no need to reduce the clocks.
I'm testing 1.45 on HIVE OS. At the start, the hashrate results on the pool and shares are good, I use cuda 11.4 Nvd driv. 470.94 , --kernel 1, --xintensity 1988 , cclock 1311. The miner still gives a dag generation error on rigs 3060 - 3070 . I continue the test.
I noticed that your miner works fine for the first 24 hours, but then the speed slows down, the hashrate on the pool becomes smaller, maybe this is due to Hive OS and cuda 11.4 You should do more tests under HIVE OS, more than 24 hours.

I've done some analysis based on the shares per minute as at-pool hashrate and:
*The miner stabilizes at around the 70 minute mark and remains fairly stable until at about the 300 minute mark, the miner begins to degrade.
At the 430 minute mark, the degradation levels off and remains relatively constant until around the 500 minute mark where it degrades again until about the 600 minute mark where it remained stable / slightly increasing until the end of the sample dat at 780 minutes.
It seems that for whatever reason, the first 60 minutes sees the most improvement and the highest share/minute production after it peaks decreases significantly to the 70 minute mark where it stabilizes until the 300 minute mark.