This is going to be difficult to express without it being mis-read, the aim behind it is overall "job satisfaction" for those with slower cards, no more, no less. In reading it, place yourself in the situation of the lower speed rated cards.

At present the server will reach out and cancell WUs already crunched by another, and no longer needed on that PC - a good thing, no problems with that, its a win-win scenario. It does have a consequential drawback, which whilst not strong enough to negate the principle, does have sufficient weight to merit consideration of a resolution.

To quote an extreme, if a 8500/8600 etc etc is sent a WU, and is matched with a 285/295 at the same time - no contest, the 285/295 will finish first everytime. If the slower card is not running the WU, it will be cancelled, and thats fine. If its running it, it will be allowed to complete and be given credit, thats also a good thing. In that latter case however, in the extreme example, it means that the slower card never contributes in a meaningful way, as their crunched WU is never needed.

Of course in real world terms such a scenario is nigh on impossible on every single occasion. However also in real world terms it does happen on a significant number of occasions. I run a 9800GTX+ and after a recent cancellation had a look at completed WUs to see how many were "beaten to the punch", there are quite a few, around 20% or so. That number will significantly increase the slower the card,

That will over time become discouraging for those with slower cards, as it dawns on them that much of what they crunch is of no value (and here keep an even keel, I am taking in terms of running against faster cards and being beaten to the finish post, no other inference implied).

That there is a valueable and essential place for the slower cards there is no doubt whatsoever, clearly, so lets not go there ...... The recall system does produce the anomaly however, and it would not surprise me to find many withdrawals from the Project - overwhelming number of which just "disappear" no reason or song and dance about it - because they feel there is no point as they get "beaten to the finish" by someone else. The latter can be very discouraging if on a slower card, is happening a lot, and will be increasingly common with cards below a 9800GTX.

Is it possible server-side to test for the card used by the two selected crunchers to try and ensure comparable cards? It should be easy to do, I dont think it would involve too much extra cycles, and would create a level playing field with happier crunchers.

This is not a race, nor should it ever develope into one, most have the common sense to realise that. By issuing to comparable cards however, it means the slower card can contribute in a more meaningful way, with more overall chance of retaining them, and the additional computing power.

The world will not come to a halt, if this is not adopted, but it will be a happier place for those with lower spec cards if it is.

Regards
Zy

That will over time become discouraging for those with slower cards, as it dawns on them that much of what they crunch is of no value (and here keep an even keel, I am taking in terms of running against faster cards and being beaten to the finish post, no other inference implied).

This is not a race, nor should it ever develope into one, most have the common sense to realise that.

The world will not come to a halt, if this is not adopted, but it will be a happier place for those with lower spec cards if it is.

I fear that is the most attracting reason for the top participants

Don´t watch statistics if you get discouraged.

Guilty as charged on the card designations :) It was a quick remark as illustration I should have checked facts a little closer.

The dilema is well understood, life is not perfect, never will be and we all go with the flow on the best path available when all is factored in. I understand the drive at Project level to produce a schedular solution that is the most efficient in producing the best return of WUs - it is after all why we are all here.

I would only restate the effect of going down a path of "pure" efficiency, the latter can often be fools gold as the penalties suffered outweigh the solution enabled. In this case, I have no idea of the actual hard facts as clearly I dont have the whole project stats. The scenario I painted is plausible and I have seen similar effects elsewhere, where a drive for efficiency implemented in good faith, ends up driving away those "excluded" albeit unintentionally.

Competition is getting fierce for Crunchers in the BOINC world, and anything that helps tweek reasons to stay on this Project can only be a good thing. As stated above todays low end card user, is potentially tomorrows mega cruncher when they get hooked by it all. There is a balance in all this which is always difficult to get right all the time.

It would be an idea to "Test & Measure" numbers of lower end cards over time, and see if a trend of increasing non-activity develops, shouldnt be too hard to frame a daily stats report and log it to map the trend. Meanwhile if the schedular can be tweeked to minimise as much as is practically possible within the Projects Objectives, unbalanced card pairing, that can only be a good thing.

Regards
Zy

That made me think rofl :)

As a starter for ten, building on your idea in the post above, how about:

Three Categories with suggested sub catagories in following priority order to allocate WUs:
1. Fast & Reliable. One Replication, match fast cards only,
then allocate in the pri order:
A. Time Critical & Content Critical Project Work
B. Time Critical & Content Critical special one off or short duration

If Units & suitable hosts remaining

2. Fast or Slow, & Reliable. Two Replications, match card speed first, any
speed second, then allocate in the pri order:
A. Balance of Category 1 Units remaining
B. Critical Content Standard Project Work
C. Critical Content special one off or short duration

If Suitable hosts remaining

3. Fast or Slow, Reliable or Unreliable. Three Replications (do not pass remaining Cat2's to this)
A. Routine non time critical, non content critical
(1) Match card speed
(2) Any Card speed

If Units remaining - wait for capacity, rinse and repeat.

Within that framework, define the Definition of each type of WU in a flat table/array with Column IDs:
Time Critical
Standard Project Work
Special One off
Short Duration
Routine
Non Time Critical

From the Flat Table/array allocate the types of WU to the overall categories above, depending on the Project Priorities - I would see that as an "Option" in an application accessible for Project Admin to set/tweek criteria for the next run of units.

That way the only "maintenance" to the code - as such - is generating an allocation of WU to Definition in the overall Definition table, thats just a straight input session of a few seconds during each Project Definition and scoping to enter the next row in the array - the rest should flow.

Bit flakey, I'm no programmer - rofl - but I reckon it points in the right direction indicating the right priorities for the Project but balancing in needs of Cruncher Speeds.

Anyone else out there with an idea how to balance Project Objectives as primary with maximising slower card useage satisfation - lets hear from you:)

Regards
Zy

As an owner of what I consider one of the slower cards ... though many would not consider it so ...

I would suggest that the distribution of longer vs. shorter tasks may be less balanced than it could be. Again, there are various ways of eating this elephant but it would bother me little at all to be given fewer sub 6 hour tasks on the machines with GTX200 class GPUs. Or to put it another way, I get a lot of tasks that MIGHT be more suitable for slower systems than the KASHIF tasks now flowing through the system.

WIthout gaming the questions and that would require more information as to the classes of machines it is hard to know if changes would make significant differences, or not.

I would argue that it would.

Put it another way, if my i7 got more of the KASHIF tasks while the slower systems got more of the other tasks our return intervals would converge ... but this requires knowing the number of systems of the various classes and the population of the tasks to be processed. And their priority. If the slower tasks are higher "priority" than the slower this makes changes significantly.

Other limitations apply. The "Feeder" application that feeds tasks to the scheduler has a very limited size. My recollector says its default size is 100 tasks. And the usual configuration is FIFO so that the task assignment is "random". You can put more smarts in the scheduler so that it selects more appropriate tasks ... or change the system so that there are multiple schedulers with multiple queues and we sign-up for the one with a best match ...

Hoar to know what the best choices are here ... Maybe I need to go buy another faster card ...

Its a little difficult to know which direction to go from here. I reckon a fair summary of all the above to date is:

- Overall speed of production from the overall crunching capacity of the community is the top priority, as long as that is not at the expense of overall capacity (ie yup need to crunch em quickly, but little point achieving that if we loose a chunk out the back door because they feel "unwanted"). Hard balance to achieve, but the overall goal is there.

- BOINC schedular does give some issues in that we are essentially "interveening" between it and the GPUGRID server. Not impossible to resolve if the server responded to the BOINC schedular request with internal logic to select the WU, and pass it back to the schedular for "delivery". Suspect there is some heresy there rofl, but hey, I'm no programmer :)

- No strong yells of "over my dead body", so we could be reasonably close to a done deal given some collective brain storming on detail and some pragmatic decisions on what will be an imperfect solution - lets go for the classic 80/20 rule, get it in, and massage as time goes on. Perfection first time round is not going to happen, thats not the real world.

If this is gaining thought, maybe the next step is someone better than me at "sudo code" to attempt a better rendition of my first crack at it above, and post it for collective comment?? Usually a proper sudo-code exercise can tease out good suggestions as it is readable by us mere mortels.

Regards
Zy

NOt knowing the internal goals or the sub-task goals it is hard to know for sure...

BUt, I can easily see that there is going to be a dynamic tension between the Speed of Service (SoS) and the processing time ... what I mean is this. Assume that there are three task length classes and three SoS objectives.

Short Run Time
Med. Run Time
Long Run Time

SoS: 1 Day or less, 2-3 Days, and Deadline fine

So, in my case I have a spread of cards from GTX280 to 9800GT ... run times average 5 to 20 hours on the faster card and on my slow card it is 15 to 33 hours or there about.

Assuming, for the moment, that we can roughly class the tasks I looked at the credit claim numbers and at the moment have 3 sets 3681/3946, 7057/8076, and 4131/4352. And looking at a couple dozen of these tasks gave me the run times for these tasks.

Now if we contrast those run times with the SoS, we may find that the shortest running tasks may have a higher desired SoS, where the longer running tasks may be in the "Deadline Fine" class.

I mean the question is are we trying to average the run times so that my 9800GT card would get the "shorter" tasks which it completes in about 15 hours, while the GT280 gets the longer tasks (about 16.5 hours)? If that is the case, then the objective would be to attempt to fit them by estimated run time class.

But, the SoS objective may not be that neat and pretty. if the SoS is for 1 day or less, then you would want to assign that short run time task to the faster machine regardless.


As to the Scheduler and the project, um, there is no intervervention between it and the GPU Grid server. They are one and the same. The BOIC CLient tells the project's scheduler that it wants work and it issues work out of the available pool.

Sadly, this is one of the places that is some pretty bad code and one of the hardest to get changed. The first issue is that the feeder has a limited collection of tasks and if there is not a good choice in that selection there are two options, issue no work, or issue work that falls out of these new guidelines.

Not trying to be nay-sayer here... but, the first question is "Is there a real problem?" or are we a solution looking for a problem?

I better quit, not typing well, and not thinking much better ...

Without knowing how it is implemented from the server perspective ... if we take a look at how WCG has multiple projects, perhaps that basic concept could be reworked for different classes of WUs (priority, 200 series card only, tight turnarounds (for compute error WUs), regular, best suited to low end cards ... you get the idea.) Let's say I have a 295, I am *asked* to sign up for specific WU types on the website (yes, this still leaves me in control so no big brother concerns) ... basic information could be provided explaining what each *WU type* is best suited for ... only if buffer < 24 hours etc. Now for coordinating this through the scheduler ... maybe just an extra <tag> on each WU to see if there is a match to the incoming client request (what the client registered for on the website). I could also select "give me anything the project needs me to do" type of WU so that if all the short turn around or tasks only suited to 200 series cards have been sent out then by all means send me a lower priority WU. This would reduce the necessarily inefficient process by which WUs are allowed to complete even thought the project already has a valid return while also reducing the implied perception of my GPU is less useful than yours so I'm gonna take my ball and go someplace else :-). Wow ... in fact if I am concerned about having my WU returned quickly (so someone else's copy does not even start processing yet) I would turn my buffer way down low which I believe the project would really appreciate.
____________
Thanks - Steve

You been doing that subliminal stuff again :)

I dont have the competance re the internal workings of the WU to give a validity opinion on the overall principle you gave - seems sensible to me, I can see the benefit if the basic underlying predication re splitting by time steps is fundamentally practical.

Whether its all predicated by GPU Class or Time Step, at some stage, as you pointed out, we inevitably get to the point of matching Users, which is where the fast-slow issues come in. I can see that time step is the much better of the two (GPU Class / Time Step) scenarios - given my caviat above - and has benefits beyond mere card matching.

Having got to the stage of deciding which principle to follow - GPU Class or Time Steps - indeed any other principle that may come along), the ultimate gottcha will always raise its head re matching fast-slow. Albeit Time Steps look much better in that regard. The next bit may sound a little "sledgehammer to crack a nut" - and decidedly non-tech ......

Which ever principle is chosen, only show the Cruncher their WU result, not everyone's, in the WU result page. What we dont know wont hurt us.

The Project will have gone through hoops and loops to be as fair and as accomodating as it can possibly be to the slower class card encouraging their participation. Its no biggie not to show the matched result. That way the Cruncher will not know how many times their result was dumped. Since the Project will have done its best to avoid cards being "useless" because they were not used in the final outturns, such an arrangement could be used with a clear guilt free mindset.

I recognise there are benefits in seeing all participants on screen for a WU, however for the Cruncher, at the end of the day its pure asthetics, doesnt contribute one way or another to successful or otherwise WU crunching. Such a screen - or similar - may be needed by admins et al, but thats no issue.

The Results Of The Zargon Jury?

Flowers :)

Regards
Zy

My mind is slipping over the surface. But, I think the solution is simpler than you imagine ...

The application does time steps, we know the amount of elapsed time. If we allow the user the discression, as at Rosetta, they can set a time limit on how long they want to run individual tasks. The task is downloaded... it is run until it has completed the number of iterations that will fill up the amount of time the participant selected. The task is ended at whatever arbitrary time-step the task is on when the clock expires.

Task is returned and the next task is issued based on the amount of work done in unit time. The point here is that I can say run for 6 hours and at the end of that time I get a new task. Let us say that I completed 100 TS, well, the 9800GT in that same 6 hours would have only completed 30-32 TS ...

Obviously this complicates the work generator, credit awarding, etc.

It allows participants greater control over the work size, for those of us that do not like tasks that take more than about 6 hours would probably be happier...

this is the point where I started thinking :)
There's one important problem with this approach: WUs issued to several cards.

Let's assume a slow card returns 10 steps after 4h, whereas a fast card might return 100 steps after 6h. How long are you going to wait? You could estimate the runtime from the users preference, but that's not very direct. I'm trying to make things easier to predict and more regular. Not sure how neccessary it is, but I really wouldn't want slow cards to "outrun" fast ones just because they set a shorter runtime (and the server decided to use their result for the next WU instead of waiting for the other one).

MrS

Um, I knew I was not clear ...

I ws thinking of GPU Grid following more in the line of MW where we have single issues and single returns. When you get into HR then you have to have identical returns or you cannot compare.

So, I was thinking more in line with:

..|..|..|..|..|..|..|..|..|..|..|..|..|..|..|..|..|..|..|..|..|..|..|..|

Where we have 3 hour "frames" if you will ...

THe next frame is built on the return from the prior frame.

Here, we start with the 9800 and get 30 TS, next a 260 returns 100 to TS130, a 8800 returns 10 to 140 ... and so on ... so, each client runs as best they can, and we accumulate the results on a more regular schedule, but the actual work accomplished becomes highly variable.

The problem is that I do not know how much that biases the science and how it is being used. If they are looking at snapshots at certain specific TS then the returns are streamed and re-sliced for the science to be done.

The advantage to a "flow" system such as this is that the totality of the schedule to hit certain points would become more predictable on average (I would expect) because of the random assignment of tasks would mean that slower cards would cause "bumps" in the timeing, but overall the odds say that the next machine is just as likely to be faster than the one currently running the task ...

The only reason that I like shorter tasks is that my risk of loss goes down. I know credit does not matter, but the science does. If I am doing one hour tasks, I do put 6 times the load on the server to get tasks, but the output files are 1/6 the size and my risk of losing 5 hours science goes way down.

Again, I am unusual in that I have MOSTLY higher end cards so my run times are about 6 hours per ... with the single exception with the 9800GT where the run time is 12-20 hours per more to the higher end ...

Again, the Rosetta model comes to mind ... it lets ME chose how much time I want to spend on each task. How much risk *I* want to take with a task failure costing me and the project time and effort.

I don't know if this is any clearer than what I said before ... and I am not sure we are converging on a concept yet ... sadly too much excitement with dying tasks causes me to wig out ... and I cannot concentrate well ...

for me you've been clear enough. If you go for a stream with one host per WU your system is fine and appreciably simpler than what I wrote down. However, what are you going to do if you send a WU to a host whih has been notoriously unreliable? Are you going to wait for the error or do you want to send it out to a second host immediately? Could you provide this capability and come up with something simpler than me? I don't think it would be beneficial for the project to give up the ability to issue WUs multiple times.

Which is why I was asking back in the beginning... are we a solution in search of a problem? Only the project types can tell us that.

Which is why I was asking back in the beginning... are we a solution in search of a problem? Only the project types can tell us that.

Agreed...to a point. I think that many of the posters in the thread have been around BOINC for several years, so we have some fairly good ideas about what those problems are...especially you Paul. On that side of things, we are able to offer real solutions. But you are very much right that without more detailed understanding of the construction of workunits at this project, we can at best offer potential solutions that, if we are lucky, might hit upon a real solution...

Though I must admit I would really like to see shorter tasks so that a 9800GT can get them done in less than a full day ...

Perhaps the best solution could be setting up 2 projects under 1 roof (ie. seti multi-beam and astropulse) and have one for slow gpus, one for fast. Default settings would have the slow GPU selected and users could select fast GPU for more credits and longer tasks.

Perhaps the best solution could be setting up 2 projects under 1 roof (ie. seti multi-beam and astropulse) and have one for slow gpus, one for fast. Default settings would have the slow GPU selected and users could select fast GPU for more credits and longer tasks.

A more efficient approach would be to follow the PrimeGrid model where shorter and longer types of work can be selected within the same project...However, GDF has said elsewhere in the forum (sorry can't find the link just now) that it is not possible to divide up the work this way.

We would need to be careful re credits, they need to be awarded on the "standard" BOINC formulae basis as being an equal number of credits per Flop, whatever X multiple is used in the BOINC formulae

That's exactly what I was referring to... different sub-projects.

How can it not be separated like that?
There are several different types of work going on right now so why could it not be set so that (for example) 79-KASHIF_HIVPR is run on slower cards with longer deadlines and p780000-RAUL on the faster cards with shorter deadlines.

As an added bonus this could help with issues such as the current problems with G90 GPU's...

The main problem which I see here is that it would split up the pool of WUs. If too many WUs are generated for one of the runtimes these will be lagging behind, whereas other runtimes may even run dry. If this idea was adapted it would require changes in the server software to dynamically adjust the runtime / number of steps within one "set of simulations", when ever new WUs are created. Otherwise load balancing would suck.

MrS

Regarding load balancing, there is already an option for the user to check to accept other types of work if the preferred work is not available. Make this an always on option (or perhaps switched on automatically for reliable hosts), and that might solve the load balance issue.

I’m sure there are thousands of people that have added this project in Boinc and just gave up after repeatedly getting no credit for work units.
Is there some sensible reason, I am not aware of, to turn people away from the project?

Tasks canceled are those that have not been started. So, no work is lost. If you start it, you can still get full credit for your work. But, if someone else has a task and they do not need the one you have, but have not yet started, it can be canceled.

The available projects that use the Nvida GPU now include:

SaH, SaH Beta, The Lattice Project, Ramsey, Aqua, and soon we hope MilkyWay...

I know that SaH, SaH Beta, Ramsey and Aqua are issuing GPU work at this time ...

Can you post a link to/identify which ones had that happen?

Regards
Zy

The task you've linked wasn't cancelled by the server but it had a computation error...

<message>
Incorrect function. (0x1) - exit code 1 (0x1)
</message>

So I think that if a user has crunched a WU and it is still within the time I should get credit for it. Look at this wu. I had crunched it for 64,753.00 secs but got nothing as the server canceled it.

http://www.gpugrid.net/result.php?resultid=564654
____________

Proud Founder and member of



Have a look at my WebCam

This one got not cancelled because of a redundant result but because of something else. You can see minimum quorum =1 and initial replication=1. Maybe it got cancelled because it was part of a bad batch of tasks...

So it was better to cancel it server-side than to let it run even longer and let it error out (which would also give you 0 credits)...
____________

pixelicious.at - my little photoblog

Are you sure it is not a hardware issue ? I get these "Incorrect function. (0x1) - exit code 1 (0x1)" quite often, but only on GPU3. I have now completely underclocked this unit.
____________
Join team Bletchley Park, the innovators.

Why have two cards compete against each other? Wouldn't it be possible to do one of the following:

1. Eliminate the competition altogether and have all cards work on separate work units.

2. Employ a SETI@Home resolution where they send out the same work unit to three crunchers and require a minimum of 2 comparable results to reach a 'quorum' and view the work unit as satisfactorily completed and granting credit to all who submitted the verified work unit based on the lowest credit granted. In other words, this would penalize those with faster cards because they get less credit than would otherwise be granted.

Two things to consider:

First and foremost, I don't care about competition or seeing how many work unit I can complete in a given day or how many work units other users accumulate against me. I care about doing worthwhile research. If my work units are getting canceled because there are others out there beating me to the punch, then I view it as not necessary and I will go donate my GPU to SETI@Home, they are always in need of crunchers. Granted, I prefer doing medical research because that may actually pay off versus listening to a signal.

Second, if my work units are canceled as redundant, then wrapping back to the first reason, it is a waste for me to donate my computers time in terms of electricity. It is a cost to me to keep my computer running full time, even while I am not using it.

Maybe its not my place to say this, but you should really get your system for sending work units out to people in line. Worry less about competition and more on just getting as many verified work units done. Competition is a waste...

Thanks for the info.
I like the look of Aqua, and I have signed up to that project. I dont find the others too apealing - maths for the sake of maths is not my thing! Perhaps I will opt into the Milkyway project when they get their act together.

Nvidia-GPU on Linux works only with the GPUGRID-project .

I newly tried the D-Wave's Adiabatic QUantum Algorithms - CUDA Enabled for Linux on 64 platform without any success. However they, today, have released the 3.23 version and I look forward to add AQUA to the short list of CUDA enabled project for Linux.

Others are still only enabled for Windows/x86. Ramsey-GPU is NOT listed as enabled on the official Ramsey app. list.