I encourage and implore all providers to rate their rigs at a true and accurate speed. Based on the last 24 hour performance. IE if your rig is hashing at a straight line of 2.17Mh/s you should rate it 2.15 or less. Pool Swaps will bring down the 24 Hour a bit. If your rig has downtime or hash-rate fluctuation you should account for that.
The newest site build will encourage this.
So if I have a renter that uses a bad pool, and my hash rate suffers, that's my fault? I should be rated as underperforming for the action of a renter?
My concern is real. I have this now, despite trying to contact the renter with info on how to select pools for better performance.
So how does this improve the accuracy of the info on the site? It just muddies it in a different way.
Right now, we are using current hash rate. So once your rig gets out of a lease and is relisted as rentable it will be based on YOUR pools. The above is not an issue.
Once the legacy pool logic is rebuilt and the pool test queue put in place the speed rating will be based on a rolling average. This does improve the site. Almost half of the rigs left for rent do not perform at their advertised rate.
Thanks for the response miavator, but you didn't answer my concern. You basically said, "once that renter with the bad pool goes away, your hash will go back up... eventually."
I'm still being penalized for the action of a renter. So I need to then run my own pool for 24 hours to recover my green color and star, all the while losing out on lease income.
Perhaps you should take the self-declaration of hash speed out all together from the site. What value does it offer if you're just going to judge the rig against actual hash anyway? Just show actual hash speed, or the 24 hour average with no comparison to the declared speed.
Also, there should be some mechanism in place so that if the renter fails to use an appropriate pool, the rig owner is not penalized. If the pool they entered is hashing below the 24 hour average, then they are rated poorly or the variance is tolerated from a reporting perspective.
And, I sometimes move my rigs from scrypt to scrypt-n, which has a significantly lower hash. When I do that, I should not be penalized for the drop in hash vs the 24 hour average.