Does this mean --dev_fee_ssl is ignored now even on previous releases?

It's pretty nasty behavior for software to modify its network activity/fingerprint on existing versions. I noticed previously configured gminer versions trying to hit outbound SSL all of a sudden.

Stales were good at first but climbed up to 2% over 24 hours. gminer is still slightly better effective because of that.

I rather control my own watchdog/overclock enforcement and have the option for miner do a slower/safe DAG generation to work with operating overclock settings.For those that want to let TBM control overclocks, is the delay only for the first DAG generation? If so, it will likely crash on epoch change.

I'm happy to say the defaults in v1.16 are proving to be competitive on flexpool so far.

Especially for RTX 3080, RTX 3090, and RX 6800. The effective hashrate matches or exceeds the same setup with gminer now, even with the little bit more stales .

RTX 3070 and 3060Ti still seem to not accept the same level of memory overclocks. They have to be adjusted down -100 to -250 MHz to get past the DAG generation phase and the decrease shows in the effective hashrate.

Can you provide more details and proof of gminer doing this? Otherwise this is an unbased smear attempt.

I'm saying there is more to the picture than just the data on that page and it makes sense to analyze everything about pool+mining software+tune stability before moving. Higher highrate with stales on a pool is good and well, but if it's not leading to more crypto in the wallet at the end of the day it's just mind games.

We've seen pools be deceptive with miner rewards. I don't blindly trust that pools compensating stale shares on the surface are not pulling from somewhere else. So yes, I want more data to prove the % gain in hashrate by switching pools for TBM (with more stales) translates to more actual rewards/payout.

Keep making TBM the best you can and presenting the data as it evolves.

It will require more testing as TBM matures I think.

I have not seen an effective hashrate increase with TBM on flexpool yet even with the lower fee, for example.

I understand the point that pools which pay for stale shares will give you a higher hashrate with the miner. But we have to consider the hashrate gain versus each pool's payout holistically. What is squeezing that extra hashrate poolside with stales at the expense of (withdrawal fees, pool not paying out other parts of the total reward, etc)?

For me v1.09 DAG generation works on RTX 3080s and 3090 with the same stable OC settings as other miners and the reported hashrate gained was substantial.
With RTX 3070s I had to drop my memory overclock by -150 to -200 compared to other miners just to get the DAG to generate properly and the reported hashrate dropped accordingly.

Unfortunately, the poolside effective hashrate (flexpool) was lower overall along with a higher number of stale shares overall so I'm not using TBMiner for now. I have high hopes for TBM and will be following development closely.

It would be helpful to have the option to order cards by PCI ID for debugging overclock issues.
Or at least show the PCI ID in --list-devices