Let me know if the increase queue size helps at all with the work availability.

27/02/2009 16:31:35|Milkyway@home|Message from server: Project is temporarily shut down for maintenance

Let me know if the increase queue size helps at all with the work availability.

Still nothing here.

Let me know if the increase queue size helps at all with the work availability.

Looking forward to it Travis, but right now I have this;

27/02/2009 16:31:35|Milkyway@home|Message from server: Project is temporarily shut down for maintenance

No work availabilty just now

Yeah, I just restarted the server :P Work should start flowing now.

27/02/2009 16:36:26|Milkyway@home|Sending scheduler request: To fetch work. Requesting 1745280 seconds of work, reporting 0 completed tasks
27/02/2009 16:36:32|Milkyway@home|Scheduler request succeeded: got 0 new tasks

Hmmm...

Insta-Purge seems to back to. :-(

UGGGHHH! PITA time again for data logging.

<edit> It seems to me that if you cannot even accommodate a 1 hour delay in purging the completed tasks, then you have a serious overbooking and/or backend capacity problem that allowing more work out in the field is not going to help one iota.

Alinator

Nothing at all since that one task;

27/02/2009 16:43:14|Milkyway@home|Scheduler request succeeded: got 0 new tasks

> got 49 WU's on one machine, 50 WU's on another but these are the exception... mostly '0 new tasks' after repeated manual primes...

Well I haven't been following their work feeder problem that closely. However, in general BOINC terms, if you cannot transition enough work fast enough into the schedulers limited size queue, then this is what you end up seeing even if there is plenty of tasks coming out of the work generator(s).

Alinator

Just got 80 for the Quad.
____________

OK, I just got a bunch through. It was quite a shock to see so many :P

____________

OK, I just got a bunch through. It was quite a shock to see so many :P

Yup, the new limit came down right away on two machines with one manual update. Looks good so far.

I'm not seeing a reduction in the amount of '0 new tasks' and am not hitting the WU download limit.

Sitting idle here ... sigh ... when I checked the server page it said 500 available ... now 437 ... refetch master file, still nothing ...

ARRRRGGGGGHHHHH!

idle ATI GPU ... man this is depressing ...

Nearly 80 new WU here aswell.

I'm wondering if one could code a script which would request an update at say 15 second intervals automatically -- that would eventually get work, of course hammering the server might not have the right effect if such a script got out in the wild....
____________

Still no improvement here, wu unit increase made no difference at all, I've still got computers Idle and comms backed of for hours.
____________
m4rtyn
******************************* *******************************

It's really hard to catch WUs because there's several "Scheduler request completed: got 0 new tasks" messages before one gets work eventually.

But it's still an improvement to have the bigger WU cache of 20/core because if you catch WUs it now takes longer until the boxes cry for more. *LOL*
____________
Lovely greetings, Cori

Yep, not seeing a change here either. Took 30 mins of updating every min to get like 3 mins of work. Then back to nothing.

Would be nice to see 20 per core sitting there.

Rick

It's taking several tries to get any work, and not even getting the full 20/core either...

27/02/2009 21:46:49|Milkyway@home|Sending scheduler request: Requested by user. Requesting 3046482 seconds of work, reporting 4 completed tasks
27/02/2009 21:46:55|Milkyway@home|Scheduler request completed: got 0 new tasks
27/02/2009 21:47:00|SHA-1 Collision Search Graz|Sending scheduler request: Requested by user. Requesting 0 seconds of work, reporting 0 completed tasks
27/02/2009 21:47:05|SHA-1 Collision Search Graz|Scheduler request completed: got 0 new tasks
27/02/2009 21:47:15|Milkyway@home|Sending scheduler request: Requested by user. Requesting 3046900 seconds of work, reporting 0 completed tasks
27/02/2009 21:47:20|Milkyway@home|Scheduler request completed: got 0 new tasks
27/02/2009 21:47:30|Milkyway@home|Fetching scheduler list
27/02/2009 21:47:35|Milkyway@home|Master file download succeeded
27/02/2009 21:47:40|Milkyway@home|Sending scheduler request: Requested by user. Requesting 3047232 seconds of work, reporting 0 completed tasks
27/02/2009 21:47:45|Milkyway@home|Scheduler request completed: got 0 new tasks
27/02/2009 21:47:56|Milkyway@home|Sending scheduler request: Requested by user. Requesting 3047577 seconds of work, reporting 0 completed tasks
27/02/2009 21:48:01|Milkyway@home|Scheduler request completed: got 0 new tasks
27/02/2009 21:48:26|Milkyway@home|Sending scheduler request: Requested by user. Requesting 3047971 seconds of work, reporting 0 completed tasks
27/02/2009 21:48:31|Milkyway@home|Scheduler request completed: got 0 new tasks
27/02/2009 21:48:46|Milkyway@home|Sending scheduler request: Requested by user. Requesting 3048311 seconds of work, reporting 0 completed tasks
27/02/2009 21:48:51|Milkyway@home|Scheduler request completed: got 0 new tasks
27/02/2009 21:49:52|Milkyway@home|Sending scheduler request: To fetch work. Requesting 3049346 seconds of work, reporting 0 completed tasks
27/02/2009 21:49:57|Milkyway@home|Scheduler request completed: got 8 new tasks
27/02/2009 21:49:59|Milkyway@home|Started download of ps_s82_9_search_parameters_186427_1235771352
27/02/2009 21:49:59|Milkyway@home|Started download of ps_s86_9_search_parameters_186428_1235771352
27/02/2009 21:50:00|Milkyway@home|Finished download of ps_s82_9_search_parameters_186427_1235771352
27/02/2009 21:50:00|Milkyway@home|Finished download of ps_s86_9_search_parameters_186428_1235771352
27/02/2009 21:50:00|Milkyway@home|Started download of ps_s86_9_search_parameters_186429_1235771352
27/02/2009 21:50:00|Milkyway@home|Started download of ps_s86_9_search_parameters_186430_1235771352
27/02/2009 21:50:01|Milkyway@home|Finished download of ps_s86_9_search_parameters_186429_1235771352
27/02/2009 21:50:01|Milkyway@home|Finished download of ps_s86_9_search_parameters_186430_1235771352
27/02/2009 21:50:01|Milkyway@home|Started download of ps_s86_9_search_parameters_186431_1235771352
27/02/2009 21:50:01|Milkyway@home|Started download of ps_s82_9_search_parameters_186382_1235771351
27/02/2009 21:50:02|Milkyway@home|Finished download of ps_s86_9_search_parameters_186431_1235771352
27/02/2009 21:50:02|Milkyway@home|Finished download of ps_s82_9_search_parameters_186382_1235771351
27/02/2009 21:50:02|Milkyway@home|Started download of ps_s82_9_search_parameters_186384_1235771351
27/02/2009 21:50:02|Milkyway@home|Started download of ps_s82_9_search_parameters_186385_1235771351
27/02/2009 21:50:03|Milkyway@home|Finished download of ps_s82_9_search_parameters_186384_1235771351
27/02/2009 21:50:03|Milkyway@home|Finished download of ps_s82_9_search_parameters_186385_1235771351
27/02/2009 21:50:08|Milkyway@home|Sending scheduler request: To fetch work. Requesting 3021818 seconds of work, reporting 0 completed tasks
27/02/2009 21:50:13|Milkyway@home|Scheduler request completed: got 0 new tasks
27/02/2009 21:51:13|Milkyway@home|Sending scheduler request: To fetch work. Requesting 3022868 seconds of work, reporting 0 completed tasks
27/02/2009 21:51:18|Milkyway@home|Scheduler request completed: got 0 new tasks
27/02/2009 21:51:18|Milkyway@home|Message from server: No work sent
27/02/2009 21:51:18|Milkyway@home|Message from server: (reached per-CPU limit of 20 tasks)

In the 8 hours since I last posted I have had 4-5 small batches of work and thats it.

Well I haven't been following their work feeder problem that closely. However, in general BOINC terms, if you cannot transition enough work fast enough into the schedulers limited size queue, then this is what you end up seeing even if there is plenty of tasks coming out of the work generator(s).

Alinator

Yeah, I'm thinking this might be the problem. Now I just have to figure out how to increase the scheduler's queue size.

Looks like lots more WUs ready to distribute, but getting any work seems to be almost impossible.

Even with manual forced requests ... zilch ... and the BOINC Projects tab shows MW up to 3 hours and more, which means more forced requests until it's back down to 1 minute.

First time this has really hit me. It's letting Einstein in for crunching.

I guess as it's the weekend and Seti always goes down at the weekend as well, a few other projects are going to get some extra work done again :)
____________

As of 1:44:14 UTC server status shows 0 results ready to send and the validator seems to have stopped. Rats, I may have to temporarily go back to SETI on these two machines.

Noooooooo

Is it just me or has it been harder to get work since the cache limit was bumped up?

____________

Calm Chaos Forum...Join Calm Chaos Now

Just got 17 new tasks after many update tries
Glenn
____________

The assimilator/validator was crashed for the last hour or so, which would make it hard to get work :P

Ahh, never mind - just saw the message about limiting it to 6... Ok.

I hope you have a nice big network pipe - lots of requests coming your way :)
____________
.

Hi Travis,
Why a limit of 6/cpu we had 12 up till last nite things were running not bad with a limit of 12 maybe you should put it back that...
Glenn
____________

See the above post. I dropped the queue down to 6 per core to see if this will help more people get work. It was looking like with the limit at 20, the scheduler was running out of work to send very quickly and more people were getting the out of work message.

*edit*

before you flip out too much -- this is just temporary to see if this helps with work availability. if it doesn't help i'll increase the queue again. also, once we get a larger queue for the scheduler we'll be able to increase the work unit queue as well.

I don't know how many GPUs are already in use on this project, but with more likely to be used soon I would think it a good idea to increase the size of each wu, so there will not need to be so many requests.

Given that once a client is unable to receive work a couple of times, the time between requests increases, there are going to be a lot more people out of work for longer periods because of such a small amount of work (on all my systems, 6 wu per core will typically keep me going between approx 60 and 90 minutes, and you are not proving you can feed us with work that fast).
____________

Travis,

As long as you think your server can handle the requests..

This is just 1 machine with a GPU - you will notice it requesting every few seconds, and getting 1 - it is going to destroy your bandwidth - and may cause some issues on the RPC calls on your side.. I am not sure about this, but something to consider.


2/27/2009 19:59:30|Milkyway@home|Sending scheduler request: Requested by user. Requesting 2488366 seconds of work, reporting 1 completed tasks
2/27/2009 19:59:35|Milkyway@home|Scheduler request completed: got 1 new tasks
2/27/2009 19:59:46|Milkyway@home|Sending scheduler request: To report completed tasks. Requesting 2488191 seconds of work, reporting 1 completed tasks
2/27/2009 19:59:51|Milkyway@home|Scheduler request completed: got 1 new tasks
2/27/2009 20:00:02|Milkyway@home|Sending scheduler request: To report completed tasks. Requesting 2488079 seconds of work, reporting 1 completed tasks
2/27/2009 20:00:07|Milkyway@home|Scheduler request completed: got 1 new tasks
2/27/2009 20:00:17|Milkyway@home|Sending scheduler request: To report completed tasks. Requesting 2487999 seconds of work, reporting 1 completed tasks
2/27/2009 20:00:22|Milkyway@home|Scheduler request completed: got 1 new tasks




Guess it is time to open up another project to run as well.
____________
.

Do you have the option to limit DL's to perhaps 10 at once but keep the total limit at 20 per core? That should ease the hits on the scheduler yet leave us with a little better comfort level if we do manage get a full quota, and let us get a partial load to hold us over in the mean time.

Up until yesterday my quad had very rarely run out of work. Now, in the last 24 hours, it has run completely dry probably 5 times or more and all I get is the same as others:

"Scheduler request completed: got 0 new tasks"

I was thinking about doing something like this. Going to let the 6 WU queue go for awhile and see if it helps anything first.

The assimilator/validator doesn't seem to be crashing anymore *fingers crossed* so work availability should be better from here on out.

Gday all.. Just saw this result in my task list wondering why it is so???

Task ID 12690510
Name ps_s82_10_394_1235776518_0
Workunit 12383039
Created 27 Feb 2009 23:15:21 UTC
Sent 27 Feb 2009 23:15:54 UTC
Received 28 Feb 2009 4:51:43 UTC
Server state Over
Outcome Success
Client state Done
Exit status 0 (0x0)
Computer ID 21898
Report deadline 2 Mar 2009 23:15:54 UTC
CPU time 1027.891
stderr out <core_client_version>6.4.6</core_client_version>
<![CDATA[
<stderr_txt>
Running Milkyway@home version 0.19 by Gipsel
CPU: Genuine Intel(R) CPU T2300 @ 1.66GHz (2 cores/threads) 1.66677 GHz (917ms)

WU completed. It took 1027.89 seconds CPU time and 1038.24 seconds wall clock time @ 1.66678 GHz.

</stderr_txt>
]]>

Validate state Invalid
Claimed credit 2.83954728750274
Granted credit 0
application version 0.19

Every other task has been validated correctly dont know why this is the odd one out.......
____________

What lowering to 6 does is temporarily (say for maybe a couple of hours) reduce the false (success / 0 new work) messages by replacing them with 'met your CPU limit of 6'. Then, when the completed work drops the queue back from 20 to 6, the same problem pops up again -- but *more* frequently. Now one needs to hit the server for more work almost continuously since it may take about 15 minutes of server pounding for more work to get 45 minutes of work by which time two more work units have completed.

I'm still trying to figure out how one can script a 'pound the server continuously script' <rueful smile>.

I'm going to lower the number to 6 and see if that helps.

Yup -- I think you are spot on here.

I haven't been able to keep my caches full (set for .1 days) for a while now. Cutting back to 6 per core is just going to make it beg even more. Seems to me this would cause more problems for the server instead of it making fewer requests at a longer interval. so I'll help out. Setting all systems to pull from einstein when the server here won't honor requests for work.

Not a complaint as I know you got problems, but would rather have something to do than the computers sitting at idle for long stretches. Maybe this will take some of the load off. Probably wouldn't hurt if others did the same thing over the weekend until you got this worked out. (but then again if more people were doing that you would probably think 6 is enough) <smile>

Feed the beast. Limiting on the workunit queue size to 6 will not stop the beast from starvation. Feed the beast.


Holy Mackerel! Call headquarters. Get the lieutenant.
____________

Gday all.. Just saw this result in my task list wondering why it is so???

Task ID 12690510
Name ps_s82_10_394_1235776518_0
Workunit 12383039
Created 27 Feb 2009 23:15:21 UTC
Sent 27 Feb 2009 23:15:54 UTC
Received 28 Feb 2009 4:51:43 UTC
Server state Over
Outcome Success
Client state Done
Exit status 0 (0x0)
Computer ID 21898
Report deadline 2 Mar 2009 23:15:54 UTC
CPU time 1027.891
stderr out <core_client_version>6.4.6</core_client_version>
<![CDATA[
<stderr_txt>
Running Milkyway@home version 0.19 by Gipsel
CPU: Genuine Intel(R) CPU T2300 @ 1.66GHz (2 cores/threads) 1.66677 GHz (917ms)

WU completed. It took 1027.89 seconds CPU time and 1038.24 seconds wall clock time @ 1.66678 GHz.

</stderr_txt>
]]>

Validate state Invalid
Claimed credit 2.83954728750274
Granted credit 0
application version 0.19

Every other task has been validated correctly dont know why this is the odd one out.......

Sorry, but reducing the wu limit to 6 has only made things worse.
____________
m4rtyn
******************************* *******************************

2009-02-28 09:22:33|Milkyway@home|Message from server: No work sent
2009-02-28 09:22:33|Milkyway@home|Message from server: (reached per-CPU limit of 6 tasks)

I see this info more often than this about getin' 0 new tasks. So it's gettin' better now imo. Anyway i see that more WUs is with granted credit 0.
As far as i can see now 0 credit is granted in about 10 % of my new WUs.

i see that more WUs is with granted credit 0.

At this moment I see also workunits that are getting q credits. I did not see this before this night. Now it looks like to happen with about 10% of the wu.

I forgot. For me it seems to work more smoothfull. I get less wu but the system is running most of time now. The message reaches cpu limit is ocuring regurly, but this is the setting at this moment. This means that the work available for my serer is at that moment the maximum that it is allowed, so I think this has made the situation more stable.

I forgot. For me it seems to work more smoothfull. I get less wu but the system is running most of time now. The message reaches cpu limit is ocuring regurly, but this is the setting at this moment. This means that the work available for my serer is at that moment the maximum that it is allowed, so I think this has made the situation more stable.

Compared to yesterday my rigs (CPU only) seem to be running well, and fed. Yesterday, with the cache at 20 per CPU, I was in the same position as everyone else - zilch.

Still have problems with comps running dry (overnight).
If they don't get work within the first requests of the BOINC manager then the requests get delayed more and more - and the boxes are sitting idle. *sniff sniff*

PS. The lame P4 boxes have more chances to have WUs running of course, the faster comps need to be fed more often. ;-)
____________
Lovely greetings, Cori

Compared to yesterday my rigs (CPU only) seem to be running well, and fed. Yesterday, with the cache at 20 per CPU, I was in the same position as everyone else - zilch.

At this moment I see also workunits that are getting q credits. I did not see this before this night. Now it looks like to happen with about 10% of the wu.

Compared to yesterday my rigs (CPU only) seem to be running well, and fed. Yesterday, with the cache at 20 per CPU, I was in the same position as everyone else - zilch.

Everyone? Zilch? I got a shed load of WUs yesterday, I can tell you. Did anyone else get any? Did everyone get zilch WUs yesterday? Was I the only one who got any WUs yesterday?

If you're going to bitch and complain, at least don't drag me into your 'everyone'.

With the 20 limit, I got more 0 responses than before, but on the other hand I got more WUs when I occasionally got some.

With the limit at 6, I anticipated a lot of 'limit reached' responses, so I lowered my cache from one to half a day. So far, I've seen *none* of the 0 responses, but only a few WUs with each request.

Of course, both my ATI-equipped crunchers are asking for work almost continuously now, but that doesn't seem to matter much.
____________

If there are so many problems with getting as many WU's out as is necessary to keep all crunching cores happily working, why do not you increase the crunching length of a WU? If you increase it by a factor of two, then the amount of SQL-requests to the dataserver should be lowered and server responsiveness should increase accordingly...
____________

OK shoot me for this!
The baby ATI cruncher grew into a monster with an unsatisfying appetite
A quick calculation shows that a 4850 in a quad can gobble up +/- 1400 work units in an hour!
These monsters multiplied rapidly when a lot of crunchers rushed to the stores to get theirs
Now the server and network can’t keep up feeding these hungry monsters.

Result:
Everyone is starving!

I still run out of work, two CPU apps dried up over the last 3 hours left to their own devices. The small WU queue did improve the situation a lot though.
This is with a 4870- not so good:

02/28/09 06:10:38|Milkyway@home|Sending scheduler request: To fetch work. Requesting 129629 seconds of work, reporting 8 completed tasks
02/28/09 06:10:43|Milkyway@home|Scheduler request completed: got 8 new tasks
02/28/09 06:10:53|Milkyway@home|Sending scheduler request: To fetch work. Requesting 115461 seconds of work, reporting 0 completed tasks
02/28/09 06:10:58|Milkyway@home|Scheduler request completed: got 0 new tasks
02/28/09 06:12:00|Milkyway@home|Sending scheduler request: To fetch work. Requesting 132473 seconds of work, reporting 8 completed tasks
02/28/09 06:12:05|Milkyway@home|Scheduler request completed: got 0 new tasks
02/28/09 06:13:05|Milkyway@home|Sending scheduler request: To fetch work. Requesting 149010 seconds of work, reporting 0 completed tasks
02/28/09 06:13:10|Milkyway@home|Scheduler request completed: got 0 new tasks
02/28/09 06:14:11|Milkyway@home|Sending scheduler request: To fetch work. Requesting 165398 seconds of work, reporting 9 completed tasks
02/28/09 06:14:16|Milkyway@home|Scheduler request completed: got 0 new tasks
02/28/09 06:15:16|Milkyway@home|Sending scheduler request: To fetch work. Requesting 172803 seconds of work, reporting 7 completed tasks
02/28/09 06:15:21|Milkyway@home|Scheduler request completed: got 0 new tasks

OK shoot me for this!
The baby ATI cruncher grew into a monster with an unsatisfying appetite
A quick calculation shows that a 4850 in a quad can gobble up +/- 1400 work units in an hour!
These monsters multiplied rapidly when a lot of crunchers rushed to the stores to get theirs
Now the server and network can’t keep up feeding these hungry monsters.

Result:
Everyone is starving!

Although the server side says there is plenty of WUs to be released so, clearly, the issuing to work to requests are the problem still. Again I am, uncharacteristicly, out of work.

Let us hope the problem, and server cache work waiting, issues can be solved early next week.

::Waving to Anton:: who is still sore!

1 WU today 0 yesterday.

:lolol: :lolol: :lolol: :lolol:

Funny kindergarten here.
____________
Lovely greetings, Cori

1 WU today 0 yesterday.

Beats me, ill check out the second PC to see if it has any work.

_________________________
Other one has a ton of work, weird.

[/quote]
Bang! Travis has recently repeated that there are plenty of WUs on the server side. The problem is releasing them to the clients (us), which I understand requires a server memory fix which will be done on Monday, hopefully, the 20/6 WUs being a temporary fix. It has nothing to do do with WU shortage so blaming ATI will do nothing for you.

Go here; http://milkyway.cs.rpi.edu/milkyway/server_status.php

There are 700 WUs for you not being gobbled by ATIs

[edit] it just went up to 800 +[/quote]

Sorry I think you missed

Server status shows 753 ready
I immediately hit update on my dry quad and received 0
I’m not blaming ATI (its ability is amazing!) but this started to escalate when more and more crunchers uses their ATI’s.
I looked randomly at 10 of the top 100 computer’s RAC – they are all ATI equipped.

Other fast PC’s may also contribute to this.
I’m also guilty because I OC’d my Q8200 to 2.9 GHz to pump up my RAC
It’s doing a S82 in 250 seconds
Yesterday I turned down the cache to minimum 0.01 but its scheduler still wants 9000 seconds of work and repeatedly ask for more every 60 seconds even with 76 wu’s ready to start
Doesn’t this put a big strain on the network and server?

Edit
I can also install ATI but with my luck my RAC will go down
____________
A BLAST FROM YOUR PAST

Beats me, ill check out the second PC to see if it has any work.

_________________________
Other one has a ton of work, weird.

Beats me, ill check out the second PC to see if it has any work.

_________________________
Other one has a ton of work, weird.

Just Reset the Project, don't Detach but just reset it if it doesn't have any work & see if you get some. You may not right first but in awhile you might again ...

Hmm ya, one out of two working is good enough.

Beats me, ill check out the second PC to see if it has any work.

_________________________
Other one has a ton of work, weird.

Just Reset the Project, don't Detach but just reset it if it doesn't have any work & see if you get some. You may not right first but in awhile you might again ...

Wait a second...

Resetting the project as a workaround to get more work might be counter productive. The reason is that even if you already have the third party apps to install afterwards, your host is going to have to re-download all the input files it needs that got dumped from the reset. If running stock, it will have to download the app again too.

This is probably not going to do much to help the overall situation. ;-)

Alinator

I don't know how many GPUs are already in use on this project, but with more likely to be used soon I would think it a good idea to increase the size of each wu, so there will not need to be so many requests.

I'd rather have a real fix for the problem, because if we do this the same problem will just show up again when we get more users and starting seeing the same amount of workunit requests...

I don't know how many GPUs are already in use on this project, but with more likely to be used soon I would think it a good idea to increase the size of each wu, so there will not need to be so many requests.

I'd rather have a real fix for the problem, because if we do this the same problem will just show up again when we get more users and starting seeing the same amount of workunit requests...

Larger work units would be a real fix, and would give you more time to sort out the problem with how slowly work is being released at times.

I don't know how many GPUs are already in use on this project, but with more likely to be used soon I would think it a good idea to increase the size of each wu, so there will not need to be so many requests.

I'd rather have a real fix for the problem, because if we do this the same problem will just show up again when we get more users and starting seeing the same amount of workunit requests...

Larger work units would be a real fix, and would give you more time to sort out the problem with how slowly work is being released at times.

I brought this up a couple weeks ago and Travis said they contain enough info and the 'group' doesn't want to increase the size any more.

I brought this up a couple weeks ago and Travis said they contain enough info and the 'group' doesn't want to increase the size any more.

LOL, I'd love to know what majority group thinks everything is fine as it is :)

I looked randomly at 10 of the top 100 computer’s RAC – they are all ATI equipped.

Wait a second...

Resetting the project as a workaround to get more work might be counter productive. The reason is that even if you already have the third party apps to install afterwards, your host is going to have to re-download all the input files it needs that got dumped from the reset. If running stock, it will have to download the app again too.

This is probably not going to do much to help the overall situation. ;-)

Alinator

No, Resetting the Project won't get rid of any Optimized App's, Third Party App's I don't know about but the Optimized ones don't get taken out when Resetting. Yes you'll have to re-download the input files & if you have Dial-Up it could take some time or pose a problem.

I do it all the time but I have Cable so it's no big deal for me to re-download the input files, it only takes a few seconds for me to do that. It works for me but if somebody has a problem with it then don't do it, more work for me then ... :)

I know have work on all computers and including the GPU where I was getting practically nothing.

I know have work on all computers and including the GPU where I was getting practically nothing.

Server-side, it looks like the change helped work availability quite a bit.

I know have work on all computers and including the GPU where I was getting practically nothing.

Server-side, it looks like the change helped work availability quite a bit.

I know have work on all computers and including the GPU where I was getting practically nothing.

Server-side, it looks like the change helped work availability quite a bit.

The only problem- and it's a big one- is when you have 'got 0 new tasks' multiple times in a row, which does still happen, and run dry and the reconnect time goes to 2 or 3 hours and you have nothing to crunch until then... any way to change/fix(?) that?

The only problem- and it's a big one- is when you have 'got 0 new tasks' multiple times in a row, which does still happen, and run dry and the reconnect time goes to 2 or 3 hours and you have nothing to crunch until then... any way to change/fix(?) that?

It depends on what mean by 'fix'.

If you are talking about MW being able to feed work to the scheduler faster, then no, not until Monday at the earliest.

If you're talking about not running dry, then you have two choices:

1.) Sit at the console all the time and pound on the update button when you are out.

2.) Run a backup project and just ride out these difficulties until a satisfactory backend fix can be implemented.

Alinator

So far, I've seen *none* of the 0 responses

Should be even better now that the workunits should take around twice as long to crunch.

The only problem- and it's a big one- is when you have 'got 0 new tasks' multiple times in a row, which does still happen, and run dry and the reconnect time goes to 2 or 3 hours and you have nothing to crunch until then... any way to change/fix(?) that?

It depends on what mean by 'fix'.

If you are talking about MW being able to feed work to the scheduler faster, then no, not until Monday at the earliest.

If you're talking about not running dry, then you have two choices:

1.) Sit at the console all the time and pound on the update button when you are out.

2.) Run a backup project and just ride out these difficulties until a satisfactory backend fix can be implemented.

Alinator

I think he was talking about the 3 hour delay.

Good to see that the idea of increasing the size of a work unit was eventually taken on board. Making them smaller always seemed crazy when they are mostly completed so fast :)
____________

Should be even better now that the workunits should take around twice as long to crunch.

Huh. Making us work twice as slow eh? :p

Should be even better now that the workunits should take around twice as long to crunch.

Huh. Making us work twice as slow eh? :p

Ooh 2 seconds then.

Hey now, some of the GPU apps are taking a whole 3 seconds.

Should be even better now that the workunits should take around twice as long to crunch.

Should be even better now that the workunits should take around twice as long to crunch.

Wonderful, we've solved the problem of WU availability, but now you've effectively cut WU credits almost in half (for me) yet again!

Unless it's the same credits as the previous amount of work.
____________
Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

Should be even better now that the workunits should take around twice as long to crunch.

Wonderful, we've solved the problem of WU availability, but now you've effectively cut WU credits almost in half (for me) yet again!

but now you've effectively cut WU credits almost in half (for me) yet again!

I know have work on all computers and including the GPU where I was getting practically nothing.

Server-side, it looks like the change helped work availability quite a bit.

The only problem- and it's a big one- is when you have 'got 0 new tasks' multiple times in a row, which does still happen, and run dry and the reconnect time goes to 2 or 3 hours and you have nothing to crunch until then... any way to change/fix(?) that?

Travis, thanks for keeping my beasties fed.

-jim

My quady appears to be much happier now, as does my 2 * work C2D's and my old P4. I wouldn't have thought that decreasing the cached wu's per cpu would work, but this and extending the crunching time of the wu's appears to have done the job! Well done Travis.

I second the two previous posts. Thanks, Travis (also for the work you've done *before* visible success).
____________

My i7 is just fine, but my Core2Quad running on GPU is almost never running at its full potential. I usually only get 10 WUs when a request goes in, it crunches 8 in about 5-10 minutes, starts up two, gets a few more, maybe 8 more, sometimes 4, sometimes none. But at any rate, quite often today I've seen my system crunching 6 WUs and having none complete, so it made a request and just got nothing, or perhaps only 6. But I'm pretty positive its not had 24 WUs at any time today.

All running well here, thanks Travis

OK -- what I see is that this works ok *if* the only application running is Milkyway -- I'm doing that as a test on a batch of computers and it does work. However, if one is doing multiple projects (like I normally do), then the small cache tends to result in other projects *with lower resource shares* actually getting a larger proportion of CPU cycles because they have larger caches with similar due dates (examples in particular would be Spinhenge and Poem for me, but it also seems to apply to a lesser degree with SETI, Einstein, Rosetta). The only project which stays reasonable is Climate -- but that's because the due dates are so far out.

I know have work on all computers and including the GPU where I was getting practically nothing.

Server-side, it looks like the change helped work availability quite a bit.

Hey now, some of the GPU apps are taking a whole 3 seconds.

Hey now, some of the GPU apps are taking a whole 3 seconds.

Not really.
...<snip>...
Ice has posted already one result that took him mere 0.96 CPU seconds to crunch (but a bit more on the GPU of course).
...<snip>...
If you want we can skew the cpcs values (they are skewed anyway with GPU apps) on the stats sites with some creative timing ;)

CPU: Intel(R) Pentium(R) D CPU 2.80GHz (2 cores/threads) 2.79297 GHz (347ms)

CAL Runtime: 1.3.145
Found 1 CAL device

Device 0: ATI Radeon HD 4800 (RV770) 512 MB local RAM (remote 28 MB cached + 512 MB uncached)
GPU core clock: 680 MHz, memory clock: 750 MHz
800 shader units organized in 10 SIMDs with 16 VLIW units (5-issue)
supporting double precision

0 WUs already running on GPU 0
Starting WU on GPU 0
Calculated about 1.85078e+012 floatingpoint ops on GPU, 6.18221e+007 on FPU.
Calculated about 8.03964e+008 floatingpoint ops on FPU (stars).
WU completed. It took 0.953125 seconds CPU time and 25.528 seconds wall clock time @ 2.79307 GHz.

Thank you Travis for the other requested changes.

It looks like the changes you and Dave have made are keeping things going smoothly - at least from this end they seem to be. Crunchers are fully fed and have some morsels waiting to gnaw on.

I wonder if any of the GPU crunchers (nice RACs) are equally resplendent with the WU availability?