Got *much* more work than asked for


log in

Advanced search

Message boards : Number crunching : Got *much* more work than asked for

Previous · 1 · 2 · 3 · 4 · 5
Author Message
WinterKnight
Volunteer tester
Send message
Joined: 18 May 99
Posts: 8630
Credit: 23,718,254
RAC: 19,011
United Kingdom
Message 857199 - Posted: 24 Jan 2009, 15:51:55 UTC

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

Alinator
Volunteer tester
Send message
Joined: 19 Apr 05
Posts: 4178
Credit: 4,647,982
RAC: 0
United States
Message 857203 - Posted: 24 Jan 2009, 15:58:53 UTC - in response to Message 857199.

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

Alinator
Volunteer tester
Send message
Joined: 19 Apr 05
Posts: 4178
Credit: 4,647,982
RAC: 0
United States
Message 857892 - Posted: 26 Jan 2009, 1:44:59 UTC - in response to Message 857048.

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

Profile ignorance is no excuse
Avatar
Send message
Joined: 4 Oct 00
Posts: 9529
Credit: 44,433,274
RAC: 0
Korea, North
Message 857941 - Posted: 26 Jan 2009, 4:14:55 UTC - in response to Message 857194.

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

End terrorism by building a school

WinterKnight
Volunteer tester
Send message
Joined: 18 May 99
Posts: 8630
Credit: 23,718,254
RAC: 19,011
United Kingdom
Message 857946 - Posted: 26 Jan 2009, 4:23:11 UTC - in response to Message 857941.
Last modified: 26 Jan 2009, 4:23:35 UTC

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.

Alinator
Volunteer tester
Send message
Joined: 19 Apr 05
Posts: 4178
Credit: 4,647,982
RAC: 0
United States
Message 857966 - Posted: 26 Jan 2009, 5:08:15 UTC - in response to Message 857941.
Last modified: 26 Jan 2009, 5:11:27 UTC


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

Richard HaselgroveProject donor
Volunteer tester
Send message
Joined: 4 Jul 99
Posts: 8465
Credit: 48,924,712
RAC: 75,869
United Kingdom
Message 858284 - Posted: 26 Jan 2009, 22:45:18 UTC - in response to Message 856661.

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.

archae86
Send message
Joined: 31 Aug 99
Posts: 888
Credit: 1,572,688
RAC: 42
United States
Message 858361 - Posted: 27 Jan 2009, 1:16:15 UTC

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.
____________

SManning
Send message
Joined: 19 May 99
Posts: 6
Credit: 537,153
RAC: 0
United States
Message 859627 - Posted: 30 Jan 2009, 6:06:10 UTC

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
____________

Previous · 1 · 2 · 3 · 4 · 5

Message boards : Number crunching : Got *much* more work than asked for

Copyright © 2014 University of California