So I test my rig management code on a small test rig (Four GTX 1080 Ti’s). I have been analyzing the log files since Aug 8th and noticed the following.
Below is a plot showing the hourly Accepted Share values for each GPU. GPU0 had an issue with halving its Sol/Sec without failing so I had written code to watch GPU performance over time to deal with that issue (Running Avg and Variance). You can see the halving of the shares earned / GPU on Sept 28th that we all noticed. So nothing here raised any red flags for me.
So here is a different plot that shows the EWBF DevFee goes from 1.9% before the share halving to 3.6% after (average calculations). The DevFee is now sitting up at 8% for many hours when it peaks. So what is going on here?
Update, So the period for the DevFee seems to correlate with a drop in difficulty. When there is a drop in difficulty (total mined shares goes up) the DevFee spikes. When the difficulty is high (mined shares goes down), then DevFee is low. So the DevFee effectively removes the variability in shares earned that is caused by difficulty fluctuation and keeps it for the Dev. So a flat average calculation is not correct and the stated DevFee is NOT 2% (before and especially after the change at Flypool).
I am NOT against DevFees and happily pay them, but NOT when I am lied too about what the DevFee really is.
Below is a scatter plot of total shares mined vs the DevFee shares mined. The right is before the earned shares halve and the left is after on Flypool. Either way there is a strong and steep correlation between mined shares and DevFee shares mined. So even a small increase in mined shares and the DevFee skyrockets (Its NOT 2% folks)!
I can see where you are going, but statistically this is almost three months of hourly data. I would suspect that changing the fee to zero would give you back the gains from difficulty variation but its likely not enough to make up for the loss in hash rate imposed by the Dev. Setting fee to 0.1 will still cycle with difficulty but will be much smaller (and I still think the Dev imposes a penalty for setting the fee lower). Either way I would need to collect a lot of statistics to do prove that.
Right now I am more concerned with the bug that has effectively doubled the DevFee on Flypool. If there is not a fix from the Dev for that then I need to switch pools to see if the issue goes away.
for my experience there is no penalty in your hash with -fee 0 , i used that code afttes 2 months of mining because i saw the same as you, devfee is a lot higher than expected
Sorry but that is not accurate. I pushed a --fee 0 to all my EWBF rigs and they returned to the same Hash rate reported by the miner and by Flypool before the change. Its pretty common for Dev’s to hide their Fee reported in the hash rate. The EWBF Dev is no different in this regard. So this change will not avert the 2X DevFee on Flypool with the EWBF miner, nor will it save you anything as the penalty is the same as the DevFee. I would be very surprised if it was different.
Update: Actually I take that back, its a bit early but it looks as the hash rate is lower. So the penalty is higher than the DevFee (my average hash rate is already starting to drop).
I have never pushed a change to a miner start command to all my rigs before, changing scripts for different coins and updating my software is built in, but I never considered needing to change the miner start command on all rigs at once. So I found an error in my hastily hacked code. I have restarted and will let run overnight. Still looks like at best the --fee 0 is the same as with the DevFee (so Devfee = penalty). I will try the --fee 0.1 tomorrow as you suggest and compare the results. I have already left a message for EWBF on the bitcoin talk forum, EWBF's CUDA Zcash miner.
You can try dstm’s Zec Miner, windows version was released a few days ago with better hashrate compared to EWBF. There’s a thread in bitcointalk and the dev appears to be working a lot on improving the miner. EWBF is just rich and lazy at this point.
Half a day after switching from EWBF to the Windows dstm version I can say it does provide a higher hashrate. My 3 rigs (21x EVGA GTX 1070) went from 9250 kSol/s to an average 9500 kSol/s. No change in settings, on flypool the entire time. Great work Dev!!!
ewbf-zcash appears to lie about the dev fee. The author claims a 2% dev fee. Yet I see that 9-10% of all my submittals are going to coinbase.pl under the name “terraman”
I assume that terraman is the wallet associated with the ewbf-zcash author? Unless someone knows otherwise.
As a follow up from my post before… on Ethos 1.2.7, I manually updated /opt/ethos/etc/ewbf-zcash.conf to include:
fee 0
and restarted ewbf. Once I did this, I confirmed that the ewbf process no longer attempted to connect to its random list of pools for dev fee deposits. I did a tcpdump for quite some time and could not find an instance of ewbf submitting its dev fee to its various wallets scattered around other pools.
So my question is if others see the same “success” by making this change? I did a lot of work on this (including subverting the dev fee with iptables, etc). But I no longer see a need for the iptables trickery.
