Rewards are steady for 5 years.
I would assume down the road hardware specs will be shown when renting. A raspberry pi and a datacenter server do not serve the same clientele.
CPU benchmarking for reward calculations
1 Like
Food for though, Flux has minimum events per second (EPS) for its node tiers.
https://runonflux.io/flux-nodes.html (ctrl+F eps)
1 Like
That’s cool. You can do your own test with command lines.
I wonder about EPS vs passmark. Which is more precise and effective for assessing the quality of a 3node.
Interesting. I wonder how they arrived at these figures for Flux.
Based on my reading, they are using sysbench, particularly the included prime number test for CPUs. If you read up on PassMark, you’ll find that this is one of a suite of tests which get aggregated into the overall score. You can also find a free download for Linux/MacOS at that link for testing, as well as a trial version for Windows.
EPS is kinda like hertz–it’s just a measure of frequency that could be applied to any kind of event. In this case, it’s finding prime numbers, which is a useful but limited way to measure CPU performance. There are other tests bundled with sysbench that would give different perspectives on the performance of a CPU or system.
So, PassMark seems like a convenient way to test CPUs more holistically, while sysbench has the advantages of being open source and extensible.
2 Likes
What if the payout takes the average of all running systems passmark and then tunes the payout multiplier based on are you below or above the average? This can be implemented in a way that it starts with a small penalty but it increases to the desired goal through a year.
But judging the cpu speed just by that is not realistic. The more cores you have the more overhead there might be in the system if you have lots of stuff running. I would rather run my 4 cpu load on a 4 core machine alone than on a busy 24 cpu machine even if it’s faster.
Some more factors:
Ram speed
L2 cache size
Ssd speed
Utilization
E.g. Heavy IO towards disks(ssd and hdd) can get the whole system to a crawl, especially if you have say SMR disks and you trying to showel a lot of data to them. And the fastest cpu won’t help there.
This can be partially adressed by using cgroups, don’t know if TF uses it.
The one thing I’m not sure I saw was real usage payouts. So if some system is running a contract, does it get a share? If that’s the case then that solves pretty much the problem, as a more capable system will be able to run and keep more customers and the thing will self regulate for the most part.