Okay, here is a problem. See screenshot.
I'd say it is a problem that has two causes. The fluctuating hashrate due to the algo but mostly the suboptimal vardiff implementation of the pool, which ramps up way too much an then remains way to high for way too long. Both causes amplify each other.
See on the first screenshot around 13:30 how due to the skyrocketing hashrate to 80MH/s the pool ramps up the vardiff to 2.05G. However just then the hashrate drops (when hash order changed) to sub 30MH/s and the rig isn't able to find a single share for four minutes (13:32:12 to 13:36:11). Yes, I know the typical pool operator talk about how it doesn't matter for revenue because shares are weighted with difficulty. Sure. But 2.05G multiplied with ZERO shares is still ZERO over that four minutes period.
From experience I can tell that shares should be found/submitted every five seconds for an averager blocktime of 1min. Too low diff is bad (server traffic, latency), too high diff is bad too (no shares at all, working on outdated jobs).
I understand the pool operators' incentive to minimize server traffic by letting workers crunch higher diffs, but in this case the vardiff clearly is not working well because it goes way too high and remains there for too long. That's bad for the workers and bad for the pool too.
@ocminer: What you think?
@andrucrypt: Is it technically possible to optimize the miner to make the hashrate higher for those hash orders where it is much lower currently? Or is this limited by the varying usage of core and memory and the actual hardware specs with regard to both on which it runs?
I'd say it is a problem that has two causes. The fluctuating hashrate due to the algo but mostly the suboptimal vardiff implementation of the pool, which ramps up way too much an then remains way to high for way too long. Both causes amplify each other.
See on the first screenshot around 13:30 how due to the skyrocketing hashrate to 80MH/s the pool ramps up the vardiff to 2.05G. However just then the hashrate drops (when hash order changed) to sub 30MH/s and the rig isn't able to find a single share for four minutes (13:32:12 to 13:36:11). Yes, I know the typical pool operator talk about how it doesn't matter for revenue because shares are weighted with difficulty. Sure. But 2.05G multiplied with ZERO shares is still ZERO over that four minutes period.
From experience I can tell that shares should be found/submitted every five seconds for an averager blocktime of 1min. Too low diff is bad (server traffic, latency), too high diff is bad too (no shares at all, working on outdated jobs).
I understand the pool operators' incentive to minimize server traffic by letting workers crunch higher diffs, but in this case the vardiff clearly is not working well because it goes way too high and remains there for too long. That's bad for the workers and bad for the pool too.
@ocminer: What you think?
@andrucrypt: Is it technically possible to optimize the miner to make the hashrate higher for those hash orders where it is much lower currently? Or is this limited by the varying usage of core and memory and the actual hardware specs with regard to both on which it runs?