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

In that particular case 20 mb units might not be much, but did you look at one of my previous posts, 856162. No user button pushing, and got 11 AP + 9 MB tasks, over 150 hrs of work when requesting 170 sec of work.
This not a cuda capable computer and still using V5.10.13.

So to conclude;
It is not only Button abusers.
It is not only CUDA capable, or recent clients.
It is not always just a little bit extra work.

I did the simple math that archae86 hadn't done. His BOINC process is working fine and its delivering Seti work at the level that he asked for it. nothing more.

I never implied their wasn't a glitch but everyone that suddenly downloads 20 MB WU's thinks that they have the glitch. and since not everyone says what they set their cache to I have to assume its set to longer than 1 day. It's all about the pertinent info. Yes people here have seen and been victims of the glitch. not everyone here is a victim.
____________
In a rich man's house there is no place to spit but his face.
Diogenes Of Sinope

I can confirm that BOINC 6.2.19 also gets work when its not requested. See log below. All projects were set to NNW. I was trying to report a task. As you can see it still gets work despite not asking for any. Seeing as 5.10.45 is doing the same thing this would suggest the bug is on the server side as BOINC hasn't been updated.

Its not just a user asked problem. Mine started when it restarted from the 6.6.2 install. I just kept repeating the 354240.00 seconds cuda work request over and over. I have cuda (8600gt) but was set to no cuda. It only stopped when set to NNT but started up again with ANT. Changed to 6.4.5 and seems to be ok again. 600+ wu's with ~60 ap's is a lot more then my 4 day cache should be. My normal disk usage is about 50-70mb and it is at about 700mb.
____________

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.

I did the simple math that archae86 hadn't done. His BOINC process is working fine and its delivering Seti work at the level that he asked for it. nothing more.

My BOINC process asked for 1 second of work from SETI. That should have been served with 1 WU by the Berkeley site. The anomaly here was on the Berkeley side. It does not know, and is not told the state of my work from other projects. Short of computer telepathy, it could not have been somehow figuring out what my host "really" wanted and sending that instead. It is just supposed to translate the number of seconds of work requested given the estimate of work for each WU, and its current estimate of my hosts ability to perform work. Were the BOINC process on my host cleverly asking for more, it would have been expressed as a request for more seconds of work (it is quite happy to ask for hundreds of thousands of seconds, when indicated).

As to simple math, it is true that I did not do that--instead I let BOINCView do it for me, as documented in the post. I have plenty of accumulated experience of observing on which I base my confidence in the math BOINCView does in this case. It noticed the Astropulse work, which while only three of the twenty WUs weighs rather more heavily in the work they represent.

There is certainly a gremlin in the system as I've noticed it on several PCS.

One is an OLD PIII that sits in the corner just doing it's thing. It takes about 30 hours to crunch a normal work unit, and has a 3 day cache. So it normally has 3 or 4 WUs. It asked for 17 seconds work and got 17 wus.!!! About 3 weeks work.

Another machine I had switched to 'No new work' and ran the cache out. Manually updated to report the last few work units, requested 0 seconds, got 20 new work units ???

No CUDA or new Clients involved, although I wonder if something has spazzed out in the programming changes that were being made to allow more work units to sent to high spec CUDA machines?

Did the system mmistake my ole PIII for a CUDA equipped I7 ???? I wish.. :-)

I did the simple math that archae86 hadn't done. His BOINC process is working fine and its delivering Seti work at the level that he asked for it. nothing more.

My BOINC process asked for 1 second of work from SETI. That should have been served with 1 WU by the Berkeley site. The anomaly here was on the Berkeley side. It does not know, and is not told the state of my work from other projects. Short of computer telepathy, it could not have been somehow figuring out what my host "really" wanted and sending that instead. It is just supposed to translate the number of seconds of work requested given the estimate of work for each WU, and its current estimate of my hosts ability to perform work. Were the BOINC process on my host cleverly asking for more, it would have been expressed as a request for more seconds of work (it is quite happy to ask for hundreds of thousands of seconds, when indicated).

As to simple math, it is true that I did not do that--instead I let BOINCView do it for me, as documented in the post. I have plenty of accumulated experience of observing on which I base my confidence in the math BOINCView does in this case. It noticed the Astropulse work, which while only three of the twenty WUs weighs rather more heavily in the work they represent.

Agreed. One point of clarification though, the project does know the exact state of all the work which is onboard the host at the time of a connection. It's included in the scheduler request.

For reference, this host runs a CI/CO of 0.01/0.25 days respectively, and a quick look at the link I gave for it shows that the project completely out of the blue, and on it's own decided to pop the host with 6 new tasks totaling 543530 seconds (6.29 days), when it should have sent none.

There is no other way to explain this other than the project is currently screwing up how it is handling work requests and what it is calculating for work assignments. In the case of my host, this has guaranteed blown deadlines for at least 2 (probably 3) of the 6 SAH tasks it sent. The reason is it must now run the two tasks for the other projects in HP/EDF first (due to deadlines sooner than the SAH tasks) which will leave only about 4 days till deadline for SAH to run over 6 days of work.

That's the worst case I have so far, but it also spoffed the assignment to my T2400, and sent 20 to it when it should have sent one. However in it's case (CI/CO = 0.01/0.6667 days) it has sufficient performance overhead to work thorough it without missing a deadline. However, it is guaranteed to diverge from Resource Share until this gets fixed (and the sooner the better).

The anomaly here was on the Berkeley side. It does not know, and is not told the state of my work from other projects.

One point of clarification though, the project does know the exact state of all the work which is onboard the host at the time of a connection. It's included in the scheduler request.

Alinator,

Thanks for the useful information.

With the clue provided by your post I noticed the scheduler request and reply files in the top-level BOINC directory.

Opening them for Einstein and Seti (my only two projects) showed a WU-by-WU accounting of results in progress for both projects in the request sent to each project.

So the specific assertion in the second sentence (of my own) quoted is entirely false.

Nevertheless, I think we generally agree on the description of the Berkeley-side response as in error. Thanks for educating me. At Ye Aulde Microprocessor Workes we called this sort of conversation "violent agreement". It can actually be pretty productive at times.
____________

Reports in this thread seem to indicate that this issue is not limited to BOINC version (so it cannot be a bug within the BOINC code; older versions that worked fine are now exhibiting this flaw), and is not limited to 'button pushers' or 'CUDA users'.

An interesting(?) side note to this is that, although not entirely Boinc version dependent, while I was running v6.6.2 for a couple of days on my quaddie with cuda (1 day cache set) I got 900 WU's each downloaded in response to the first server contact of the day. That first request was for 0 seconds of work but after the first 20 had downloaded, the client continuously requested 86400 seconds for both the CPU and GPU until the daily limit was reached.

I reverted to Boinc 6.6.0 about 12 hours ago and have not received any more WU's (which the aim of the exercise as, even with my 25% CPDN share suspended, it is going to take several days with everything running in high priority to clear the backlog).

We seem to have two quite separate problems being reported in this thread.

First, the SETI server issuing large amounts of work in response to a small, or null, work request. Theis is pretty much independent of the BOINC client being used - my Work Fetch Anomaly was BOINC v5.10.13: the event was timed at 15 Jan 2009 5:56:54 UTC, if that helps track down the precise server code update which brought on the problem.

Second, and very particular to the BOINC v6.6.2 client, is a client-initiated problem of actually requesting excess work until inhibited by the daily quota.

Murphy's law strikes: the daily quota has recently been increased for CUDA-capable machines, and Matt has recently installed lots of extra storage. So the old failsafe of stopping work production when the disks get full ain't goona happen for a while yet. The downhill pipe has been saturated all night, and will be doubly-saturated from an hour ago with the release of the new daily quota. About the only limit in operation right now will be the stalled uploads (being shouldered out of the way by the downloads), which should inhibit all scheduler contact when the pending uploads on each host reach 2 x nCPUs.

I had a try at 6.6.2 also, but had no text in the boinc panels and couldnÂ´t make it work so next day shifted back to 6.6.0
My cache was then filled with 225 AP and 1200 MB workunits ???
Talk about a days work here ??

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.

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

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.

But that aside, I think you're missing the point. His machine requested 1 second of work, with a request like that he should only have gotten 1 of any kind of WU. Aborting or not (and I don't think this increases debt, though I could be wrong), you're trying to fit the math of adding up some WUs into the situation you think the system somehow just knows, but again, I would point you to the first line -
Requesting 1 seconds of work

I just don't see how you can say getting all that work from the 1 second request is something that should be expected? If that were true, why wouldn't every request for any amount of work result in downloads that keep coming until the daily limit is reached? It seems like what you're saying is that the amount requested just doesn't matter in any way, and I don't think that's correct (or at least, when the system was working properly, it wasn't correct).

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.

But that aside, I think you're missing the point. His machine requested 1 second of work, with a request like that he should only have gotten 1 of any kind of WU. Aborting or not (and I don't think this increases debt, though I could be wrong), you're trying to fit the math of adding up some WUs into the situation you think the system somehow just knows, but again, I would point you to the first line -
Requesting 1 seconds of work

I just don't see how you can say getting all that work from the 1 second request is something that should be expected? If that were true, why wouldn't every request for any amount of work result in downloads that keep coming until the daily limit is reached? It seems like what you're saying is that the amount requested just doesn't matter in any way, and I don't think that's correct (or at least, when the system was working properly, it wasn't correct).

-Dave

Agreed. If the host has become cache overloaded for it's CI/CO, aborting a task should not result in the project sending anymore work under any circumstances (at least until the cache overload is gone that it).