Miner does not use 1.88 factor in calculations, using it is a bad idea because it is theoretical factor and real implementation may be not so good. Therefore miner just counts all solutions found, and time that was spent. If algorithm implementation has a bug that causes 1.8 factor, it will cause less number of solutions and less calculated hashrate. So this idea is wrong.
I still think it's related to pool. What pool do you use? I will put all my polaris cards to it and check 2-3 daily hashrates to see hashrate deviations.
Claymore I found your bug...seems like shares are dropped when there is high network latency in your share queue (time after block is found on network, network disconnects, pool disconnects etc). Either there is a bug in your share queue that not properly submitting queued shares, or when you do regain connection to pool, you dump all the shares at once to pool and pool software might be blocking/loosing those submits.
Below you can see a test of my theory, network is manually dropped at 12:58:22 and reconnected at 12:58.36 and in that time system finds 18 shares, but only 15 reach the pool.
This issue is obviously magnified by larger rigs since the faster the system finds shares the more shares will eventually be dropped if there is a network latency, so it explains why you or others might not see the same behavior. Maybe put in a slight delay(10-20ms) between queued shares so they are not all dumped at the pool at same time?
PM me entire log file, I'll check it.