Donors Advisory Board information and discussion

I'll second that. I haven't had any outstanding issues, but it would still be nice to see more openness from PG on principle.
 
may i be worthy said:
Donor Advisory Board can only be called stillborn and a dismal failure.
Click to expand...
This is not the case at all. There has apparently been a break down in communication between Xilikon, Team 33, and the DAB. I recently posted a rant in the beta forum about p2684 and Bruce (site admin) quickly sent me a PM asking me to talk to my DAB Representative. I replied back stating that I had assumed the DAB was dead but Bruce informed me that he knew otherwise and that Xilikon had essentially "given up" but declined to comment further. I have always had a good relationship with Vijay, so I immediately sent Vijay an email and he confirmed for me that Xilikon hadn't participated much at all in any of the recent discussions.

Vijay Pande said:
Hi,

I'd love to get your input in the DAB. I'll send an email to Bruce and cc you to get you involved.

It's surprising and a bit disappointing to hear that Xilikon feels like the DAB has been stagnant. I think the other DAB members would disagree. In fact, I recently asked them if they're happy with the DAB and the progress we've made and got only positive responses.

I'm not sure why, but it looks to me like Xilikon's participation in the DAB has been stagnant (he hasn't posted there in a long time). I'd love to get participation from your team. Thanks for bringing this up.

Vijay
Click to expand...

Vijay and Bruce gave me access to the DAB forum on FF where I was able to see for myself that Xilikon has not posted since Dec. 20th when the group was first getting things setup an intial discussions started. I assume Xilikon has just been busy with other things and I'm not attacking him.. I am just stating the facts as they have been given to me.

Therefore, I have assumed the role, once again, as DAB Representative for Team 33 and I'm catching up on the discussions that have been taking place in the forum. If people here would like to hold another vote to elect someone else, you are free to do that. Right now, I am just trying to get communication flowing once again.

Now, what is happening within the DAB you ask? Well, things are a little slow but it is not stillborn nor dead at all.

The changes made to the beta team forum, as applauded by MIBW in his "Change at Stanford" thread, came out of the DAB.

Points Consistency is being discussed across the board and we are specifically talking about p2684 at the moment. I will be presenting my own analysis of p2684 to the DAB and have asked musky and MIBW if they could also provide some of their analysis. If anyone else has something to comment on regarding p2684, please let me know.

Improving Communications is an ongoing discussion topic.

Formal adoption by PG of the Folding Best Practices Guidelines many of us participated in. I will talk about this in more detail, and to get some needed input from you guys, in another post.

So, in a nutshell, those are the big topics currently being discussed and, as I said, it is a little slow but forward progress is being made. In the next couple days, I will also create individual posts, with more detail, about each open subject. Additionally, if anyone has anything new to bring to the table, please let me know.
 
Tobit
Keep on keeping on! You were one of the big reasons it all got started. Just remember never to post while you are snarling. (or even frowning real hard for that matter)
 
Wow tobit. Fascinating stuff.

Thanks for taking the reigns. If you ate willing and able to continue in that role, I don't think anybody will suggest otherwise.

Looking forward to good things in the future.
Posted via Mobile Device
 
Glad to see this is moving again.
Seems it was moving without us.
Good job for picking it up tobit. Thanks!
 
it begs a question. What happened to Xilikon?
 
Yea....that does not seem like him to just "give up" for lack of a better word.

I hope everything OK!

Xil give us a ring and let us know how your doing!
 
This is really great to hear. Hopefully the point system balancing (if it occurs) can soothe a lot of the wounded egos that seem to be floating around sometimes.
 
Tobit: from what I can see the 2684's on the 2P and 4P systems have a 40%+ penalty over 6901's. I still haven't had a 6901 on the 4P 2.2GHz but have had lots of 2684's. 205K ppd on the 2684's and other units are minimum 335K ppd with the max, non-2684 running at just over 360K ppd thus far.

That is a really wide gap in ppd performance between WUs and I often see 1/3rd of the farm on 2684's. 10% or 20% is one thing. Succumbing to slightly higher WU loads by the lowest-end -bigadv chips like the Xeon X3400 series is somewhat understandable if one is on the edge to begin with. On the other hand at over 105GHz over the 48 cores, in a $3500+ machine is not exactly "on the edge" of not being able to do WUs. The variation of 10-15% is not bad, but the 2684's and any future similar WUs are different enough that they need to re-score. Just to give an idea on SMP's the 205K ppd 4P was actually pulling over 160K in SMP (0:46 TPF) according to HFM. That makes 2684 bonus, to me, look much closer to SMP than bigadv.

One idea would be to propose a base -bigadv and state that ppd/TPF times should not vary by more than 15% and 10% respectively from that base without requiring a new bonus structure. Otherwise the really hardcore may look to automate the jettisoning of 2684's from their machines.
 
pjkenned said:
Otherwise the really hardcore may look to automate the jettisoning of 2684's from their machines.
Click to expand...
oh geez we've been down that road....

I would honestly be comfortable if bigadv PPD were normalized somewhere between 2684 and 6901.
 
jebo_4jc said:
I would honestly be comfortable if bigadv PPD were normalized somewhere between 2684 and 6901.
Click to expand...
The question is where and how much of a points difference would be acceptable?

My E5640's:

p2684 - 50.6 hours - 36K PPD
p2685 - 35.7 hours - 62K PPD
p2686 - 34.3 hours - 66K PPD
p2689 - 35.5 hours - 63K PPD
p2692 - 34.6 hours - 65K PPD
p6901 - 34.6 hours - 65K PPD

I don't know how to do the math to determine if the 15 hours difference between a 2684 and a 2685 for a points difference of 26K PPD is an appropriate difference in points or not.
 
Thanks Tobit for picking up the torch. In fact I would invite as many people as possible to run a few frames of 2684 and 6900 usingMusky's benchmark

The big question I have never been clear on is: is there any bigadv benchmarking done at all? My impression is that bigadv work units are just released and the points fall where they may. Usually the issue is that benching is done on one machine, and differences to that will result in variances. I am not aware of any machine on any architecture that has 2684 frames times remotely close to 6900. You would think there would be some folks somewhere saying "no problem here".

So what are we trying to do? Is it the benchmarking system that is broken, or just fudge the one work unit that is the biggest outlier? Because while we are at it, the 2685 and 2689 could use some work.

Summary of my benching:

2686/2692/6900/6901 are pretty much the same thing and should be the baseline.
2685 - 9% to 10% slower
2689 - 10% slower
2684 = 43% slower on Windows, to 52% slower on Linux

SR2#1 @4.1Ghz on Windows

Project, PPD, Frame time
6900 153,000 0:11:34
2685 134,000 0:12:38
2684 90,200 0:16:30
6701 49,600 00:02:50
60XX 85,000 00:01:02

SR2B @ 4255Ghz 185 x 22: Turbo on. On 64 bit Linux with Krakken affinity wrapper

2692 - Avg. Time / Frame : 00:09:34 - 208,135 PPD
6901 - Avg. Time / Frame : 00:09:35 - 207,593 PPD
2686 - Avg. Time / Frame : 00:09:37 - 206,514 PPD
2689 - Avg. Time / Frame : 00:10:10 - 189,985 PPD
2685 - Avg. Time / Frame : 00:10:15 - 187,673 PPD
2684 - Avg. Time / Frame : 00:14:28 - 111,927 PPD

On DAB not being dead - that is terrific news BUT... you can see how we could form that opinion. Our rep was not interested and did not respond to questions, so be it. But nor has there been (to my knowledge) any public announcement of the DAB. The EVGA forums have a DAB sub forum - dead as a doornail. I am thrilled to hear DAB is alive and twitching, but given that fixing communication was kind of the main point, you kind of slap your forehead! If some of the successes I mentioned in the OP were due to DAB, then great, but guys... sign your work!

Anyway, very glad you are involved Tobit.
 
Last edited:
jebo_4jc said:
I would honestly be comfortable if bigadv PPD were normalized somewhere between 2684 and 6901.
Click to expand...

I am strongly of the view that we should use the 2686/2692/6900/6901 as the baseline, and correcting up the 2684, and if possible the 2689 and 2685.

Reasons are mostly psychological - not great for donor morale to cut the future points - people are used to discussing max points capacity of their rigs. People have made relative purchasing decisions based on capacity. I can't think of a better way to piss off more people than devaluing what they are used to. Forums will be overrun with all the "why did my machine get slower". Any "thanks for fixing the 2684" would be drowned out by the howls...
 
Last edited:
This is great news that communication is happening. I can see this bringing more good things for the folding community.

EDIT: Tobit is the man!
 
may i be worthy said:
I am strongly of the view that we should use the 2686/2692/6900/6901 as the baseline, and correcting up the 2684, and if possible the 2689 and 2685.
Click to expand...
I can live with the differences on all units except 2684 and I believe I can speak for musky on this as well. The small differences on the other units seem acceptable. However, I don't know if benchmarking is the issue with 2684 as it DOES take long to fold it so it makes sense that it should be valued less given the goals of the QRB system. In my example above, it takes 15 hours longer to fold a p2684 compared to a p2685 but I agree that the points difference seems exaggerated. As I said above, I don't know how to do the math to determine if the 15 hours difference between a 2684 and a 2685 for a points difference of 26K PPD is an appropriate difference in points or not.

I've asked Vijay if he could have Dr. Kasson give us an explanation as to what makes 2684 tick so we can understand the unit better. I know it isn't the number of atoms that makes it slower as other BA units have more atoms. p2684 is an older WU, one of the first to have switched from A2 to A3.
 
may i be worthy said:
I am strongly of the view that we should use the 2686/2692/6900/6901 as the baseline, and correcting up the 2684, and if possible the 2689 and 2685.

Reasons are mostly psychological - not great for donor morale to cut the future points - people are used to discussing max points capacity of their rigs. People have made relative purchasing decisions based on capacity. I can't think of a better way to piss off more people than devaluing what they are used to. Forums will be overrun with all the "why did my machine get slower". Any "thanks for fixing the 2684" would be drowned out by the howls...
Click to expand...

I think the fact that WUs vary would lead me to put an acceptable variation range on the entire process (e.g. 10-15%). Up-leveling the 2684's to the middle of this range should be easy.

Also, for those wondering, Haitch has an automated benchmark now for Windows that collects relevant information such as WU, OS, CPU speed, memory speed and etc and uploads that information to a MySQL database. Think of this as "muskymark" with automated system information collection like Jebo was working on.

The next steps are twofold. First, beta testing the Windows client so we can start gathering results. Second, developing the Linux client so we can see exactly how different configurations (hardware and software) perform. For now, Jebo's spreadsheet is the best we have, but automated data collection will make the process more consistent and scalable... and also make Jebo/ Musky the "Godfathers" of FAH benchmarking.

The first chance I get I will be firing up the new beta on my Windows machines and a few others have access to the beta right now (hoping that they do the same). Once the few have an opportunity to test, and it works, the plan is to distribute it to the broader audience. If you do not have access to the STH beta forum right now and you want to give it a go in a week or so, feel free to PM me here or on the STH forums.

Coverage and consistent collection will help drive the discussion regarding how much slower or faster WUs are, and we can use this information to feedback through the DAB.
 
That benchmark sounds really awesome. I hope that becomes a standard piece of software like HFM.net
 
Zink said:
That benchmark sounds really awesome. I hope that becomes a standard piece of software like HFM.net
Click to expand...

Thanks - I'm working on it :)

Once a couple more people from STH have run it, I think the current build should be ready to be opened up to a wider audience to test it with more hardware. And the more hardware, the better - what worked great on the i7-860, failed miserably on the i7-2600K. What worked great on those two, failed miserably on the Dual AMD hex cores.....

I don't want to OT this thread, so will start another to discuss the benchmark, all input very welcome.

H.
 
Just for giggles I ran Musky's bench on my old quadcore Q6600 1P machine, which is not fast enough to make the deadline:

Unit: 6900
Frame 1: 59 minutes, 58 seconds

Unit: 2684
Frame 1: 77 minutes, 46 seconds

That is only 130% slower - maybe we should all stick to older rigs ;)
 
Guys, I've presented all the numbers and opinions to Vijay regarding p2684 and here is what he wants from us:

Vijay Pande said:
To make this very specific: what do you think the points for P2684 should be? I can run that w/Prof. Kasson to see what he thinks and post his reply.
Click to expand...

So, how do you guys think it should be valued? Now, before you guys answer, it can't really equal exactly the same points as P6901 or other bigadv units can it? It DOES run a bit slower after all so it should be valued less, the question is how much less. As I said above, I don't know how to do the math to determine if the 15 hours difference, in my example above, between a 2684 and a 2685 for a points difference of 26K PPD is an appropriate difference in points or not.

So, how do you guys think it should be valued compared to other units? Be specific but not greedy. :D
 
I dunno Im not so sure why everyone is so hung up on 2684.
If you run any of those other projects at the same TPF, your PPD would be the same. And I think we can all agree that when you return it slower, you should get less points.
Additionally its not like its unfair.....its affecting everyone equally....unless you are cherry picking units, but thats a different topic.

It is just such a dramatic difference due to the bonus structure.

Mean seriously if we start down this path, its just going to open up the doors for whenever there is a slight difference in PPD because one unit is faster/slower than the average.

Mark me down as who gives a shit.
 
I think I'm confused how the points are determined.

They claim the units are run on a quad core i5 750 to determine the "benchmark" points. How is it possible that i5 gets the same amount of points on a 6701 and on a 60xx? They claim bigadv is benchmarked on the same system. I just don't see how that could be possible.
 
There needs to be a compromise between work done and time to complete. A harder WU that takes longer to finish should scale with a less-intensive WU that's quick to finish.
 
Based on MIBWs times, and excluding the QRB, it should be worth between 11,800 and 12,400 base poimts to earn the same number of ppd. If you then leave the K factor as is, it'll earn fewer points as it is slower, but it would be a more reasonable value I think.

H.
 
Tobit said:
Guys, I've presented all the numbers and opinions to Vijay regarding p2684 and here is what he wants from us:



So, how do you guys think it should be valued? Now, before you guys answer, it can't really equal exactly the same points as P6901 or other bigadv units can it? It DOES run a bit slower after all so it should be valued less, the question is how much less. As I said above, I don't know how to do the math to determine if the 15 hours difference, in my example above, between a 2684 and a 2685 for a points difference of 26K PPD is an appropriate difference in points or not.

So, how do you guys think it should be valued compared to other units? Be specific but not greedy. :D
Click to expand...

for some reason... be it the wu is more complex requiring more work or coding... the cpus are still running full bore... they tend to use more power on that unit... doing more work for less ppd doesn't make sense.

I find 13500 base pts for 2684 to fall around 5k pts less than 6901 and be pretty reasonable...

That make sense to be based on my understanding...
How are the point supposed to be set?
The longer a wu takes the less points it should be worth...
If all wu did equal amounts of work they should be equal points and you would get rewarded for turning it in faster....

If they are not all equal work the ones that require more work... should be worth more base pts in such that they don't penalize the folder for doing a harder unit....

again... thats how I understand it...
 
Patriot said:
I find 13500 base pts for 2684 to fall around 5k pts less than 6901 and be pretty reasonable...
Click to expand...
That would put it about equal with 2685 then, correct? They may find that to be too much. How would you, and others, feel about 12K base points?
 
Tobit said:
That would put it about equal with 2685 then, correct? They may find that to be too much. How would you, and others, feel about 12K base points?
Click to expand...

I think part of the problem is that the % difference is bigger on linux than windows...

so 12k base puts the difference at 50k for my monster and 5k for the low end.... basically the lower the base is the more it cripples the faster systems... which is kind of the opposite to the whole point of bigadv imo....
 
Tobit said:
That would put it about equal with 2685 then, correct? They may find that to be too much. How would you, and others, feel about 12K base points?
Click to expand...

Its in the middle of the range I calculated, so I'd be fine with it.

H.
 
At the same time, if you raise the base too much, it will start to be worth more on slower systems.
 
12k Is a compromise, they don't often rebase points for a project, Its not going to please everyone but i would be happy with that.
 
I'm undecided.

I'm also not convinced that the 2684 and the 6701 are the real problem here. I'm suspicious that the benchmarking system is broken in a serious way.

If 2684 is rebalanced, the outcry will begin about 6701, and after those the 111xx monsters.
 
jebo_4jc said:
If 2684 is rebalanced, the outcry will begin about 6701, and after those the 111xx monsters.
Click to expand...
There are less WUs that are supposedly "unbalanced" than there are those that fold consistently with similar PPD. 2684 is the only bigadv that people have an issue with. 6701/6702 are in hibernation at the moment and may or may not come back. Moving forward, we are also discussing how to catch perceived slow WUs before they leave beta testing such is the case with the new 7200 unit.
 
Tobit said:
That would put it about equal with 2685 then, correct? They may find that to be too much. How would you, and others, feel about 12K base points?
Click to expand...
It should be worth exactly the same as a 6901 in terms of ppd. 2685s and 2689s should be re-adjusted as well. Patriot hit the nail on the head as to why:
for some reason... be it the wu is more complex requiring more work or coding... the cpus are still running full bore... they tend to use more power on that unit... doing more work for less ppd doesn't make sense.
Click to expand...
I will not be happy with the points system until this is done. The compomise crap is just that - a compromise, and crap. Why does Stanford think these "points" are so valuable?? This really seems like a no-brainer to me...make your contributers happy at virtually zero cost to you...
 
Patriot said:
for some reason... be it the wu is more complex requiring more work or coding... the cpus are still running full bore... they tend to use more power on that unit... doing more work for less ppd doesn't make sense.
Click to expand...
technically, that's a fallacy.

we are doing more work for the same points.

...which results in lower PPD.
 
musky said:
It should be worth exactly the same as a 6901 in terms of ppd. 2685s and 2689s should be re-adjusted as well.
Click to expand...
So all bigadv units should equal the same PPD on the donors system and let the QRB reflect the faster systems.
 
Tobit said:
So get rid of the QRB then, because that is where the problem is.
Click to expand...
not necessarily. you could look at it that way, or you could look at it another way:

A work unit that requires more "work" should be worth a bigger base value.

If a 6901 requires "X" cpu time, why is its base value the same as a 2684 that requires something substantially greater than "X"?
 
Tobit said:
So get rid of the QRB then, because that is where the problem is.
Click to expand...

It takes me 40% - 60% longer to process a 2684 compared to a 2686, yet they are both worth the same base value. That has nothing to do with the QRB.

Edit: Sneaky T...but I caught your original quote, which is what I am replying to. Your edited post I agree with:
So all bigadv units should equal the same PPD on the donors system and let the QRB reflect the faster systems
Click to expand...
 
rmdashrrootsplat said:
There needs to be a compromise between work done and time to complete. A harder WU that takes longer to finish should scale with a less-intensive WU that's quick to finish.
Click to expand...

This is the expectation: relatively constant PPD. A given computer will crunch at a constant rate and should have the same PPD regardless of WU (with room for small variations). If a WU takes longer to run, then the computer is doing more work and should be rewarded with more points for that WU. As already mentioned, all bigadv WUs have the same point values, so it seems like no benchmarking was done to figure out the "correct" points for each bigadv WU. This is in contrast to SMP WUs, which do have different point values.

If the 2684 is changed to have 12000 base points, that's only half the issue. The PPD would then be about 75-85% of PPD for faster WUs, which is better than 55% but still out of whack. If the K factor was changed from 26.4 to about 40, in addition to changing the base points to 12000, then the PPD should be about the same (about 95% of the PPD for "normal/fast" WUs). This would need to be tested to make sure the math aligns with reality on a wide variety of bigadv-capable machines.

There's actually a third number that can be adjusted: the WU deadline. Currently the 2684 deadline is 6 days just like the other WUs. If it were bumped to 9 days, the PPD would scale very well with base points at 12000 and K factor left at 26.4. Note that the bonus deadline is not part of the formula, just the final deadline, so the bonus deadline could be left at four days to continue to prevent slower boxen from running bigadv.
 
You must log in or register to reply here.
Back
Top