It seems to me that I am seeing more and more AP units being aborted by new users because of the time involved in crunching these units on their slower rigs. My feeling is that a lot of this is occuring because of the default setting that automatically allows AP units to be downloaded when a new S@H account is started unless the user is tech savy enough and changes the preferences accordingly. I personally know that if I had an AP download onto my 1.8 Celeron that would take hundreds of hours to crunch the first thing I would do would be kill the WU.

Are we not wasting our time and resources by having to constantly resend these units that have been aborted or that have simply just timed out? Some of these WU's are going out 4,5,and 6 times in order to get a quarum and be credited to the crunchers account. Are we not also taxing the system unnessarily by having these WU's downloaded time after time.

My question to the developers is...why can't the AP field be left disabled by default and leave it up to the user to turn it on if they want to do AP WU's? I am sure that this would reduce some of the unneeded aborting of these WU's.

Just my thoughts on the problem...any other ideas on the subject?

Cheers

---

http://www.novascotia.com

It seems to me that I am seeing more and more AP units being aborted by new users because of the time involved in crunching these units on their slower rigs. My feeling is that a lot of this is occuring because of the default setting that automatically allows AP units to be downloaded when a new S@H account is started unless the user is tech savy enough and changes the preferences accordingly. I personally know that if I had an AP download onto my 1.8 Celeron that would take hundreds of hours to crunch the first thing I would do would be kill the WU.

Are we not wasting our time and resources by having to constantly resend these units that have been aborted or that have simply just timed out? Some of these WU's are going out 4,5,and 6 times in order to get a quarum and be credited to the crunchers account. Are we not also taxing the system unnessarily by having these WU's downloaded time after time.

My question to the developers is...why can't the AP field be left disabled by default and leave it up to the user to turn it on if they want to do AP WU's? I am sure that this would reduce some of the unneeded aborting of these WU's.

Just my thoughts on the problem...any other ideas on the subject?

Cheers

Hi Zebra3,

I have a conflict of interests on this topic. For one, I believe having the Astropulse button automatically enabled by default (as you mentioned) wastes resources, time, bandwidth (for SETI@home and the average user), not forgetting to mention the fact when you, the other cruncher, have to wait for another user to complete it and even then, your battle could still not be over. So this opinion of me feels the Astropulse button should be disabled by default, and only knowing users should crunch them.

But on the other side of me, I feel, when you sign up to SETI@home you knowingly have an (some people may say "minimal" here) obligation to complete the tasks that you are sent. And not just play fussy kid and abort the workunit's that you don't like or want to deal with. Plus, if the Astropulse button was disabled by default, you would see minimal, little, if any Astropulse workunits being crunched and successfully completed by users, which could result in possibly less development of optimized applications, less implementation of the optimized executables, in turn causing longer crunch times for those that would and do crunch Astropulse.

For example, this morning, when I went to fetch work for SETI@home. Along side with the usual tens of Multibeams, I was lucky enough (I barely ever get them) to catch 6 Astropulse workunits. I go to find my first Astropulse workunit, this one, and I see my wingman with computer #4210066, Berry Jansen, has aborted every single Astropulse workunit he received. I sent him a PM saying either crunch them or turn the tap off (out of the slim chance he might look and read it!). Like it will do much good. For my 5th task, I see I am actually the third cruncher, since the first guy did not reply (*smirk*). And the second person is using 6.5.0 BOINC, so we will see what happens there. Luckily my 4 other wingmen for the other Astropulse appear normal and not whacked out! Luck of the draw...

- Luke.

---

- Luke.

Like Luke, I think the AP option has to be, by default, On. Or the set and forget, which are very much in the majority, would never go them.

(I think Ned has figures to show that less than 5,000 people post on these boards in a year.)

Also looking at some hosts I think some of the aborts might have occurred because they are CUDA enabled and they might have acted on Eric's CUDA FAQ.

I've recently gone to optimised AP only, on one computer, and only found about four people that I could reasonably say were aborting all AP work, I sent these a friendly e-mail.

Are there really that many people manually aborting AP workunits? What a severe waste of time and focus!

Somehow I doubt that this problem is anywhere near massive to consider worry about.

---

Like Luke, I think the AP option has to be, by default, On. Or the set and forget, which are very much in the majority, would never go them.

(I think Ned has figures to show that less than 5,000 people post on these boards in a year.)

Here is the information I have indirectly from Eric:

I don't think we have a way to tell how many readers there are on the forums, but we've got 24914 users who have posted at least once to the forums. 12877 who have posted at least twice. And 8554 who have posted at least 3 times.

Of those, 101 have posted in the last day. 708 have posted in the
last month, and 4224 have posted in the last year. Even if readers
outnumber posters by a factor of 10, the forums are only read by
40,000 people.

It's from a few months past, but it gives some idea of how many "fanatics" there are, and how the vast majority is likely "Set and Forget."

---

Like Luke, I think the AP option has to be, by default, On. Or the set and forget, which are very much in the majority, would never go them.

(I think Ned has figures to show that less than 5,000 people post on these boards in a year.)

Here is the information I have indirectly from Eric:

I don't think we have a way to tell how many readers there are on the forums, but we've got 24914 users who have posted at least once to the forums. 12877 who have posted at least twice. And 8554 who have posted at least 3 times.

Of those, 101 have posted in the last day. 708 have posted in the
last month, and 4224 have posted in the last year. Even if readers
outnumber posters by a factor of 10, the forums are only read by
40,000 people.

It's from a few months past, but it gives some idea of how many "fanatics" there are, and how the vast majority is likely "Set and Forget."

Shows my memory isn't so bad after all. There's hope for old codgers like me after all.

Like Luke, I think the AP option has to be, by default, On. Or the set and forget, which are very much in the majority, would never go them.

(I think Ned has figures to show that less than 5,000 people post on these boards in a year.)

Also looking at some hosts I think some of the aborts might have occurred because they are CUDA enabled and they might have acted on Eric's CUDA FAQ.

I've recently gone to optimised AP only, on one computer, and only found about four people that I could reasonably say were aborting all AP work, I sent these a friendly e-mail.

So is Eric effectively saying that he believes that the ratio of crunchers to readers is very small so that by making the AP button off by default would be conterproductive to the project?

Also on Ozz's comment that he doubts that this is a massive problem ...is there any report than can be brought up reguarding "user initiated AP aborts" that can confirm or deny that this is may be adding to the problem?

---

http://www.novascotia.com

[trying to stay in the "posted in the last month" category :)]

Another way of looking at it is those who are aborting AP units may not be reading the forums, let alone posting, but they _are_ monitoring their rigs enough to notice long crunching times. This is not quite set & forget (perhaps that should be seti & forgeti)!

Is there some way to make it easy for a user who is checking their SETI tasks to turn off receiving AP or just long WUs? A friendly button on the side of the tasks view maybe?

Could the abort confirmation message be customised to suggest changing preferences when aborting an AP WU? I don't know if BM or the SETI app is controlling this - probably BM so not possible/easy.

i think that many people, including my self, are aborting a lot of AP because of BOINC 6.6.2

I had 6.6.2 for one day and got 225 AP workunits !

So i aborted more than 100 so not to waste Your or the projects time ?

Mike

@Odan

Is there some way to make it easy for a user who is checking their SETI tasks to turn off receiving AP or just long WUs? A friendly button on the side of the tasks view maybe?

Go to your account > click "SETI@home Preferences" > Click "Edit Preferences" > Find the section called "Run only selected applications" > and untick the "Astropulse" box.

- Luke.

@Bukken

i think that many people, including my self, are aborting a lot of AP because of BOINC 6.6.2

I had 6.6.2 for one day and got 225 AP workunits !

So i aborted more than 100 so not to waste Your or the projects time ?

Mike

Did you have Astropulse disabled in your preferences?

- Luke.

---

- Luke.

No why ?
I like doing astropulse, but 225 wu´s on top of what i allready had, is way too much !
Cache set to 4 days.. Doing about two a day ??
They have to be returned in 30 days, so even the fastest computer in here would have trouble ?
Make the math, more than 240 AP in all, within 30 days..
Anyone ??

No why ?
I like doing astropulse, but 225 wu´s on top of what i allready had, is way too much !
Cache set to 4 days.. Doing about two a day ??

Still using Raistmer's 6.06 Build?, wouldn't it be better to upgrade to later build or stock 6.08?, and get AP r103, that's a lot faster too.

Claggy

So is Eric effectively saying that he believes that the ratio of crunchers to readers is very small so that by making the AP button off by default would be conterproductive to the project?

Also on Ozz's comment that he doubts that this is a massive problem ...is there any report than can be brought up reguarding "user initiated AP aborts" that can confirm or deny that this is may be adding to the problem?

I would not presume to put words in Eric's mouth.

It is a very long jump from "This is the observation" to "Making the AP button off by default would be counterproductive."

I would interpret Ozz as saying "if most crunchers are on autopilot, then it's unlikely that the owners are aborting work on unmonitored clients."

I would agree that defaulting Astropulse to "off" means less AP gets done because with 800,000 crunchers and maybe 40,000 readers, most would never know AP was here.

---

Am doing AP r103 !

Not the point !!!!!

Too much work sent out, no possible way of finishing in due time !

And claggy, it´s AP wu´s 225 on top of 15 i allready had ;-)

Next to that 1200 MB wu´s

Am doing AP r103 !

Not the point !!!!!

Too much work sent out, no possible way of finishing in due time !

And claggy, it´s AP wu´s 225 on top of 15 i allready had ;-)

Next to that 1200 MB wu´s

LOL...

No Problemo. We knew you were talking about having to abort the excess from the bad work assignment, and not just summarily aborting AP because you don't 'like the look of them'. ;-)

FYI, excessive assignments from the project have been observed lately for other CC versions than 6.6.2 as well. That was most likely the reason for the other questions which were asked.

So it's probably a good idea to keep your eye on it for now, even after rolling back from 6.6.2.

Alinator

Am doing AP r103 !

Not the point !!!!!

Too much work sent out, no possible way of finishing in due time !

And claggy, it´s AP wu´s 225 on top of 15 i allready had ;-)

Next to that 1200 MB wu´s

Probably something to do with each Cuda WU that get's aborted/autokilled because it's a VLAR and so only takes 0secs, and there are hundreds of those,
that will likely drive down RDCF, giving you more work, so what is your RDCF now?

Anyway the last two AP you reported today and yesterday both were reported as being rev 69, so unless you've upgraded in the last day or so, you are still running rev 69.

resultid=1125481864

resultid=1125482365

Claggy

No why ?
I like doing astropulse, but 225 wu´s on top of what i allready had, is way too much !
Cache set to 4 days.. Doing about two a day ??
They have to be returned in 30 days, so even the fastest computer in here would have trouble ?
Make the math, more than 240 AP in all, within 30 days..
Anyone ??

I'll take 'em :) With BM 6.6.0 all MB's are pointed at the GPU so my cores are doing only AP using r103. At the current rate, that should be about 435 AP's in 30 days.

F.

---

Yeah updated yesterday to AP r103.
So all those wu´s are also before autokill in the new raistmer pack.
But i´ll keep an eye out for missbehaving, so i don´t have to kill anymore AP Wu´s.
My Post was more a heads up, to those with 2-300 AP Wu´s and no way to crunch them in due time..

Keep crunching

@ Fred Woohoo crunching train is SPEEDING.. Congrats ;-)

You can probably get through 70 to 100 AP WU's in the month before they are due with AP r103 now, depending on each AP length, and there are quite a few short one's around.

Claggy

I know, thats why i aborted the 100+ wu´s so someone else could have a shot.
Me keeping them, they would all end up with "No result"
and be sent out to someone new. 30 days later... waste of time ;-)