Debts are only calculated when the tasks are processed and at completion. Aborting tasks has no effect on LTD.

Debts are only calculated when the tasks are processed and at completion. Aborting tasks has no effect on LTD.

Agreed, he's oversimplifying the policies and drawing a faulty conclusion about what the CC behaviour should be.

In any event, I haven't seen one single case where the CC is doing anything wrong. It's the project screwing up from time to time for no apparent reason I can see. Like I said before, I have had two contact sessions mess up since the 14-15th of this month, but have also had a number of them get processed by the backend normally.

Alinator

Update:

LOL...

Well, I got lucky for 782084.

The first three tasks of the bad work assignment turned out to be Dash 9's. Since it pulled them all at the same time, the rest probably are too.

So in this case, blown deadlines are avoided, even if the remaining three run full length.

Of course, you can't count on that happening every time and saving your bacon! :-)

Alinator

lets do some math
you had 20 Seti WU's that you complete in less than 15 minutes on a phenom. so thats 1.25 hours worth of work. divide that into 24 hours. that's approximately 5%(I rounded up the WU time) of your total time for 24 hours. Since you've already aborted most of those WU's this is pointless. however you say you have seti at 4%. I'd say your BOINC is working properly and would have completed the 20 WU's in about 5% of your daily time. Not bad for something works on its own without needing someone watching over it.

I would even bet that your repeated aborting of Seti WU's(I see you've done this for the last 3 weeks) is the reason for it fetching more and more work. BOINC wants or has in the past, to keep the cpu running at the percentage you've requested.

Is this in response to Archae86's post? Because if it is, I'm seeing a couple of AP tasks in the list he posted, that's not 1.25 hours worth of work even on Mark's frozen Nehi machine.

-Dave

I saw 20 Wu's that had a return date of 1 week. These were not AP WU's. We don't know if he's checked his account page to make sure seti doesnt send AP. As far as I can see from his work is that he constantly aborts work which puts seti in a work debt which makes BOINC want to do more Seti to catch up.

I don't know how you are coming up with Archae86 has been 'aborting tasks constantly'. I looked over all his hosts and found 3 or 4 instances of aborting tasks dating back to the 14th of this month, all related in time to cases where the project erroneously sent his host a ton of work (as he related and documented in his posts).

Second, aborting a task has absolutely no effect on the LTD situation for a project. What it does effect is the amount of overall host cache and individual project cache slack on the host. However, it should be intuitively obvious that if the host is currently running at cache equilibrium, the normal course of operation is for the host to make small requests for work (1 to a few hundred seconds or so) for the projects when slack opens up as the current work is processed. IOW, you should never get walloped with multiple task assignments unless the requested numbers of seconds of work is greater than the estimated runtime of the proposed task(s) to be sent.

Alinator

http://setiathome.berkeley.edu/results.php?hostid=4636182 This is the first page of Work that was aborted on his phenom. A phenom that he's gotten to OC at 2.83 Ghz (congrats to you) still no reason to dump work that is being legitimately sent to you.
if you look at his tasks you'll see that he has aborted about 3 pages worth of work on or around the same day he's receives it. As stated before 20 WU's on his PC isn't excessive its the exact amount he's asked for and has gotten. for 3 weeks he's gotten 20 or so WU's and aborted virtually every one of them. This isn't helping him of seti. I've done the math try it yourself.

Debts are only calculated when the tasks are processed and at completion. Aborting tasks has no effect on LTD.

I misunderstood the process. This still doesnt prevent anyone else from looking at his completed work, seeing that he's got nothing but short work, and wonder why he's dumping his 90 minutes worth of work then complaining that his PC is getting large dumps of work. His only problem was having no work to process then getting 20 WU's
We still don't know how large a cache he runs or keeps.

---

In a rich man's house there is no place to spit but his face.
Diogenes Of Sinope

lets do some math
you had 20 Seti WU's that you complete in less than 15 minutes on a phenom. so thats 1.25 hours worth of work. divide that into 24 hours. that's approximately 5%(I rounded up the WU time) of your total time for 24 hours. Since you've already aborted most of those WU's this is pointless. however you say you have seti at 4%. I'd say your BOINC is working properly and would have completed the 20 WU's in about 5% of your daily time. Not bad for something works on its own without needing someone watching over it.

I would even bet that your repeated aborting of Seti WU's(I see you've done this for the last 3 weeks) is the reason for it fetching more and more work. BOINC wants or has in the past, to keep the cpu running at the percentage you've requested.

Is this in response to Archae86's post? Because if it is, I'm seeing a couple of AP tasks in the list he posted, that's not 1.25 hours worth of work even on Mark's frozen Nehi machine.

-Dave

I saw 20 Wu's that had a return date of 1 week. These were not AP WU's. We don't know if he's checked his account page to make sure seti doesnt send AP. As far as I can see from his work is that he constantly aborts work which puts seti in a work debt which makes BOINC want to do more Seti to catch up.

I don't know how you are coming up with Archae86 has been 'aborting tasks constantly'. I looked over all his hosts and found 3 or 4 instances of aborting tasks dating back to the 14th of this month, all related in time to cases where the project erroneously sent his host a ton of work (as he related and documented in his posts).

Second, aborting a task has absolutely no effect on the LTD situation for a project. What it does effect is the amount of overall host cache and individual project cache slack on the host. However, it should be intuitively obvious that if the host is currently running at cache equilibrium, the normal course of operation is for the host to make small requests for work (1 to a few hundred seconds or so) for the projects when slack opens up as the current work is processed. IOW, you should never get walloped with multiple task assignments unless the requested numbers of seconds of work is greater than the estimated runtime of the proposed task(s) to be sent.

Alinator

http://setiathome.berkeley.edu/results.php?hostid=4636182 This is the first page of Work that was aborted on his phenom. A phenom that he's gotten to OC at 2.83 Ghz (congrats to you) still no reason to dump work that is being legitimately sent to you.
if you look at his tasks you'll see that he has aborted about 3 pages worth of work on or around the same day he's receives it. As stated before 20 WU's on his PC isn't excessive its the exact amount he's asked for and has gotten. for 3 weeks he's gotten 20 or so WU's and aborted virtually every one of them. This isn't helping him of seti. I've done the math try it yourself.

Debts are only calculated when the tasks are processed and at completion. Aborting tasks has no effect on LTD.

I misunderstood the process. This still doesnt prevent anyone else from looking at his completed work, seeing that he's got nothing but short work, and wonder why he's dumping his 90 minutes worth of work then complaining that his PC is getting large dumps of work. His only problem was having no work to process then getting 20 WU's
We still don't know how large a cache he runs or keeps.

Maybe because his resource share is probably in the region Einstein 90%:Seti 10%.

His Account Data shows appoox that split by RAC.

http://setiathome.berkeley.edu/results.php?hostid=4636182 This is the first page of Work that was aborted on his phenom. A phenom that he's gotten to OC at 2.83 Ghz (congrats to you) still no reason to dump work that is being legitimately sent to you.
if you look at his tasks you'll see that he has aborted about 3 pages worth of work on or around the same day he's receives it. As stated before 20 WU's on his PC isn't excessive its the exact amount he's asked for and has gotten. for 3 weeks he's gotten 20 or so WU's and aborted virtually every one of them. This isn't helping him of seti. I've done the math try it yourself.

Debts are only calculated when the tasks are processed and at completion. Aborting tasks has no effect on LTD.

I misunderstood the process. This still doesnt prevent anyone else from looking at his completed work, seeing that he's got nothing but short work, and wonder why he's dumping his 90 minutes worth of work then complaining that his PC is getting large dumps of work. His only problem was having no work to process then getting 20 WU's
We still don't know how large a cache he runs or keeps.

With all due respect:

I did look at all of the tasks on all of Archae86's hosts, and stand by my comments.

The only time he has aborted tasks was when the project overloaded his host in spite of it's preferences and the work request made at the time. Even then he only aborted the number of them required to keep his hosts on his resource share target. IOW, he was dumping the excess work because it was going to force his host(s) to make a resource share break for no good reason other than the project messed up somehow.

Also, the quick math you did is irrelevant to this situation. The question is not whether the host is capable of running the work sent by the deadline (it is), but whether the project should have sent that much work to in the first place, given the conditions at the time (it should not have). You continue to breeze over the simple fact that there is no way a request for one second of work should result in 20 tasks being sent (unless the host is capable of running them in less than about 50 milliseconds or so).

Alinator

How about this?

1/22/2009 8:12:53 PM|SETI@home|Sending scheduler request: Requested by user. Requesting 0 seconds of work, reporting 1 completed tasks
1/22/2009 8:13:14 PM|SETI@home|Scheduler request succeeded: got 20 new tasks

If anyone gets a *NEW* occurrence of this problem - and please note I'm only asking about the server sending unwanted work, and not the excessive requests by BOINC v6.6.2 - please could they post clearly in this thread, with timings (e.g. message logs - please state your time-zone) and circumstances.

The developers are trying to check whether a server update has solved the problem.

In case you don't read Tech News:

Matt L made a post which acknowledges the problem which is the subject of this thread, in addition to the (presumably 6.6.2) client problem.

---

I am receiving way too many CUDA wu's. Currently, I have approx. 475 and they are still coming.

Although most seem to be very short should it be generating that many?

Thanks,

-SM

---