1. From an earlier posting: " If you run a batch of slow tasks, APR will fall, estimated runtime will rise, and your machine will fetch work less often because it'll think that the cache is fuller. Anonymous platform machines will fetch work more steadily, because the runtime estimate is fixed (by the task size tweak) when the work is first allocated, and doesn't change thereafter."

Maybe that's why my RAC has fallen lately? I suspended Asteroids, which runs concurrently with S@H, hoping that would make it better.

Since POGS is finished and is no longer being processed with the others, and with Asteroids temporarily suspended, I thought S@H would go much faster and my RAC would get a boost. That hasn't happened. In fact, my RAC has gotten even lower.

WTF?

2. Why do VLAR units take longer and/or make the processor work harder?

I appreciate the patience and forbearance you guys have shown with my lame questions.

Steve Gaber
Oldsmar, Florida

Since POGS is finished and is no longer being processed with the others, and with Asteroids temporarily suspended, I thought S@H would go much faster and my RAC would get a boost. That hasn't happened. In fact, my RAC has gotten even lower.

WTF?

Seti uses Credit New, the official BOINC system for granting Credit. It doesn't work as intended (actually, it's totally borked- see the numerous threads on the topic). Most other projects that use Credit New have put in various tweaks or scaling factors to significantly boost the amount of Credit their work receives. And others just ignore Credit New & payout whatever they feel like paying out.

2. Why do VLAR units take longer and/or make the processor work harder?

When it comes to CPUs, the Credit payout for VLARs is proportional to the payout for VHARs. The VLARs take longer to process & they end up with more Credit.
What makes GPUs so much faster at processing VHAR WUs, makes them slower at processing VLAR WUs- particularly NVidia GPUs. Considerable optimisation has been done with the SoG application in regards to GBT (Green Bank Telescope) work and the crunching time for most of them is close to on par with higher mid-range to longer running Arecibo WUs. However when it comes to Arecibo VLARs, they have only recently been released to GPUs, and there has been no work at optimising the code to improve their crunching times. They tend to take twice as long as normal Arecibo/GBT tasks but aare worth the same amount of Credit.
Running an optimised application on the CPU, and making use of command line values for the GPU (stock uses the optimised GPU version) will significantly improve work output over the stock application/settings.

---

Grant
Darwin NT