Hello Sekerob,

I'm running both applications in BOINC (one for each CPU). Yes, I think it's already time to add more memory, :-).

---

The disk swapping (to and from page file) will interfere with Winamp, and it doesn't matter which drive Winamp is then reading from.

With the Cancer app using 350+ (to 715.26) Megabytes of memory a LOT of memory is the best course. :)

---

Sekerob,

I have another question. I got these two inconclusive results in one day. These are results for the HPF2 application of WCG. Won't I get any credit for these two? What a waste of time, :-)...



BETA_ za297_ 00175 POWER Inconclusive 12/05/2006 03:17:10 12/05/2006 08:51:38 3.08 29 / 0

BETA_ za297_ 00166 POWER Inconclusive 12/05/2006 00:10:33 12/05/2006 03:28:29 2.85 27 / 0

---

The disk swapping (to and from page file) will interfere with Winamp, and it doesn't matter which drive Winamp is then reading from.

With the Cancer app using 350+ (to 715.26) Megabytes of memory a LOT of memory is the best course. :)

Thanks! So adding memory is the only way to go. Anyway, I forgot to mention that the page file, Winamp, and BOINC are residing in my three different SATA drives. Wow, HDC is really that demanding!

Again, thanks!

---

Thanks! So adding memory is the only way to go. Anyway, I forgot to mention that the page file, Winamp, and BOINC are residing in my three different SATA drives. Wow, HDC is really that demanding!

It really is.

Windows, Winamp, BOINC are all residing in memory. The moment that your memory is so far gone that Windows switches to the page file, a lot of read write operations are done by either CPU (or both). And since all write operations are done by the CPU (through an interrupt), this interferes with whatever is in memory at the time. Especially when you are running two of those HDCs and both are maxing out at the top number of 715MB. You'll probably then see your page file grow exponentially.

---

Thanks! So adding memory is the only way to go. Anyway, I forgot to mention that the page file, Winamp, and BOINC are residing in my three different SATA drives. Wow, HDC is really that demanding!

It really is.

Windows, Winamp, BOINC are all residing in memory. The moment that your memory is so far gone that Windows switches to the page file, a lot of read write operations are done by either CPU (or both). And since all write operations are done by the CPU (through an interrupt), this interferes with whatever is in memory at the time. Especially when you are running two of those HDCs and both are maxing out at the top number of 715MB. You'll probably then see your page file grow exponentially.

I changed the checkpoint time of the application to 900 sec. Everything seems fine now but I know this is only a temporary solution, :-). Thanks for all the help!

---

I just upgraded to 5.7.5 on Mac OSX Intel Core Duo.
I notice one change from the previous version: the time to completion for waiting WU's keeps increasing and is now nearly twice what the actual times are. In the previous version, these times would be gradually decreasing, approaching the actual times.

What project(s)?

Do your benchmarks look ok? (Although I'm not sure if bad benchmarks would impact time to completion not counting down.)

The Benchmarks are fine. For SETI, A WU with an estimated completion time of 5:16 actually takes 2:18. This time has not changed in the last 4 days. The result is that the queue of waiting WU's is about half as long as it should be and occassionally, when a shorter WU is downloaded, the program goes into "computer overloaded" mode and preempts the running WU and starts the newly-arrived short WU.

The project is SETI running at 95% priority and Einstein at 5% priority. Einstein is affected somewhat less with the estimated time being 1:09 and the actual time being 0:40. I am running the "stock" worker on Einstein and a "modified" (30% speedup) version on SETI.

---

[quote]I just upgraded to 5.7.5 on Mac OSX Intel Core Duo.
I notice one change from the previous version: the time to completion for waiting WU's keeps increasing and is now nearly twice what the actual times are. In the previous version, these times would be gradually decreasing, approaching the actual times.[/quote

U dont say which project u run... The WU's send have a Time To Complete estimate in it based on a guess value of flops. If the machine getting the work is slower, the time will increase rather than decrease. Also some sciences are not rectilinear.... if it takes many attempts on a section to find the optimal, it will too increase the expected completion time.

Seen this in 5.2, 5.4, 5.6 and 5.7.... nothing new.. rather i dare say the latest are closer to predicting completion times once they've been running a WU for a wee while.

Oh and waiting WU's of the same project/science do move with the time a specifics project WU actually progresses. It tends to go up quicker than down, to prevent any over commitment in the total task queue. The BOiNC requires a long time of calibration and settling.... just let it do its job.

This is running SETI primarily (95%). It has been about 4 days and no change. It affects the length of the queue of WU's and occassionally if a shorter WU is downloaded, there is a change to the "over commited" mode and that WU is processed immediately rather than waiting in the queue. I am using Alex Kan's modified worker on SETI.

---

@Billy.

I need some data from you.


On each of your projects, go to "Your account" (log in if you aren't already), "computers on this account". Click on the computer name that you're having trouble with. Post the numbers at the bottom of the page for % time client is running, % time work allowed, average cpu efficiency, and duration correction factor.


Mine look like this for Einstein:

% of time BOINC client is running 82.2459 %
While BOINC running, % of time work is allowed 66.6027 %
Average CPU efficiency 0.463772
Result duration correction factor 0.606095


These are not really representative of what a computer that runs 24/7 would look like as I use the CPU throttling and it was off for quite a while a week or so ago.

---

Kathryn :o)

@KSMarksPsych

I believe all the requested values are stored by-project in the client_state.xml. For WCG u'd have to go there as there is no equivalent there.

True. They are stored there, just a bit harder to find.

And he's running Seti and Einstein so no problem there.

---

Kathryn :o)

5.7.5 was running fine with 10 different projects. I added Seti Beta and it crashes asking for a dump file. 5.7.5 then goes crazy with all WU's aborting within 1 minute of running. Some get a message "waiting for memory" then abort the go to "ready to report". Only way to stop was to reboot, uninstall and reinstall 5.4.11. I did that and ALL projects ran fine for 2 days. Put 5.7.5 back on and again it ran fine until Seti Beta started.

anyone else seen this?

gone back to 5.4.1 until new version.

Shane

---

For everyone running a 5.7.x version who runs into problems, please use CC_Config.xml to add options for BOINC to log to stderrdae.txt. These files can be sent directly to the developers (David Anderson, Rom walton) if you have their email address, or to Kathryn or me (KSMarksPsych at yahoo dot com or elst93 at gmail dot com). Make sure you ZIP/7Zip/RAR the file before sending it.

To use cc_config.xml:
This file needs to be added to the BOINC directory, defaulting at C:\\Program Files\\BOINC. When you add it or edit it, always first exit BOINC.

To add it:
Open Notepad (or a similar plain text editor for your OS).
Copy these entries into it;

<cc_config>
<log_flags>
<task>1</task>
<file_xfer>1</file_xfer>
<sched_ops>1</sched_ops>
<cpu_sched>0</cpu_sched>
<cpu_sched_debug>0</cpu_sched_debug>
<rr_simulation>0</rr_simulation>
<debt_debug>0</debt_debug>
<task_debug>0</task_debug>
<work_fetch_debug>0</work_fetch_debug>
<unparsed_xml>0</unparsed_xml>
<state_debug>0</state_debug>
<file_xfer_debug>0</file_xfer_debug>
<sched_op_debug>0</sched_op_debug>
<http_debug>0</http_debug>
<proxy_debug>0</proxy_debug>
<time_debug>0</time_debug>
<http_xfer_debug>0</http_xfer_debug>
<measurement_debug>0</measurement_debug>
<poll_debug>0</poll_debug>
<guirpc_debug>0</guirpc_debug>
<scrsave_debug>0</scrsave_debug>
<app_msg_send>0</app_msg_send>
<app_msg_receive>0</app_msg_receive>
<mem_usage_debug>0</mem_usage_debug>
<network_status_debug>0</network_status_debug>
</log_flags>
</cc_config>

The ones that are on by default are the three at the top. Leave these on.

Save this file as cc_config.xml to your BOINC directory. Make sure (double check) that you saved it with without a txt extension (In Notepad, Save As..., make sure you have the Save as Type set to All Files), else rename the file. .

To debug memory messages, please change these lines in the file:
<app_msg_send>0</app_msg_send>
<app_msg_receive>0</app_msg_receive>

to

<app_msg_send>1</app_msg_send>
<app_msg_receive>1</app_msg_receive>

(Whenever you set an option to on, change the 0 to 1. To shut it down, change the 1 to 0. Don't forget to save the file after you made changes).

Restart BOINC. Wait for your error to happen.
Exit BOINC. Zip your stderrdae.txt file and send it to us.
Restart BOINC.

You'll be helping us to make BOINC better. Just moving back to an older version of BOINC isn't going to help anyone.

If you want to know what all options in the cc_config.xml file mean, ask here, or check the cc_config help page.

I have upgraded to 5.7.5 again. I put in the cc_config.xml and we will see what happens. We will offer up any problems that are encountered.

---

Thank you, Shane. :)

---

I just tried to install the 5.8.0 beta code for Windows on my machine running Windows XP SP2. I am getting an error during the install proces that says "internal error 2721 CAValidatesetup".

---

I just tried to install the 5.8.0 beta code for Windows on my machine running Windows XP SP2. I am getting an error during the install proces that says "internal error 2721 CAValidatesetup".

We all do, so no need to further test it as far as I can see.
Wait for Rom's next message. I think the whole file isn't there, as it's advertised as 8.7MB, but it's only 6.7MB

---

Just installed 5.7.5 Linux on my ubuntu 6.10 host and I ran into a problem...

Seti wu's ran for a couple of seconds and then got the "waiting for memory" status.
After those wu's were all "waiting.." the Docking@home wu kicked in and started and ran with no problems.

Tried 2 options:
run_manager
run_manager with added first line "ulimit -s unlimited"
(The 'ulimit' line is needed by Docking to fix the "error -1")

Both options gave the same result, have 5.4.11 running now on this host and all seems well.

Besides that 5.7.5 (linux) looks really nice.

Rene

edit:

Host: (seti) 2598480
app: Linux SSE 32-bit V5.15 'Chicken Good!' (R1.1|+kwsn|xK)

---

Seti wu's ran for a couple of seconds and then got the "waiting for memory" status.

When you check the Seti general preferences you'll see there are some extra memory prefs to fill in.

Use at most 50% of memory when computer is in use
Use at most 90% of memory when computer is idle

Play with those. You've probably got them at a low percentage.
I haven't a clue what their default entries are.

---

Thanks Jord and Sekerob...!!!

Just looked and found it here:

Disk and memory usage
....
Use at most 50% of memory when computer is in use
Use at most 90% of memory when computer is idle

I will increase the "in use" value.

;-)

---

This morning I've updated my boinc prefs and set "in use" to 90%.

5.7.5 Linux is running now on my Athlon and all seems fine.
I really like the new GUI, prior to 5.7.5 I had problems with showing some (dutch) translated phrases, but they all are correct now.

Job well done.

;-)

---