finally, after i bitch, i get 22 wu's in one request.

---

I recommend Secunia PSI: http://secunia.com/vulnerability_scanning/personal/

We've had server outages and some workunit problems so i'm not sure if thats representative of the situation.

I guess only time will tell. Give it a few days -

Don't get me wrong, I am not complaining, just making an observation.

my prediction is a drop. Of course I have been wrong before, and hope that I am wrong this time.

But just as before - when the server crashed a month or so ago, there was a decline in the amount of work completed as depicted below on weekly average.

Anytime you add daemons that the server must execute, it will have an impact on performance.

My daily production has remained nearly constant, only decreased recently because I have taken all my CPU's off the project, and lost 4 ATI cards.






However, you will notice that from the 16th to the 21st - around the other server outtage.. there was a slight production increase...

I didn't add any daemons and the server isn't really doing anything it wasn't before. Previously the server wouldn't respond with work if a request was made within 6 seconds, I changed the 6 to 60.

---

Keep in mind 3 things happened:

1) There was a minor server outage

2) The request was changed from 6 to 60 seconds

3) The very small ps_sgr_208_* runs

My humble opinion is that the "ps_sgr_208_*" runs is the culprit causing an increase to the network traffic because of its very short run-time

---

A BLAST FROM YOUR PAST

Can't get any tasks from MW today. :(

Why not make it 120? 600, 6000...
At what point would faster CPU's start starving under normal conditions. I'm not worried about GPU burning through tasks in seconds as this is the CPU project. Would it not be a good idea to shift work toward CPU hosts being able to pick them up, at the expense that gpu can't get new tasks every minute?

My understanding is server connot distiguish cpu/gpu app with current layout. So to stop GPU cruching on main entire new app would be required. This is why GPU tasks not receive credit here when GPU project go live.

---

I tend to think that work requests are being dropped somewhere at the MW end. I changed my resource share and it says the next time you hit update it will update the numbers in BOINC Manager - which didn't occur on the next update, nor the next, nor the next. After about 20 minutes it updated....

Can't get any tasks from MW today. :(

Why not make it 120? 600, 6000...
At what point would faster CPU's start starving under normal conditions. I'm not worried about GPU burning through tasks in seconds as this is the CPU project. Would it not be a good idea to shift work toward CPU hosts being able to pick them up, at the expense that gpu can't get new tasks every minute?

My understanding is server connot distiguish cpu/gpu app with current layout. So to stop GPU cruching on main entire new app would be required. This is why GPU tasks not receive credit here when GPU project go live.

This is not a CPU only project. Once the projects are split then yes, it will be but as it sits right now it is not.

I have run both CPU and GPU so it makes little difference but why would you want to starve the higher processing power computers. Makes no sense at all from a project stand point to "starve" the faster hosts just so the slower ones can get work and basically slow down the entire process of the project.


** EDIT **
@@@@@ - I did a quick check on your hosts. not entirely true about you not getting "any" work today. You have a downloaded several on the hosts that you have attached. Currently you have a cache of un-crunched work on
http://milkyway.cs.rpi.edu/milkyway/results.php?hostid=75164

---

.

Can we maybe stop the GPU vs. CPU snipping, please, and keep the focus on server efficiency and performance? We understand the GPU-CPU differences of opinion, and IMO that "discussion" is at a stalemate.

Thank you.

---

--Bill

Can we maybe stop the GPU vs. CPU snipping, please, and keep the focus on server efficiency and performance? We understand the GPU-CPU differences of opinion, and IMO that "discussion" is at a stalemate.

Thank you.

Agreed!!!!

However, What about those like me that run both, can I fight amongst myself :)

---

.

I tend to think that work requests are being dropped somewhere at the MW end. I changed my resource share and it says the next time you hit update it will update the numbers in BOINC Manager - which didn't occur on the next update, nor the next, nor the next. After about 20 minutes it updated....

That's because one of the changes they made to the standard BOINC scheduler is that if a request comes in and there is no work in the scheduler local queue, no DB query is issued.

It only happens now if an assignment is actually made or a task is reported.

Alinator

<snip>

My understanding is server connot distiguish cpu/gpu app with current layout. So to stop GPU cruching on main entire new app would be required. This is why GPU tasks not receive credit here when GPU project go live.

No, you don't have to release new apps per se, all you have to do is not allow the anonymous platform.

That being said, it would probably be wise to make an update for all the supported platforms to incorporate everything which has been done so far before doing that.

Alinator

I tend to think that work requests are being dropped somewhere at the MW end. I changed my resource share and it says the next time you hit update it will update the numbers in BOINC Manager - which didn't occur on the next update, nor the next, nor the next. After about 20 minutes it updated....

That's because one of the changes they made to the standard BOINC scheduler is that if a request comes in and there is no work in the scheduler local queue, no DB query is issued.

It only happens now if an assignment is actually made or a task is reported.

Alinator

Curious when the scheduler was changed ... as this has been happening on my end for weeks.

My guess is that was part of the work they did back when they integrated the assimilator and work generator.

It just never made a difference until the advent of the GPU apps to be noticed unless you were really looking for it.

Alinator

No CPUvsGPU debate here. 99% of my credits come from GPU. I was mearly offering a suggestion which would increase project throughput by lowering server demand. While at the same time still serving all the workunits it can. It would then be a more even distribution of work among volunteers. Not the stark division between haves and have-not's that exists now.

*returns to his quiet corner*

---

While you are waiting on the never ending story of ATI suport under BOINC you can always join Folding@home

Tomas

That is if they were not the bastard of the BOINC world.
They are words that I cannot type here. Needless to say, anyone that knows F@H history refuse to run it.

---

Since the last change on the server my RAC is dropping by over 30%. My Linux machine got not one WU today since now, my GPU card drops from 72% work time to under 50%. It seems, only the cheater with a patched application, that notifies more cores than they really have, have a advantage. The other get much less work than before.

---

they dont - lost over 50%

Since the last change on the server my RAC is dropping by over 30%. My Linux machine got not one WU today since now, my GPU card drops from 72% work time to under 50%. It seems, only the cheater with a patched application, that notifies more cores than they really have, have a advantage. The other get much less work than before.

Part of the issue has been the server being down and new people starting searches up that have WUs smaller than they should be. We have most things ironed out now so it should be better the next few days.

---

Anyone else notice that the WUs in process shown on the server status page has dropped from 36K to 30K ever since increasing the wait period from 7 to 60 seconds?

Prior to the optimized apps (CPU and ATI), there were as many as 150,000 to 200,000 in process at a time if I remember right. If that's the case, it seems to me that UP is the direction to be headed and that the recent change made it go DOWN instead.

Anyone else notice that the WUs in process shown on the server status page has dropped from 36K to 30K ever since increasing the wait period from 7 to 60 seconds?

Prior to the optimized apps (CPU and ATI), there were as many as 150,000 to 200,000 in process at a time if I remember right. If that's the case, it seems to me that UP is the direction to be headed and that the recent change made it go DOWN instead.

Well part of the reason there were so many in progress before was there was a 20 WU per core limit, and now it's down around 6.

---

since the last 2 or 3 days now, I'm getting a little more WUs

the idling time of my ATIs is shorter now.

...

I'm surprised this 1 min setting has an impact.
It means a lot of scripters were refreshing more than once in a minute...