How many people are receiving the same workunit and exactly what does the time-limit mean?

I've had two units cancelled now after working on them for like 10 hours: 552067 and 542428. Both units would have finished well within the time limit!

Is the cancellation an error or project policy?

In other words; am I wasting my time here?
____________

I have had one cancelled in the last twenty, but that one was not running. I also note another post on this two days ago that remains unanswered. WUs should not be cancelled pre-emptively if they are running.

I also would be grateful for a response on this, cancellation of models already running is an abuse of donated free time & resources and should not happen. Its a good idea to cancel redundent WUs that have yet to run. I can understand how they can become redundent, and I applaud the existence of such a facility - its win/win all round for all concerned.

However it is not acceptable to cancel those already running without pro rata credit for effort already expended, or at the very least quietly kill them off on upload. There is a high level of Trust involved in crunching what we allow automatically on machines as a free donated resource and free personal time & effort - to be reliable, safe and of value. Pre-emptive action in the way this appears to be implemented, is abuse of that Trust, and is a matter of important Principle.

Regards
Zy

I am *NOT* a member of the project, but, there are all kinds of technical reasons for the project to issue work and then cancel tasks that have not been started.

The standard cancellation tool in the BOINC system will not cancel tasks that you have started to process so that you should get credit.

THe point is, that for what ever the reason is, the project is in fact looking out for all of us by canceling work that is not needed.

BOINC has some automated mechanisms but sometimes they don't have just the perfect control so that we would never see tasks downloaded and not needing running.

In truth, they HAVE canceled streams of tasks before they were issued too ... so ...

If you can't stand it then the alternative is to leave (sadly) because this is the nature of the beast here ... sometimes we get tasks that get "recalled" ... heck, I probably get more of them than just about anyone ... look in my account for computer w2 ...

Paul, the problem here is that he says these canceled WUs had already started and quite some computation time went into them.
For project speed it's still better to cancel them if they become redundant. But it's not fair to the user, so this should not happen, unless credits are payed via trickles or some similar system.

MrS

Unhidden - only have 2 machines here so far :)

The Work unit ID shows that no work is done, but that is not the case!

Although I was not there to actually watch the cancellation, this smallish rig was well underway which both results at the time I left it...

Then, suddenly they were cancelled/redundant. Not the end of the world, but certainly a waste of time, and definitely a problem to smaller machines if this is a general issue...
____________

I don't think this is a general issue, I keep pretty close track of my WUs as I am sure many other people do also. I hestitate to say this but ... is it possible you made a mistake when you looked at the tasks? You did have one error and one complete. Can your card actually crunch two Wus at the same time... the task list will say "In Process" as soon as it gets sent to you, it does not mean the are actively being crunched all at the same time. Currently you have two tasks that say "Im Process" but if you check BOINC Manager I think you will see 1 that is processing and another that is waiting to run.

Steve

@Snow Crash

Like you I like to keep tabs on my units - at least when I start a project. When I'm sure things work I don't care ;)

And there's no chance this could be a mistake. The first one was an error for some reason - probably because I was still setting up the linux box at the time.
The second one got cancelled by the server with 10 hours or more completed. Same thing happened to #3.

Number 4 was actually allowed to finish and upload in time :)

Let's see what happens to #5 and #6 ;)

Anyway, this is really not worth wasting time on as no one from the project seems to bother. I only reported it because cycles were being wasted, and because I was not the first one to have this problem...

Have fun out there :)
____________

@ ETA

Thanks for your in debth breakdown, which made me think :)

A couple of comments/observations:

* The unit with the error actually ran first, as #1 got stuck in the download queue.

* I've been monitoring the box closely today, and Boinc, for some reason, seems to allocate only 0.05 CPU to GPUGRID, meaning that this particular box (running 24/7) in practice runs GPUGRID for only 40% of the time as opposed to the expected 100% :(

With the above in mind, unit #2 (the erroneuos one that ran first) actually would not have stopped running until after about 22.5 hours (as opposed to 9 hours), which is AFTER the two units in question were cancelled. Meaning that neither of the cancelled units would have had time to start!

So, provided the above observations/assumptions are correct for the whole period, nothing was in fact wasted - except your time and mine ;)

Sorry to miss that this box was not running full tilt guys :)

Next step is to find out why, but I won't bother you with that :D
____________

The level of cpu use at 0.05% is a good thing. It indicates a low level of cpu involvement in the gpu application. In gpu crunching the cpu is there to load up the gpu with initial data set (hence the pause when a gpu wu first starts, the data is being loaded by the cpu into the gpu), and also passes "what to do next" instructions to the gpu. The gpu - in crude terms - is inherently stupid compared to the cpu, as it does not have integral instruction sets, its a pure number cruncher, and relies on the cpu to drive it and tell it what to do next.

The lower the cpu number the better, as is it indicates a more efficient gpu app. The latter then frees the cpu to get on with other things, such as more time to crunch a cpu based application - or let you get on with the latest powerpoint presentation, etc etc, with minimal to zero lag/disruption.

Many BOINC gpu projects have much higher cpu assist percentages, the low number is a pat on the back to the gpu app devs, not a figure of concern or worry.

In SETI for example, their CUDA wu (non optimised) runs at 0.15% cpu assist, using an optimised SETI app it will run at 0.04%. The slightly higher figure of 0.05% in GPUGRID is an indicator of the complexity of the model being run compared to SETI's.

Regards
Zy

The lower the cpu number the better, as is it indicates a more efficient gpu app.

Valid point, and does, to a degree, have just that effect. Inevitably there is a "floor" below which the cpu assist number will not go, it will never be zero as the gpu has no inherent Instruction Set "Intelligence". As gpu applications become more refined, they will perform faster, as the gpu app is tweeked to both perform the maths in a more efficient way, and ask for less help from the cpu.

GPU crunching is still in its infancy, there is a lot of "sledgehammer to crack a nut" going on inside the beast, and there is a huge latent power lurking in there yet to be fully tapped. The MW WU explosion was due to a model written especially for the gpu, not just an "adapted" cpu model. Other factors were clearly involved, double precision/single precision yaddie yadda that lead to short term fanboyism re ATI/NVidia cards. In truth in the long term it will even out in performance/card vendor terms as gpu apps become more refined and specially written for a gpu.

The low cpu involvement is why the lower power cpu based machines can still produce cracking results with a gpu app, the gpu is doing all the work. In those cases there are hardware issues such as can the "older" cpu run the card on its motherboard in terms of data throughput (x16 x8 channel PCI etc etc).

Regards
Zy

... as the gpu has no inherent Instruction Set "Intelligence".

I don't agree with you that GPU's are full blown processors they are made to do some tasks but do them as fast a possible, and are not nearly as complex as a CPU.
Maybe in time we will see this change because they can be made some kind of intelligent but for now basically are raw data monsters.
They calculate some instructions and indeed because they are split up in 240 smaller ones do it lightning fast.
Still a CPU will tell it what todo and feeds it with a packet which it can work on and then go back to other work till it gets a signal from the GPU that it did the job.
So in every way the GPU is just a simple co-processor which can calculate fast.

PS Look at the mythbuster example about GPU the cpu is made to let the robot move in a circle and shoot some paint pellets and then move to the middle to make the eyes and mouth, but the gpu simply shoots many colors at once making it look like it did more.
But you can't compare them at all because the cpu have to make very complex moves and extras to come to a result while the gpu cannon just had to shoot all the pellets at once.
So in itself the GPU did more work yes but with very very simple instructions

EDIT: post greatly shortened; I'm not going to argue about this. Read for yourself:

Here's the CUDA SDK documentation: http://www.nvidia.com/object/cuda_develop.html. In particular, you might want to take a look at this document.

Mike

569200 404560 23 Apr 2009 7:23:33 UTC 24 Apr 2009 8:24:51 UTC Over Redundant result Cancelled by server 0.00 --- ---
569139 404534 23 Apr 2009 7:24:14 UTC 24 Apr 2009 18:25:03 UTC Over Redundant result Cancelled by server 0.00 --- ---
554332 397382 20 Apr 2009 18:53:34 UTC 21 Apr 2009 19:21:46 UTC Over Client error Aborted by user 0.00 0.00 ---
549590 395293 19 Apr 2009 20:44:48 UTC 21 Apr 2009 18:50:53 UTC Over Redundant result Cancelled by server 0.00 --- ---
549584 395292 19 Apr 2009 20:44:48 UTC 21 Apr 2009 18:49:42 UTC Over Redundant result Cancelled by server 0.00 --- ---
549466 395240 19 Apr 2009 20:45:23 UTC 20 Apr 2009 17:12:28 UTC Over Redundant result Cancelled by server 0.00 --- ---

A very strange Boinc project. Working Working working without any credit
I give computer time not only for the credits (some I'm used to crunch for don't give much per hour) but this project has really the world record !!! 0 credits per hour
At least is it a usefull project ???

I was happy that my GPU could help boinc projects but I'm going to leave this project without any regret if there's no way for me to get at least one credit...
Is it normal that when you finish your WU not the first(but before max time of course) you get not even one credit ??? Please at least one so that I get more than 0 credit after hours of hard work ;-)
I'm new on this project.
Maybe it's a temporary bug. Any help ?



____________

Note the zero compute time ... you lost nothing.

You started none of this workunits.
You lost no time.

ignasi

If its a KDE based distro try ksysguard its fairly good i use it on Kubuntu.

589184
Redundant while crunched on it for hours ? O.k. I had a good run with the settings a few days, but I´ll switch this host now to folding@home.

Here are my observations regarding the Redundant result issue:

It seems the "IBUCH"-workunits are send out twice and whoever finishes the WU first gets credit and the other participant gets a cancelled by server/Redundant result error and gets no credit, even if that participant reports his/her result minutes later and well before the deadline.

Example: http://www.gpugrid.net/workunit.php?wuid=466213

Note the "initial replication" parameter = 2. All the other WUs have an initial replication of 1.

This is not fair for participants with older cards who will always loose out against the GTX 295's and will never get any credit for these type of WUs. I had several of these cases happen, so now I manually abort these type of WUs when I happen to notice one of them in my queue.

It's ok to send to same WU to several participants, the Seti@HOME project does that by default, but everybody who completes the WU in time should get the credit he/she deserves.

This was cleared up a while back, there was a suspicion that was happening, but in fact it was shown at that time that the WU in question had not started on the machine in question. If it has returned as an issue I suspect they will jump on it, as that is not "as designed".

The server cancel facility is only designed to run on WUs that have not started on a machine. Those that have started, still get the credit if successfully completed. If they get cancelled in mid-crunch then a bug has surfaced, the principle of complete if started was the intent when the facility was first implemented.

Regards
Zy

I've seen this happen; an WU was 90+% complete, but when I check an hour later, somebody else reported results 10 minutes before my WU completed and I got the old "Redundant Result" stuff. I just received another of these WUs, # 475454.

http://www.gpugrid.net/workunit.php?wuid=475454

So for the record: processing has started; I'm at 1%... I made a screenshot, not sure how to upload pictures. The WU was also sent to another participant with an GTX 295 - I'll be creamed for sure. ;-)

Will babysit to see what happens and post a follow up.

Hi there,

I'm experiencing such a suspect behaviour on my own. I have one machine attached to GPUGRID since months and I've recently removed the SETI project because of the sluggishness that it puts on my system. On that matter the GPUGRID is much better in not disturbing the other activities I have on this PC.

So since about 10 days, this PC is dedicated to GPUGRID, and since then I've got more than a half of my WUs cancelled as "redundant results" and no credit. The problem is that this machine runs 24/7 GPUGRID (with a 8800GT which takes about a day to complete most WUs).

As a test on the cancellation of started WUs, I've just suspended the current running WU to force the second one to start and then reverted so that it continues the first one with an earlier deadline. I'll see how these two ones behave after upload and maybe cancellation.

I'll let you know about.

Regards
____________

I've seen this happen; an WU was 90+% complete, but when I check an hour later, somebody else reported results 10 minutes before my WU completed and I got the old "Redundant Result" stuff. I just received another of these WUs, # 475454.

http://www.gpugrid.net/workunit.php?wuid=475454

So for the record: processing has started; I'm at 1%... I made a screenshot, not sure how to upload pictures. The WU was also sent to another participant with an GTX 295 - I'll be creamed for sure. ;-)

Will babysit to see what happens and post a follow up.

Hi there again,

my problem is related to the task 25-KASHIF_HIVPR_n1_for_ba3-9-100-RND6818 (http://www.gpugrid.net/workunit.php?wuid=467482) that was blocking at 24.820% and avoiding the other tasks to start. I've cancelled it and I'll keep an eye on the next days.


____________

Hi,

I confirm that my problem was related to the blocked WU, everything ok since its cancellation.


____________