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.

24/01/2009 11:21:10 AM||Starting BOINC client version 6.2.19 for windows_intelx86
24/01/2009 11:21:10 AM||log flags: task, file_xfer, sched_ops
24/01/2009 11:21:10 AM||Libraries: libcurl/7.18.0 OpenSSL/0.9.8e zlib/1.2.3
24/01/2009 11:21:10 AM||Data directory: C:\Documents and Settings\Seti\Application Data\BOINC
24/01/2009 11:21:10 AM||Running under account Seti
24/01/2009 11:21:10 AM|SETI@home|Found app_info.xml; using anonymous platform
24/01/2009 11:21:10 AM||Processor: 4 GenuineIntel Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz [x86 Family 6 Model 15 Stepping 11]
24/01/2009 11:21:10 AM||Processor features: fpu tsc pae nx sse sse2 mmx
24/01/2009 11:21:10 AM||OS: Microsoft Windows XP: Professional x86 Editon, Service Pack 3, (05.01.2600.00)
24/01/2009 11:21:10 AM||Memory: 1.99 GB physical, 3.84 GB virtual
24/01/2009 11:21:10 AM||Disk: 148.78 GB total, 138.69 GB free
24/01/2009 11:21:10 AM||Local time is UTC +11 hours
24/01/2009 11:21:10 AM|Einstein@Home|URL: http://einstein.phys.uwm.edu/; Computer ID: 1243052; location: home; project prefs: default
24/01/2009 11:21:10 AM|orbit@home|URL: http://orbit.psi.edu/oah/; Computer ID: 6892; location: home; project prefs: default
24/01/2009 11:21:10 AM|SETI@home|URL: http://setiathome.berkeley.edu/; Computer ID: 4238333; location: home; project prefs: default
24/01/2009 11:21:10 AM||General prefs: from SETI@home (last modified 20-Jul-2008 13:15:35)
24/01/2009 11:21:10 AM||Computer location: home
24/01/2009 11:21:10 AM||General prefs: no separate prefs for home; using your defaults
24/01/2009 11:21:10 AM||Reading preferences override file
24/01/2009 11:21:10 AM||Preferences limit memory usage when active to 1019.21MB
24/01/2009 11:21:10 AM||Preferences limit memory usage when idle to 1834.58MB
24/01/2009 11:21:10 AM||Preferences limit disk usage to 37.25GB
24/01/2009 11:21:13 AM||Can't resolve hostname CNF7411NB1 in remote_hosts.cfg
24/01/2009 11:21:13 AM||file projects/setiathome.berkeley.edu/ap_5.00r69_SSE3.exe not found
24/01/2009 11:21:13 AM||Suspending network activity - user is active
24/01/2009 11:21:13 AM|SETI@home|Restarting task ap_10dc08ad_B4_P1_00275_20090117_26141.wu_0 using astropulse version 500
24/01/2009 11:21:13 AM|SETI@home|Restarting task ap_10dc08ad_B6_P0_00072_20090117_09535.wu_1 using astropulse version 500
24/01/2009 11:21:13 AM|SETI@home|Restarting task ap_10dc08ad_B6_P0_00075_20090117_09535.wu_1 using astropulse version 500
24/01/2009 11:21:13 AM|SETI@home|Restarting task 07no08aa.3235.72.16.8.3_0 using setiathome_enhanced version 528
24/01/2009 11:21:54 AM||Resuming network activity
24/01/2009 11:21:54 AM|SETI@home|Sending scheduler request: Requested by user. Requesting 0 seconds of work, reporting 1 completed tasks
24/01/2009 11:21:59 AM|SETI@home|Scheduler request succeeded: got 15 new tasks
24/01/2009 11:22:01 AM|SETI@home|Started download of 15dc08ae.19202.40748.16.8.74
24/01/2009 11:22:01 AM|SETI@home|Started download of 08no08ae.21335.13978.7.8.245
24/01/2009 11:22:14 AM||Suspending network activity - user request

---

BOINC blog

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.

-Dave

---

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.. :-)

Ian

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.

Here's an example from the last one to SAH from one of my hosts:

  <other_results /> 
- <in_progress_results>
- <ip_result>
  <name>h1_0722.55_S5R4__376_S5R4a_1</name> 
  <report_deadline>1233001475.000000</report_deadline> 
  <cpu_time_remaining>177103.386424</cpu_time_remaining> 
  </ip_result>
- <ip_result>
  <name>wu_164284800_1227694842_65230_0</name> 
  <report_deadline>1232977824.000000</report_deadline> 
  <cpu_time_remaining>90368.861345</cpu_time_remaining> 
  </ip_result>
  </in_progress_results>
  </scheduler_request>

I chose this host, because this contact was supposed to be just to report a completed task (as determined by the CC, no button pushing here):

<scheduler_request>
  <authenticator>CLASSIFIED</authenticator> 
  <hostid>782084</hostid> 
  <rpc_seqno>394</rpc_seqno> 
  <core_client_major_version>5</core_client_major_version> 
  <core_client_minor_version>10</core_client_minor_version> 
  <core_client_release>13</core_client_release> 
  <work_req_seconds>0.000000</work_req_seconds> 
  <resource_share_fraction>0.009615</resource_share_fraction> 
  <rrs_fraction>0.500000</rrs_fraction> 
  <prrs_fraction>0.250000</prrs_fraction> 
  <estimated_delay>0.000000</estimated_delay> 
  <duration_correction_factor>1.871565</duration_correction_factor> 
  <platform_name>anonymous</platform_name>

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

Alinator

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

I have PM'd Eric to take a look at this thread.

---

Agreed.

AFAICT, this is not a client side issue, but rather a SAH specific server side problem. None of the other projects I run have exhibited any unexpected request handling and/or work assignments.

Unfortunately, it doesn't appear to be a cut and dried bug, as I have had SAH requests go through correctly as well since Richard first reported it 10 days or so ago in the Work Fetch Anomaly thread.

Alinator

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

F.

---

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.

Hi guys,

I have the same problem, in BOINC 6.4.5 :

23/01/2009 17:54:29|SETI@home|Started upload of 10dc08af.20296.18068.13.8.174_0_0
23/01/2009 17:54:29|SETI@home|Started upload of 10dc08af.20296.18068.13.8.188_0_0
23/01/2009 17:54:34|SETI@home|Finished upload of 10dc08af.20296.18068.13.8.174_0_0
23/01/2009 17:54:34|SETI@home|Finished upload of 10dc08af.20296.18068.13.8.188_0_0
23/01/2009 18:00:06|SETI@home|Sending scheduler request: Requested by user. Requesting 0 seconds of work, reporting 18 completed tasks
23/01/2009 18:00:11|SETI@home|Scheduler request completed: got 0 new tasks
23/01/2009 18:00:26|SETI@home|Sending scheduler request: Requested by user. Requesting 0 seconds of work, reporting 0 completed tasks
23/01/2009 18:00:31|SETI@home|Scheduler request completed: got 20 new tasks
23/01/2009 18:00:33|SETI@home|Started download of 15dc08ae.2372.38703.15.8.148
23/01/2009 18:00:33|SETI@home|Started download of 15dc08ae.2372.38703.15.8.175

I hope I'll get everything done before the deadline?

Greetings,
Eric

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.

Alinator

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.

Well, both of the below are cut from the list posted:

stoll5 SETI@home 1/23/2009 5:22 Started download of ap_20dc08ad_B5_P0_00028_20090123_17965.wu
stoll5 SETI@home 1/23/2009 5:22 Started download of ap_20dc08ad_B4_P1_00356_20090123_15293.wu

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

---

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.

Well, both of the below are cut from the list posted:

stoll5 SETI@home 1/23/2009 5:22 Started download of ap_20dc08ad_B5_P0_00028_20090123_17965.wu
stoll5 SETI@home 1/23/2009 5:22 Started download of ap_20dc08ad_B4_P1_00356_20090123_15293.wu

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

Alinator