## Got *much* more work than asked for

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

Previous · 1 · 2 · 3 · 4 · 5 · Next

AuthorMessage
ignorance is no excuse

Joined: 4 Oct 00
Posts: 9529
Credit: 44,433,321
RAC: 0
Message 856932 - Posted: 23 Jan 2009, 21:33:09 UTC - in response to Message 856917.

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

End terrorism by building a school

ID: 856932 ·
WinterKnight
Volunteer tester

Joined: 18 May 99
Posts: 10194
Credit: 30,547,364
RAC: 3,229
Message 856959 - Posted: 23 Jan 2009, 23:30:35 UTC - in response to Message 856932.

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.
ID: 856959 ·
ignorance is no excuse

Joined: 4 Oct 00
Posts: 9529
Credit: 44,433,321
RAC: 0
Message 856975 - Posted: 24 Jan 2009, 0:25:39 UTC - in response to Message 856959.

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

End terrorism by building a school

ID: 856975 ·
MarkJ
Volunteer tester

Joined: 17 Feb 08
Posts: 978
Credit: 33,086,631
RAC: 5,185
Message 856977 - Posted: 24 Jan 2009, 0:30:23 UTC

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||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||Suspending network activity - user is active
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:14 AM||Suspending network activity - user request

BOINC blog
ID: 856977 ·
Slow_Target

Joined: 5 Oct 02
Posts: 58
Credit: 5,518,539
RAC: 638
Message 856990 - Posted: 24 Jan 2009, 0:59:56 UTC

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.
ID: 856990 ·
dnolan

Joined: 30 Aug 01
Posts: 1228
Credit: 47,209,062
RAC: 0
Message 856996 - Posted: 24 Jan 2009, 1:14:49 UTC - in response to Message 856932.

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
ID: 856996 ·
archae86

Joined: 31 Aug 99
Posts: 909
Credit: 1,582,816
RAC: 0
Message 857023 - Posted: 24 Jan 2009, 2:26:22 UTC - in response to Message 856975.

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.

ID: 857023 ·
Ianab
Volunteer tester

Joined: 11 Jun 08
Posts: 690
Credit: 16,390,665
RAC: 7,920
Message 857030 - Posted: 24 Jan 2009, 2:40:28 UTC

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
ID: 857030 ·
Alinator
Volunteer tester

Joined: 19 Apr 05
Posts: 4178
Credit: 4,647,982
RAC: 0
Message 857048 - Posted: 24 Jan 2009, 3:47:41 UTC - in response to Message 857023.

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>
<cpu_time_remaining>177103.386424</cpu_time_remaining>
</ip_result>
- <ip_result>
<name>wu_164284800_1227694842_65230_0</name>
<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
ID: 857048 ·
archae86

Joined: 31 Aug 99
Posts: 909
Credit: 1,582,816
RAC: 0
Message 857054 - Posted: 24 Jan 2009, 4:15:39 UTC - in response to Message 857048.

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.
ID: 857054 ·
OzzFan
Volunteer tester

Joined: 9 Apr 02
Posts: 15126
Credit: 45,611,632
RAC: 46,726
Message 857090 - Posted: 24 Jan 2009, 6:18:32 UTC

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.
ID: 857090 ·
Alinator
Volunteer tester

Joined: 19 Apr 05
Posts: 4178
Credit: 4,647,982
RAC: 0
Message 857095 - Posted: 24 Jan 2009, 6:41:10 UTC - in response to Message 857090.

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

ID: 857095 ·
Fred W
Volunteer tester

Joined: 13 Jun 99
Posts: 2524
Credit: 11,954,210
RAC: 0
Message 857114 - Posted: 24 Jan 2009, 8:40:11 UTC

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.
ID: 857114 ·
Richard Haselgrove
Volunteer tester

Joined: 4 Jul 99
Posts: 11143
Credit: 83,914,809
RAC: 48,616
Message 857120 - Posted: 24 Jan 2009, 9:15:47 UTC

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.
ID: 857120 ·
Eric Steensels

Joined: 16 May 99
Posts: 14
Credit: 2,717,784
RAC: 693
Message 857135 - Posted: 24 Jan 2009, 10:28:11 UTC - in response to Message 856672.

Hi guys,

I have the same problem, in BOINC 6.4.5 :

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

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

Greetings,
Eric

ID: 857135 ·
Bukken

Joined: 3 Apr 99
Posts: 50
Credit: 3,007,776
RAC: 0
Message 857155 - Posted: 24 Jan 2009, 12:16:55 UTC

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 ??
ID: 857155 ·
ignorance is no excuse

Joined: 4 Oct 00
Posts: 9529
Credit: 44,433,321
RAC: 0
Message 857179 - Posted: 24 Jan 2009, 14:35:02 UTC - in response to Message 856996.

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

End terrorism by building a school

ID: 857179 ·
Alinator
Volunteer tester

Joined: 19 Apr 05
Posts: 4178
Credit: 4,647,982
RAC: 0
Message 857194 - Posted: 24 Jan 2009, 15:44:35 UTC - in response to Message 857179.

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
ID: 857194 ·
dnolan

Joined: 30 Aug 01
Posts: 1228
Credit: 47,209,062
RAC: 0
Message 857195 - Posted: 24 Jan 2009, 15:45:35 UTC - in response to Message 857179.

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:

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

ID: 857195 ·
Alinator
Volunteer tester

Joined: 19 Apr 05
Posts: 4178
Credit: 4,647,982
RAC: 0
Message 857198 - Posted: 24 Jan 2009, 15:51:26 UTC - in response to Message 857195.

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:

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
ID: 857198 ·
Previous · 1 · 2 · 3 · 4 · 5 · Next

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