• Welcome to Overclockers Forums! Join us to reply in threads, receive reduced ads, and to customize your site experience!

News from the DAB

Overclockers is supported by our readers. When you click a link to make a purchase, we may earn a commission. Learn More.

ChasR

Senior Member
Joined
Apr 12, 2004
Location
Atlanta
Not much has been happening in the Donor Advisory Board. Discussion of deadlines and client side benchmarking is the latest, but the discussion has died. Here is where it ended:

kasson said:
Re: Deadlines

Postby kasson » 08 Aug 2011, 15:31

How long will it be before we switch to a client side benchmarking system?


Good question and not something I have the answer to. As currently structured, the client-side benchmarking would come from a development effort that Dr. Pande manages.
I am reluctant to use -bigbeta to denote higher-performing machines; I think we already have a donor perception that beta work units have higher points yield (something we try to avoid), and I'd rather not cement this opinion. It's important to us that we have beta testers primarily motivated by a desire to help out more than to earn maximal points.

The question of where to put the deadlines is tricky. For 6903 and 6904, each trajectory really becomes useful to us only when it gets to about generation #20. We'd love to have some trajectories out to 50+, but it would be more important to have all the runs have 10+ clones to generation 20 than to have 3 run/clone pairs to generation 50. That said, having all the run/clone pairs to generation 10 means that none of them are useful to us yet. That's the kind of calculation we're doing. While in theory it would be possible to automatically modulate project allocation according to how many clients of what capacity are available, it requires both additional sophistication on the AS and additional information regarding client performance that we don't currently possess. (In addition, when you think about balancing this out across all the FAH projects, it starts to get really complicated.)

Hopefully that gives you a flavor of what we think about science-wise when setting project/machine capabilities. We're also trying to balance all the donor concerns that you're likely more familiar with.

User avatar
kasson
Pande Group Member

Posts: 2108
Joined: 29 Nov 2007, 17:37

Deadline discussions have revolved around shortening the deadline to exclude the Virtual box core trick that allows i7 2600Ks to appear to be 12 core machines to the AS. Unfortunately that would also mean many slow 12 core machines wouldn't make the deadline either.
 
Last edited:
Thanks for the update.

Deadline discussions have revolved around shortening the deadline to exclude the Virtual box core trick that allows i7 2600Ks to appear to be 12 core machines to the AS.

It appears i need to pay a little more attention...........This is the first i've heard of this.....:shrug:
 
Yes, definitely... Thanks ChasR.

I'm in the same boat as you cuda... first I've heard of it. I assume those 12-core bigadv units still do well enough on 2600K to make them worth it over standard bigadv. I'm curious to see the numbers.
 
It's the same trick the 6 core AMD folks use to get -bigadv.

A 2600k @ 4.7Ghz can complete the P6904 (the longer WU) in 4.68 days, ~78,500 ppd.
 
So... virtual box you say huh? :D

I have 12-core server here at work (AMD) that I doubt would do much better (probably worse) than a 2600k @ 4.7GHz. Sadly I cannot run FAH at work though. So, shortening the deadline would effectively excluded those machines as well... even if they're within the targeted hardware envelope (12-cores). I don't think that's right.
 
It's not really virtual box. Environment variable can be set in Linux that make it report 12 cores being present. The trick works in native, VMware and virtual box.
 
Just so you guys know I'm not slacking, the last post in the DAB is dated August 19th. Anyone have any great new ideas they want to propose?
 
Not at the moment........I'm alright with a lull in the action. Too much work and not enough time as it stands. :sly:
 
Just so you guys know I'm not slacking, the last post in the DAB is dated August 19th. Anyone have any great new ideas they want to propose?

Very exciting stuff, huh? ;) I know the feeling...


The only thing I'm concerned about is the longevity of the v.6 client, if it is discontinued I'll be disappointed.
 
I highly doubt they're going to kill it off anytime soon. Heck, just a couple years ago v5 clients were still working... not sure if that's true now, but. Work (my job) is going to slow down here after this week, been pulling 10-11 hr days here for the last couple weeks. I hope to rededicate as much time as possible to getting v7 support worked into HFM after things slow down. v7 is so different that I probably should have just thrown a lot of HFM away and started over. You never know, might be the quicker route... especially I want to make HFM a complete FAHControl replacement.
 
I think v6 will be around for some time to come. Like TiIm, I suspect there will be new cores that are v7 only and they'll get the good WUs.

However, the v7 client is improving rapidly. It'll now install SMP + GPU automatically in Windows. It still has some trouble installing on some of the various flavors of Linux. If/ when it will run a gpu in native Linux and it can be monitored , it will be time to embrace it.
 
v7 is so different that I probably should have just thrown a lot of HFM away and started over. You never know, might be the quicker route... especially I want to make HFM a complete FAHControl replacement.

After spending some hours already trying to figure a way to easily hook-in v7 to my existing code base I've decided to cut my losses and pursue the avenue I spoke of above. To really do what I want to do long term (an FAHControl replacement), it makes more sense to scrap the front end (basically the primary UI and some supporting stuff) and start over from scratch. This won't be a complete rewrite... I'd say ~50%; mostly things forward facing to the user. My Log, Queue, and Client (v7) APIs are good to go. So I have access to the data. It's more about designing and presenting for v7 and not v6 whilst also maintaining a compatible path for v6.

I think I'll have fun this way too. What I've experienced so far trying to hook-in to the existing code has not been (a.k.a. spinning ones wheels); and if it's not fun then it's not something I'm going to want to spend my free time doing.

So, stay tuned... now that this decision is out of my way I'm actually excited about v7! :)
 
Finally a post to repot on in the DAB.

How are things going? Feedback requested.

Postby VijayPande » 01 Nov 2011, 20:40
We've been pounding in several areas to try to greatly improve the donor experience, especially in terms of the client and the server. The client changes are more obvious, but the WS backend is also behaving (in general) a lot better these days I think.

I was curious to hear what DAB and Mods thought. What are the pressing issues from the donor point of view these days? I ask since we can see some light at the end of the tunnel for the v7 client to be released and so it's a good time for me to start planning long range thinking. So, it's useful to get feedback from others to incorporate into that planning.

While I can't promise that we'll do all of your suggestions, it's good for us at least to know what's on donors' minds and what's their concerns, and try to to do the best we can with the resources we have to address them. In general, people on the forum seem pretty happy with FAH, but I'm curious to see how we can improve things further.

Here's our chance to have some input. I'm going to start another thread so as not to clutter News from the DAB.
 
FInally news from the DAB
Pande Group is concerned that there is a surplus of SMP WUs and a shortage of -bigadv WU. They are considering several approaches. Increase SMP points to bring them closer to bigadv. Increasing the -bigadv minimum requirement, which would eliminate the 2600K as a -bigadv folder. Decreasing the deadlines on -bigadv. Decreasing the -bigadv points. Revamping the whole points schemes.

They decreased -bigadv points once, so I will bet on increasing the SMP points, introducing a QRB on GPUs (ridiculous in my opinion), and introducing a QRB on uniprocessor work. Throw points at any problem and depend on fresh meat to keep the science flowing. Nothing makes a newbie happier than to blow past an old timer and proclaim their greatness. ;)
 
Here' the even latest (I bet wrong):
Re: How are things going? Feedback requested.

Postby VijayPande » 10 Nov 2011, 11:36
In order to get donors info ASAP, I'd like to finalize a plan. Here's my proposal:

We increase the limits for BA to 16 cores (with the analogous change to the deadlines to force the need for these machines). This will become effective no earlier than Jan 15, 2012.

That would give 2 months notice. It's not 4 to 6, but realistically, I think that's just not possible right now. However, I am happy to try to work towards the goal of more advance notice. I think with some effort, we can let people know 3 months ahead of time for future changes. Also, for now, that would mean no change to the points.

I'd like to get this to the donors ASAP, so please let me know if you have any "show stopping" concerns. I understand the concerns regarding points and the need to update points, but I want to take more time with that. For now, we need to realign BA now.
 
increase the limits for BA to 16 cores (with the analogous change to the deadlines to force the need for these machines)

I think changing it to 12 cores would do what they want without stirring up a Shitstorm.gif

Do they even have enough donors with 16 core machines to do what needs done if they made that change?? :shrug:
 
Back