RNA World

[gopher_yarrowzoo]

Angus "Not trying to get pissy here...." Oh really I think you are again.
Now this project is still in TEST phase and thus short / long WU's will occur they need to test server load and balancing..
What has WU Length got to do with ANYTHING anyway apart from wasting time waiting on the next one...
Like Micheal has suggested paralleling it with other stuff, so maybe you should do just that and relax a little!

[Angus]

Angus "Not trying to get pissy here...." Oh really I think you are again.
Now this project is still in TEST phase and thus short / long WU's will occur they need to test server load and balancing..
What has WU Length got to do with ANYTHING anyway apart from wasting time waiting on the next one...
Like Micheal has suggested paralleling it with other stuff, so maybe you should do just that and relax a little!

I was trying to make a response to zombie67's snarky comment about not reading another post that was unrelated to my question about WHY the WUs were so short.

As for being a "test" or "alpha" or "beta" project, that would be most BOINC projects.
Only 8 have identified themselves as "Production" projects. Project status


Also, both Michael and Yoyo have been around BOINC long enough to understand that releasing 300,000 very tiny WUs will swamp their server. Anyone who has tested with 'uppercase' exposed to the public has seen that behavior.

So, indeed, WU length has everything to do with how busy the server and database will be.

[zombie67]

I was trying to make a response to zombie67's snarky comment about not reading another post that was unrelated to my question about WHY the WUs were so short.

My post had nothing to do with your "why" question. It was purely a response to your bitching about the short WUs. You acted surprised and "insulted" that you were getting short WUs. If you had read the previous posts before posting, you would have known that they were aware already of the problem and working on implementing a solution.

[gopher_yarrowzoo]

My post had nothing to do with your "why" question. It was purely a response to your bitching about the short WUs. You acted surprised and "insulted" that you were getting short WUs. If you had read the previous posts before posting, you would have known that they were aware already of the problem and working on implementing a solution.

Zombie, IMHO sometimes is not worth trying to explain stuff to people if you don't give them the answer they expect see it all the time in my line of work...

Reminds me I really should pop over to your forum and say hi again

[Michael H.W. Weber]

So, indeed, WU length has everything to do with how busy the server and database will be.

Indeed. But it is a big difference between just knowing this and measuring the exact impact on your own machine in practice. And that's just what we did.

Michael.

[LAURENU2]

Well I hope you got the the exact impact on your own machine in practice I know I did
I never did see so many blinking lights before except for Jeff's X Mass display
By the way he is better at it then you Jeff's lights

[Bigred]

I'm glad somebody is getting some work because I sure ain't.

[LAURENU2]

I'm glad somebody is getting some work because I sure ain't.

Like I said

But I have noticed that RNA on some Nodes Runs like a weak puppy
and lets other projects eat up most of the power

When run with other projects you sometimes have to make the client get work by kicking the Update button
RNA seems to want to go to sleep if there is no work sent for a bit

[Michael H.W. Weber]

RNA seems to want to go to sleep if there is no work sent for a bit

The project should actually check every 20 minutes for work.

Maybe you have noticed that the average CMS run times now slightly increase. My 955 BE does not spend only a few seconds on the WUs but up to 15 minutes. This should persist for the remaining WUs that are still in the pipeline.
Concerning the two Linux x64 WU packets, around 35 and 63 very long WUs remain to be completed. After that we will have plenty of work to do at all ends.

Michael.