we continue on with our quest to find ET.

Hi Al

Why not find more ET's civilizations?
I rely believe we already find some interesting signals in this 20 Years of data.
The question could be: Are we intelligent enough to understand the signal?
Or we will be like an ant trying to decode a ET radio signal?

---

20 year of listening, and then stop it, and miss a call .. frustrating ! (:

---

Interesting that I am currently processing well over 200 WUs and getting 5 or 6 more everyday..

About one-half are GPU.

Looks like I will be crunching for a couple of weeks.

Just like the military. I made my 20 now I can retire.

---

Just I received some more workouts to crunk! Thank you.

---

Just like the military. I made my 20 now I can retire.

Rim snap on snare drum! :)

---

A proud member of the OFA (Old Farts Association).

Oh good it's not just me, I saw a bunch of GPU's turn up for crunching yesterday and now I'm working through them....at this rate I may actually make my 21 years!

---

Oh good it's not just me, I saw a bunch of GPU's turn up for crunching yesterday and now I'm working through them....at this rate I may actually make my 21 years!

. . It's good to see another Aussie hanging in there ... :)

Stephen

:)

Same here. Milkyway will just have to wait for GPU now while Rosetta chugs along on 4 cores. Maybe Rosetta will eventually stop complaining about "tasks not finishing in time" . ;-{D}

---

Same here. Milkyway will just have to wait for GPU now while Rosetta chugs along on 4 cores. Maybe Rosetta will eventually stop complaining about "tasks not finishing in time" . ;-{D}

Best cure for that is a small cache. More than 1 project, a very small cache.

   Other	
                                Store at least 0.4 days of work
                     Store up to an additional 0.02 days of work

---

Grant
Darwin NT

I don't understand how reducing cached WUs increases throughput.

Rosetta does not have a GPU version as far as I know so I monitor the best way I can.

I don't care how fast or soon Milkyway WUs are processed. I have a mix of CPU and GPU for Milkyway and GPUs were completing like you-know-what through a goose until I suspended the project to give S@h priority. Milkyway can wait. I don't care if those WUs drop off because of missed deadlines.

---

. . Sorry, if I seem I am dumb but someone posted a cc_config.xml app_config.xml entry to limit the CPU tasks being crunched per project. I can could not remember the syntax and I had scrolled back to the start of the month and did cannot find that message. I googled cc_config and got a nice long screed on parameters but could not find this parameter. BUT, when I googled app_config.xml there it was ... <project_max_concurrent>

. . Does anybody remember the syntax or where that message was?

Stephen

< D'oh!>

For projects like Rosetta that tend to rob CPU cores away from those driving GPU's create an app_config.xml with

<app_config>
 <project_max_concurrent>N</project_max_concurrent>
</app_config>

N being the number of tasks you want running at any time and drop it into the Rosetta project folder (or any other project that behaves in the same way).

Cheers.

For projects like Rosetta that tend to rob CPU cores away from those driving GPU's create an app_config.xml with

<app_config>
 <project_max_concurrent>N</project_max_concurrent>
</app_config>

N being the number of tasks you want running at any time and drop it into the Rosetta project folder (or any other project that behaves in the same way).
Cheers.

. . Thanks Wiggo ...

Stephen

:(

. . Sorry, if I seem I am dumb but someone posted a cc_config.xml app_config.xml entry to limit the CPU tasks being crunched per project. I can could not remember the syntax and I had scrolled back to the start of the month and did cannot find that message. I googled cc_config and got a nice long screed on parameters but could not find this parameter. BUT, when I googled app_config.xml there it was ... <project_max_concurrent>

. . Does anybody remember the syntax or where that message was?

<app_config>
 <app>
  <name>setiathome_v8</name>
  <gpu_versions>
  <gpu_usage>1.0</gpu_usage>
  <cpu_usage>1.0</cpu_usage>
  </gpu_versions>
 </app>
 <app>
  <name>astropulse_v7</name>
  <gpu_versions>
  <gpu_usage>1.0</gpu_usage>
  <cpu_usage>1.0</cpu_usage>
  </gpu_versions>
 </app>
</app_config>

Works for me.
If the GPU is running, it gets a CPU core. If not, the core does CPU work.

---

Grant
Darwin NT

Works for me.
If the GPU is running, it gets a CPU core. If not, the core does CPU work.

Thanks Grant.

Stephen

:)

Thank you for the memories... I hope we find something that will alter our perception of ourselves.

---

I don't understand how reducing cached WUs increases throughput.

It doesn't. It just helps your CPU work on most up-to-date tasks. If you have a pool of 20 days of work units, whenever your PC actually starts crunching a new one, it has been sitting on the queue for 20 days, and thus it's aged 20 days. If you have a queue of 0 days, you start with a fresh work unit all the time.

---

Anyone else just get a flood of units? My 8 core system is full of them currently. Most start with "16mr20ae.XXX" there is also a "blc64_2bit_guppi_XXX" and "ap_24mr20XXX" unit

---

Historian for the Defunct Riviera Hotel and Casino, Former Classic Seti@home user for Team Art Bell. Greetings from the High Desert!

Anyone else just get a flood of units? My 8 core system is full of them currently. Most start with "16mr20ae.XXX" there is also a "blc64_2bit_guppi_XXX" and "ap_24mr20XXX" unit

They appear to be sending all WUs that were rattling around unfinished to a 3rd person early in hopes of all WUs having a valid match sooner.