Work unit auto configuration system?

Moderators: Site Moderators, PandeGroup

Work unit auto configuration system?

Postby Xavier Zepherious » Mon Oct 08, 2012 8:00 am

I don't know how hard this would be to implement

as you know we have people that have run both GPU and SMP
and in some situation drop core count to 7 or 11 or 10 to free up a core for the GPU's

some SMP fail under odd number core counts

hence why can't you build a record or WU list (in the client ) that configures the slot for exactly what cores you run with a specific WU?
it would default to your original config(most like SMp8 or smp 12) if there was nothing on record

it would require the user, to add a WU config if they wanted something specific
Xavier Zepherious
 
Posts: 138
Joined: Fri Jan 21, 2011 8:02 am

Re: Work unit auto configuration system?

Postby bruce » Mon Oct 08, 2012 11:05 am

I don't think it's likely to happen any time soon.

At the current level of technology, GROMACS is unable to predict which projects or which WUs are likely to fail with 7 cores. They know that the chances of an error increase for certain prime values of core count but not well enough to tell you if it's safe to fold a specific project or to reconfigure your system. In some cases, 7 works just fine; in other cases it doesn't. A decision to exclude smp:N for certain values of N was made only after they had gathered enough historic data on a number of projects. (Some projects did work at some excluded values, but I don't think anybody knows why.) so there's no way to permit specific future projects or WUs to fold at, say, smp:15. If the failure rate is, say one out of 50, there's no point in configuring specific machines differently based on who happened to have one of those failures.

As far as using SMP with GPUs. OpenCL is able to treat a multi-threaded CPU as an alternate OpenCL device along with your GPU. Someday technology might advance to the point of being able to partition work so that part of it is done on the CPUs and part on the GPU but it's not yet reasonable to make the software come up with a unique way to process every WU on every combination of hardware. The problems discussed above, where we're talking about failures when every CPU is equivalent ("Symmetric") would become immensely more complicated when trying to balance the distribution of GROMACS work to N CPUs and to M Shaders.

The technology is still several lifetimes away, but computer generations pass quickly. I expect that FAH will be one of the pioneer when it becomes feasible for the type of analysis involved in Folding.
bruce
 
Posts: 22701
Joined: Thu Nov 29, 2007 10:13 pm
Location: So. Cal.

Re: Work unit auto configuration system?

Postby Xavier Zepherious » Mon Oct 08, 2012 4:59 pm

I wasn't asking the system to config it itself like that

rather that we user select/enter the WU and core count and store it.
when the WU get downloaded to the client it then configures the client for the amount of cores the person selected for that WU
if there is no user selected setting for the WU it goes to a default setting like when you initially installed like 8 or 12

all that would be required is that the system store that info on the hard drive as a simple list that has WU and core count on it
and when the client gets a new WU we use the user inputted info to run the cores (if no WU in the list runs at default SMP 8 or 12) other wise it uses the core count the user entered in the WU list
it be for those willing to enter settings when they realize they have new wu and it be implemented on the next one it see of that type(rather than the one currently being folded). if it fails it can be auto reset to the default (so the next one doesn't fail)


non too difficult
nothing for the client to test

and users know which WU's their particular system run into trouble with

it be the best way for user to optimize their systems,
its better than the system dropping WU's because they set at smp7 and they fail a bunch of a particular WU

and of course you would also have to give the option to disable use of it (you may prefer not to use it)
Xavier Zepherious
 
Posts: 138
Joined: Fri Jan 21, 2011 8:02 am

Re: Work unit auto configuration system?

Postby 7im » Mon Oct 08, 2012 5:22 pm

The WU list changes like the weather. It would be a never ending cycle of updating your own configuration, and for very little gain in performance. Also considering the Projects that fail on SMP7 are very rare.

I'd much rather have them work on fixing the problem of why SMP7 fails for some projects. I think that would be a better use of their development time.
How to provide enough information to get helpful support
Tell me and I forget. Teach me and I remember. Involve me and I learn.
User avatar
7im
 
Posts: 14648
Joined: Thu Nov 29, 2007 4:30 pm
Location: Arizona

Re: Work unit auto configuration system?

Postby bruce » Mon Oct 08, 2012 8:03 pm

If you are able to predict that the current WU needs N cores and the next one you receive is going to require M cores, you can reconfigure the client. The new value doesn't go into effect until the FahCore is restarted.

I'm with 7im:
I think that would be a better use of their development time.
bruce
 
Posts: 22701
Joined: Thu Nov 29, 2007 10:13 pm
Location: So. Cal.

Re: Work unit auto configuration system?

Postby Xavier Zepherious » Mon Oct 08, 2012 9:27 pm

Eventually you get a complete list and only update when New WU's come out (at your leisure) since it will default to SMP8 or SMP12
this be more like fine tuning
some GPU cores can run on smp8, some require more cpu cycles like smp7 or smp6 or smp10

look this is just an idea it doesn't or shouldn't require a lot of hard coding changes (as a programmer I know)

the other thing is a nice history list of wu's that track AVG tpf and points for each wu (rather than resort to third part apps)

and yes smp7 or smp11(or a fix for odd number of cores) would be nice to fix for some WU's
(but as we have noted that this problem been around for awhile and no progress on fixing it yet)
Xavier Zepherious
 
Posts: 138
Joined: Fri Jan 21, 2011 8:02 am

Re: Work unit auto configuration system?

Postby 7im » Mon Oct 08, 2012 10:22 pm

Easy to code? So you've seen the fahclient and fahcontrol code? And so you're saying it would be easy to detect the Project # of the next WU when it downloads while the current WU is at 99% complete. Then can wait for the current WU to finish, then read your new config settings and see if they apply, then change Core counts in the config file, then restart the client, then start the new work unit? And can handle restarting the client when it runs as either a service or a process? And doe this for Linux and Mac OSX as well? Great! If it's so easy, please submit the code. If it works, they might consider adding it. ;)

WU history idea was already denied. There is little need to add complexity to the client when 3rd party tools already do it very well.
User avatar
7im
 
Posts: 14648
Joined: Thu Nov 29, 2007 4:30 pm
Location: Arizona

Re: Work unit auto configuration system?

Postby bruce » Mon Oct 08, 2012 11:28 pm

Xavier Zepherious wrote:look this is just an idea it doesn't or shouldn't require a lot of hard coding changes (as a programmer I know)

the other thing is a nice history list of wu's that track AVG tpf and points for each wu (rather than resort to third part apps)


What I don't understand is why you think this data should be collected on every client. To my way of thinking, it should be collected once on the server and it should apply to everybody. If you know that project X fails on SMP:Y (say for Y=7) why should the server have to distribute to others who are running SMP:Y rather than withholding it from anybody who has that configuration?

A first step would be adding a feature to the server code that allows the server to withhold project X from clients with SMP:Y. It could be set manually by the project owner rather than setting up a system to track every project against every value of Y.

Getting enhancements into the code is a very slow process unless they're really bugs due to the backlog of more critical issues. IIABNFI

How many more WUs per month would FAH process with this enhancement than without it?
bruce
 
Posts: 22701
Joined: Thu Nov 29, 2007 10:13 pm
Location: So. Cal.

Re: Work unit auto configuration system?

Postby Xavier Zepherious » Tue Oct 09, 2012 9:15 pm

no one can refuse a WU (nor should they)
no program or app or changes should allow users to refuse WU's
you get what you get...im for that - it's fair and even. Im not screaming I lost Bigadv, that fine as long as the point system is made fair too
I have my issues with QRB both bigadv/smp (rebalance needed) and some low valued returns in SMP...not saying there isn't room for improvement there and maybe discussions about it - just listen to people

nor should any changes/program/app allow one to mimic more cores than one has (a hack) ...I think we all agree there

all it would do is config the client to run smp6, 7,8 or smp 10,11,12 depending on the SMP Wu it got
yes you could hold it in one site(read it and have all computers config the same) - but some machines may not fail on SMP7 while running GPU's
and some users may want differ core counts on different WU's
and user don't want to keep resetting the clients for different cores(lots of work) unless it can do it automatically

yes there would be some time/effort in setting up the WU's as they come in
you could make a default WU list file - that people can change manually too

At least Im thinking of things that can be looked at rather than shoot ideas down or complain(gripe).

I suggest an Idea ...I get gripes... exact opposite of what you're suppose to do...listen ...maybe add alternatives, ideas

yes I would like the cores to be all fix to work on all core counts and run the GPU's with no loss of PPD with minimal CPU usage..that would be nice
but that might take a lot of time(to fix the bugs)...probably more time than this would take to add in
and this would fix some of the issue

there are lots of things on your list like smp fixes,Kepler cores, SMP & Bigadv QRB, GPU QRB (promised)
I realize the time and effort that is required...Im a programmer

You have limited resources/staff/programmers
it's about scheduling and just getting things done... some things needed first(even if you have to get outside help or hire more programmers or use more student programmers)

And I realize this would not hit the top of the list ..this would be something to bounce around and contemplate
just that isn't there room for discussion on new things or idea for the client, or on the points system.
A honest discussion as long as it doesn't turn into a gripe fest(or anyone be censored) would be nice

if you all think it's a bad idea... that's fine too.
at least Im trying to think about stuff to make it better
Xavier Zepherious
 
Posts: 138
Joined: Fri Jan 21, 2011 8:02 am

Re: Work unit auto configuration system?

Postby Xavier Zepherious » Tue Oct 09, 2012 9:49 pm

7im wrote:Easy to code?


: Easier than fixing the cores

7im wrote: So you've seen the fahclient and fahcontrol code?


: I wish I could - open sourcing it would probably be a better way to operate/develope on a limited budget or resource scale (like programmers).
More eyes on it can lead to more ideas, fixes, possibly done in less time.

I also realize this is not a good idea because of securing the code from hackers/modders and protecting the WU data collected (to keep it valid)

so what would be required is a closed system that is open to adding some secure outside help, developement groups or team, or even a few selected for their talents
------------------------
7im wrote: And so you're saying it would be easy to detect the Project # of the next WU when it downloads while the current WU is at 99% complete. Then can wait for the current WU to finish, then read your new config settings and see if they apply, then change Core counts in the config file, then restart the client, then start the new work unit?


honestly the system can/should be able to download a unit before the other one finishes - not any more or less efficient - because the same data has to be sent or Downloaded
-----------------------------------------
7im wrote:And can handle restarting the client when it runs as either a service or a process? And do this for Linux and Mac OSX as well? Great! If it's so easy, please submit the code. If it works, they might consider adding it. ;)


you have a gui - that stops and start the process on a whim - you have a pause button - what more does it take to pause/stop SMP a few sec's determine the WU' and restart the process(just the SMP with the new config)
the GPU doesn't need a core count only the SMP - GPU doesn't have to stop(separate process) - just SMP - well between SMP you can reconfig the SMP (at least should be able to)

-----------------------------------
7im wrote:WU history idea was already denied. There is little need to add complexity to the client when 3rd party tools already do it very well.


And then we are at mercy of 3d party - which may come/go and may not update when you come out with newer versions of the client
I agree I can use third party - but why not add it to the client - work out an agreement to work together to add apps to the client so people don't have to look for it - give incentives to those developers in that course as well

[/quote]
Xavier Zepherious
 
Posts: 138
Joined: Fri Jan 21, 2011 8:02 am

Re: Work unit auto configuration system?

Postby 7im » Tue Oct 09, 2012 10:06 pm

With PG's resources, the fahclient will never be all things to all people. That is actually one of their design goals. KISS. Easier to program, easier to support, easier to maintain. So yes, if the 3rd party people don't keep up with client development, you will lose WU tracking. Not a big deal to either the over project performance, or to the average folder.
User avatar
7im
 
Posts: 14648
Joined: Thu Nov 29, 2007 4:30 pm
Location: Arizona

Re: Work unit auto configuration system?

Postby bruce » Tue Oct 09, 2012 11:52 pm

Xavier Zepherious wrote:honestly the system can/should be able to download a unit before the other one finishes - not any more or less efficient - because the same data has to be sent or Downloaded

Are you talking about V6 or V7? It sounds like you're still running V6 and this forum topic is for V7, which does download a WU before the previous one finishes. (The default of next-unit-percentage=98 can be set to other values depending on your preference.)

- open sourcing - it would probably be a better way to operate/develop on a limited budget or resource scale (like programmers).
More eyes on it can lead to more ideas, fixes, possibly done in less time.

I also realise this is not a good idea because of securing the code from hackers/modders and protecting the WU data collected (to keep it valid)
FAHClient will remain closed source. The plan has always beens for FAHControl to be open source. (It may be already -- I haven't checked.) The interface between the two is open, so if you'd like to write a complete replacement for FAHControl, go ahead.

Also note that there's a forum for 3rd party developers where you can "talk shop".
bruce
 
Posts: 22701
Joined: Thu Nov 29, 2007 10:13 pm
Location: So. Cal.

Re: Work unit auto configuration system?

Postby Jesse_V » Tue Oct 09, 2012 11:56 pm

bruce wrote:The plan has always beens for FAHControl to be open source. (It may be already -- I haven't checked.)

It is. GPL 3.0. https://fah-web.stanford.edu/svn/pub/trunk/control/
Pen tester at Cigital/Synopsys
User avatar
Jesse_V
 
Posts: 2773
Joined: Mon Jul 18, 2011 4:44 am
Location: USA

Re: Work unit auto configuration system?

Postby Xavier Zepherious » Wed Oct 10, 2012 1:02 am

No I run V7 on the 3930k.. I want to run to V7 because I know v6 support will be limited(eventually dead and discontinued)

With the V7 client on... I have been watching my GPU download a new Work unit before the other one finishes

as for doing coding it's one thing Id like to get back to
my coding rig died, And Ive been on a hardware replacement plan - all that's left is my project/server rig(after current build - which has stalled - RMA)

replacing compilers has not a cheap thing to do either (so I have to replace that as well)
I was looking into helping some of the development for Boinc or FAH
so I look into it when everything is settled in

the rig Im only barely gets by(it's dying - just used for browsing now) - I leave the other to do it's work for FAH - the new build..another 3930k (which I have to RMA new parts on -DOA) will be up sometime shortly when I get parts back

thx jesse for the link

yes Bruce I figure the client be closed. I didn't know for sure if the GUI was open or not... now I know

7im don't think Im giving you a hard time Im not. keep pointing out things. healthy criticism is Okay

I like the advice and the ideas tossed about...and yes sometimes I might need a swat on the head once and awhile(ring my bell)
Just don't let censorship or griping , or bias, or protectionism get in the way of a good discussion
Xavier Zepherious
 
Posts: 138
Joined: Fri Jan 21, 2011 8:02 am

Re: Work unit auto configuration system?

Postby 7im » Wed Oct 10, 2012 1:31 am

Not saying it's a bad idea. I'm just not a fan of cracking open a chest, doing open heart surgery, and then applying a simple bandaid that few people would use, to fix <1% of WUs crashing on SMP7.

IMO, net cost out weighs net benefit, but opinions vary...

Keep the outside the box ideas coming...
User avatar
7im
 
Posts: 14648
Joined: Thu Nov 29, 2007 4:30 pm
Location: Arizona


Return to V7.1.52 Windows/Linux

Who is online

Users browsing this forum: No registered users and 1 guest

cron