Folding Forum

wow...my head's reelin after reading through 17 pages... lot of info to cram into my small brain in a day

I was giving this another thought and wanted to ask something I haven't seen explicitly mentioned but I'm curious to see if someone else is able to pick up on it and maybe expand on it.

Look again at the axis. Completion time and Credit. We want the increases in the range where most folder would fall, but not the increases beyond a certain point. Ther axis imply time and credit, so the easiest way to prevent the scale to work good in the 'normal' range but maybe not so good in the 'top systems' range would be to built in a mechanism which keeps the right part of the slope ( in my own images ) but levels of the left side. Giving just logic and no math skills I would like to ask who can create an equation which takes a certain preset lower limit ( with completion time ) or a certain preset upper limit ( Credit ) and which devaluates the increases after that point so that they don't go through the roof?

Add a new field other then the deadline or use a fraction of the deadline, or use the credits as a limit as I think a time field would be harder to give a smooth transition from one slope ( original qrb ) to the new one ( qrb with increment limit based on ??? ).

But, I think getting that 'right' would require insight in what a work unit should be really worth, since you have to decide where the transition should occur and how much it should devaluate the original qrb increments.

Edit:

If you want accurate graphs, click on 'Browser', download a new projectinfo set ( the project mainly used as comparison in this thread has had some recent changes I noticed just now and my project database file is using old one's ).

Edit2:

What I'm thinking of is this Changing the root will give a totally different slope which we don't want ( this is the same as math.sqrt ), but it should be possible to add a limit here based on a; the time between the 'expected' return and the actual return, or b; the set credit limit ( in this case the limit wouldn't apply to this line but You can't lower the multi or change the project worth, but you can decrease the amount of points with a percentage of the total credit?

Well, I created one proposal with OpenOffice Calc. The picture below has a capping formula that converges with the original one. For simplicity, I didn't include the "final deadline" case - we are talking about bonus points formula, after all.



The formulae are

1. IF( A3 >= deadline_length; base_points; base_points*SQRT(k*deadline_length/A3) ) - the original one, A column is time, A2 is 00:00, A3 is 00:01 (hh:mm)
2. IF(A2<=T*deadline_length;offset+base_points*SQRT(k*deadline_length/(A2+P*deadline_length));IF(A2>deadline_length;base_points;base_points*SQRT(k*deadline_length/A2)))

Second one has two new parameters.

• P (Preset, % of preferred deadline, above 0%, below 100%) is basically the cap
• T (Threshold, % of preferred deadline, below 100%, above P) defines where the capped curve begins to diverge from the original one

The spreadsheet(s):
QRB_proposal.ods
QRB_proposal.xls

Feel free to experiment with the parameters and let us know what you think of the formula. What would be acceptable values for P and T? Mind you, this is just a proposal, but it does provide convergence with the original, eliminates "divide-by-zero" problem, as well as proposes a basic method for setting a cap and shaping the bonus curve. Not perfect solution by any means, but a concrete proposal nevertheless, as requested by PG. Might have a bug or two in it, though. Such as the temporary flat line in the proposed bonus curve. Then again, you could consider it a feature - a no-man's-land between tough folders and the really tough folders...

EDIT: Formulae and spreadsheets updated, the picture still is an old one.

That looks like what I wanted someone to do ( only looked at graph, will check details when I have more time ).

Edit: as I said this looks like the only example poste which does what was asked, bravo I am afraid my lack of mathematical insight shows as I don't understand the formula. I can't see what's happening so I can't comment sadly, I do find it interesting, I would like to be able to 'fix' it since I think the flat line shouldn't happen if you start decreasing increments after time period, since you could use the time between that moment and the actual time as grade on how much to decrease the increments from the original formula. I don't want to imply that's not exactly what you're doing, I can't follow the formula posted sorry If you want to, could you maybe put the formula in a flow diagram so even I can understand it?

Busy day today, I'll see if I can work on it and maybe provide some pseudocode (hopefully with linear interpolation). Basically, it's a simple timeshifting formula. If elapsed_time gets below certain Threshold (fraction T*deadline_length), time fraction (P*deadline_length) gets added to the actual elapsed time when computing bonus points. P provides a cap: even if one returns a WU in (near) zero time, P*deadline_length gets added to it in bonus point calculation, eliminating the near-zero division whose result approaches infinity.

The problem is the discontinuity between (T-P)*deadline_length and T*deadline_length. In my current proposal, the discontinuity is dealt with a flat bonus point line, but I suppose a points offset and (linear) interpolation could be used as well to connect the two curves (non-timeshifted and timeshifted).

I've restarted all my machines running Bigadv with the "oneunit" switch while I consider my position on these current changes,
once the amount of devaluation of my machines is worked out I may continue....

.

"Ivory tower" springs to mind ...

.

noorman wrote:.

"Ivory tower" springs to mind ...

.

And guess who built it ?

When bigadv was brought out, it required 0.5GB per core... now the whole thing fits in under 1GB, this adjustment is late, but in my opinion (a bigadv folder) fair.

Well, until recently at least...
Everyone is entitled to their opinion, but if in the last 6 months you'd just built an SR-2 rig from scratch and recently upgraded 3 x X58 rigs to Hex core Cpu's
you may think differently, but maybe it is just me........

.

It 's more and more becoming a question of yield versus costs and no-one likes to get less for 'his money'.
The big commercial players in this world do enough of that day in day out.
Selling us stuff for the same price, but secretly lessening the amount of 'stuff' you get for it!
It 's hidden and many don't notice; F@H is openly, without wider consultation and ignoring polls on the issue, downgrading credits that have been there for a long time.
This is untimely.
It also doesn't take in to account the ever increasing costs (for donors) to run their systems, mainly the energy bills.
For that reason alone, things should be left as they were.
On top of those, there are the ever returning costs for hardware upgrades if one wants to keep up with 'progress'.
The donor is already 'paying' more for those credits than a year or 2 ago, solely with his higher power bills.
It 's because of expenses/costs that I had to quit F@H after 6 years of continuous Folding ...

This kind of degrading is discouraging, to say the least.

.

Bigadv has always been a beta release, and one of the principle caveats has been that the points bonus for running bigadv is not guaranteed, PG may adjust the bonus.
A key point of advice has always been not to build systems to target a current WU sweet spot, as that can change. (Nvidia GTX430 users found this last year when GPU3 WUs moved to larger atom counts after the initial beta WUs.)
It looks like this current change in bigadv base bonus will result in an overall reduction of 20% in the total points per bigadv WU.
This will still leave bigadv as the most productive client for multi core systems, it will just reduce the advantage.

.

Sorry, now your mixing unrelated things! http://en.fah-addict.net/articles/artic ... -units.php

We 're talking about complete CPU system upgrades [Edit](CPU + mainboard/costs)[Edit] with larger amounts of RAM (costs) and higher demands on Internet data volumes (speed/costs) to keep up with demands for multiple CPU-cores and RAM ...
not about GPU Folding
EDIT: I 'm going by what PG mentions when they up credits or give bonuses / haven't checked any usages, can't anymore now (stopped F@H as mentioned before)

.

Noorman.

Internet usage for bigadv was LOWER than running regular smp (hence why I switched to it as in NZ we have horrible data caps) - larger files but the infrequency offset it. As to RAM, as I said, with the early core, .5GB was a lot more, but following the shift to the new core, RAM was not much of an issue (coming from one of the people that dropped an extra 6GB in when it was first introduced). I don't need that ram now.

As to the yet unmentioned "if I lose a wu at 99% I lose two days of folding", unless the fail % is higher, say 2% of workunits rather than 1%, the amount of downtime is still the same. Just larger but less frequent.

GPU3 shows that ppd changes, PG advice has always been that you shouldn't base machine purchases based on current ppd.

QRB is still in effect, faster machines still earn a crap load more points than regular machines, so I am really not sure what the complaints are about...

.

Again, GPU3 or otherwise has nothing to do with Bigadv

If Bigadv guns for more CPU cores, a donor wanting to Fold Bigadv has no choice but to invest in a suitable CPU and matching mainboard (certain makers like to switch to another socket for a new CPU family)
At that time he does that in the knowledge of a certain yield for said hardware and investment.
Now, after considerable time, he gets less for what is costing him more in the meantime ... (being higher power bills, mainly)

The demands for RAM may be flexible in PG's software (better use of RAM f.e.), a donor hasn't that flexibility with his purchased hardware (though). If demand has diminished, he can't return half of his purchase to correct and save ...

.