@mdk777
Well what we want to achieve is preventing the need to display the ppd/total credit using a factor. Nothing more nothing less, as far as I'm concerned. I don't know how to fix that without normalizing the ppd, which in effect would normalize the totals ( not entirely, as totals will eventually still grow very big but not as soon as when not fixing the exponential growth in ppd based only on computational increments ).
@vbironchef
mdk777 is not sad, nor is he not using common sense. He wants, just as I do, to be able to correlate ppd to science. That's an historical premise of f@h, donor's can see how much they helped the science but looking at their ppd. You can not claim that is sad, as the other way to measure points is always based on keeping as many donors happy and not on the science.
I concur with the reason he doesn't want to normalize, I just also know it will need to happen at some point in the future.
@K1w1
As to describing the solution as a common proposal, even that's going to far as it's something which was mentioned already a really long time ago, and as you pointed out the analogy with a monetary system it's also something which has come up for many different problems. It's an universal solution to an universal problem, with the added complexity that Y in a monetary system is already defined. I'll be more then happy to call this the k1w1 formula if you succeed in making it work
It's to early now to be claiming 'ownership'. Sorry btw if I was harsh, that's not the intent. It's safe to say I should have been less negative at the beginning of this thread as you're not just repeating things which were brought up before. I appreciate your efforts into making this a point of discussion, it's something which even if people don't see it now, can not be avoided as a point of discussion at some point in time.
I also looked at the qrb formula and failed to put Y in there in a way which would work
As I hinted to already, I'm quite stuck here besides saying: ppd = ppd / y and let PG come up with Y by benchmarking common fahcore functions ( which I proposed as well as keeping historical work units and rebenching them each time ).
Your graphs show that QRB will still make the ppd growth exponential, and I agree. But I can't agree with changing it to be less then exponential unless you can come up with a way to prevent people running multiple instances instead of one. PPD is not only meant to measure, it's also meant to give directions on how to tun the project. Even forcing each client to always use all resources for one instance would just make people use vm's to run multiple instances unless you give an incentive to return work unit's quicker.
Btw I have to admit I don't like the graph layout, time should go from left to right, and I don't understand the flat sections before they start raising. I'm also color blind to the point where your legend isn't clear so I'm having to guess which line is which revision ( though that I think I'm not making a mistake on ).
What we want is a fixed line PPD, and as a result, without looking at the formula, the QRB should be a fixed line above the normal base PPD. But as I said already, a fixed line equates to a linear increase, and that I don't think is something which makes the cut. PPD as a fixed line would need QRB as incremental line above it, but resetting it on each normalization. That would make the QRB line still grow, but it won't grow exponentially over time. The manner to reset it, would be using Y in relation to speedup factor. Edit ( just as you proposed already in the post with the graphs
). What happens in the graph if you do that? ( sorry, 1:23am don't feel up for making my own graphs, been a long and exhausting day and I'm going to bed ).