I have been getting the same messages over and over again, please help me figure out what I am doing wrong?
2/4/2006 7:49:11 AM|climateprediction.net|Note: not requesting new work or reporting results
2/4/2006 7:49:16 AM|climateprediction.net|Scheduler request to http://climateapps2.oucs.ox.ac.uk/cpdnboinc_cgi/cgi succeeded
2/4/2006 8:28:47 AM|climateprediction.net|Sending scheduler request to http://climateapps2.oucs.ox.ac.uk/cpdnboinc_cgi/cgi
2/4/2006 8:28:47 AM|climateprediction.net|Reason: To send trickle-up message
2/4/2006 8:28:47 AM|climateprediction.net|Note: not requesting new work or reporting results
2/4/2006 8:28:52 AM|climateprediction.net|Scheduler request to http://climateapps2.oucs.ox.ac.uk/cpdnboinc_cgi/cgi succeeded
2/4/2006 1:50:38 PM||Suspending computation and network activity - user request
2/4/2006 1:50:38 PM|climateprediction.net|Pausing result sulphur_ij2a_100864514_0 (removed from memory)
2/4/2006 1:50:38 PM|climateprediction.net|Pausing result sulphur_iige_100863726_0 (removed from memory)
2/4/2006 1:50:41 PM||request_reschedule_cpus: process exited
2/4/2006 1:50:42 PM||Running CPU benchmarks
2/4/2006 1:50:42 PM||Suspending network activity - user request
2/4/2006 1:51:41 PM||Benchmark results:
2/4/2006 1:51:41 PM|| Number of CPUs: 2
2/4/2006 1:51:41 PM|| 1298 double precision MIPS (Whetstone) per CPU
2/4/2006 1:51:41 PM|| 1382 integer MIPS (Dhrystone) per CPU
2/4/2006 1:51:41 PM||Finished CPU benchmarks
2/4/2006 2:49:43 PM||Resuming computation and network activity
2/4/2006 2:49:43 PM||request_reschedule_cpus: Resuming activities
2/4/2006 2:49:43 PM|climateprediction.net|Restarting result sulphur_ij2a_100864514_0 using sulphur_cycle version 422
2/4/2006 2:49:43 PM|climateprediction.net|Restarting result sulphur_iige_100863726_0 using sulphur_cycle version 422
2/4/2006 2:49:45 PM||Resuming network activity
2/4/2006 2:49:45 PM|climateprediction.net|Sending scheduler request to http://climateapps2.oucs.ox.ac.uk/cpdnboinc_cgi/cgi
2/4/2006 2:49:45 PM|climateprediction.net|Reason: To send trickle-up message
2/4/2006 2:49:45 PM|climateprediction.net|Note: not requesting new work or reporting results
2/4/2006 2:49:50 PM|climateprediction.net|Scheduler request to http://climateapps2.oucs.ox.ac.uk/cpdnboinc_cgi/cgi succeeded
2/5/2006 1:53:18 AM|climateprediction.net|Sending scheduler request to http://climateapps2.oucs.ox.ac.uk/cpdnboinc_cgi/cgi
2/5/2006 1:53:18 AM|climateprediction.net|Reason: To send trickle-up message
2/5/2006 1:53:18 AM|climateprediction.net|Note: not requesting new work or reporting results
2/5/2006 1:53:23 AM|climateprediction.net|Scheduler request to http://climateapps2.oucs.ox.ac.uk/cpdnboinc_cgi/cgi succeeded
2/5/2006 2:24:59 AM|climateprediction.net|Sending scheduler request to http://climateapps2.oucs.ox.ac.uk/cpdnboinc_cgi/cgi
2/5/2006 2:24:59 AM|climateprediction.net|Reason: To send trickle-up message
2/5/2006 2:24:59 AM|climateprediction.net|Note: not requesting new work or reporting results
2/5/2006 2:25:04 AM|climateprediction.net|Scheduler request to http://climateapps2.oucs.ox.ac.uk/cpdnboinc_cgi/cgi succeeded
2/5/2006 4:19:12 PM|climateprediction.net|Sending scheduler request to http://climateapps2.oucs.ox.ac.uk/cpdnboinc_cgi/cgi
2/5/2006 4:19:12 PM|climateprediction.net|Reason: To send trickle-up message
2/5/2006 4:19:12 PM|climateprediction.net|Note: not requesting new work or reporting results
2/5/2006 4:19:17 PM|climateprediction.net|Scheduler request to http://climateapps2.oucs.ox.ac.uk/cpdnboinc_cgi/cgi succeeded
2/5/2006 4:46:18 PM|climateprediction.net|Sending scheduler request to http://climateapps2.oucs.ox.ac.uk/cpdnboinc_cgi/cgi
2/5/2006 4:46:18 PM|climateprediction.net|Reason: To send trickle-up message
2/5/2006 4:46:18 PM|climateprediction.net|Note: not requesting new work or reporting results
2/5/2006 4:46:23 PM|climateprediction.net|Scheduler request to http://climateapps2.oucs.ox.ac.uk/cpdnboinc_cgi/cgi succeeded

---

It looks like everything is going pretty well. Your PC has a processor with HyperThreading, which means it can run two models at once, which it is doing. At the speed it is running, each model will \"trickle\" once or twice a day. A trickle occurs every 10802 timesteps and you receive 160 credits for each one. It is basically a way to obtain intermediate credit, and let the server know that progress is occuring on those work units.

You can see the two work units/models you are running here and looking at each ResultID, you can see the trickles link which has a listing of them.

You\'re not doing anything wrong. These are just normal, routine, BOINC messages.

Trickle_ups: \"Hullo server. I\'m still alive and running, and I\'m up to x,y,z of the processing\".
You get partial credits each time you get to one of these. NOTE: Credit is NOT instant in your Account page.)

Benchmarks. Not used by this project, but it tells the project how fast your computer can crunch. Occurs every 5 days.

edit
Already explained. Oh, well.

You\'re not doing anything wrong. These are just normal, routine, BOINC messages.

Trickle_ups: \"Hullo server. I\'m still alive and running, and I\'m up to x,y,z of the processing\".
You get partial credits each time you get to one of these. NOTE: Credit is NOT instant in your Account page.)

I think what this person might be saying is that he\'s getting the trickle up message a lot more frequently then he should be.

Trickle-up message should be every ~10k timesteps, but I get the message far more frequently then that. Perhaps it\'s a bug with cpdn, or perhaps it\'s a bug with the boinc client. I am using an optimized version of the v5.2.13 client compiled by crunch3r.

Thanks for your help!

---

John
Your trickle list seems OK, but what you could try, is Suspend, (in the menu), wait until it is suspended, then Exit, (in the menu).
Then power down, and power up again.

Also, your list says: (removed from memory) just before the benchmark.
It\'s best on this project if you set your prefs for \'leave in memory\' to Yes.
It fixs several things, but I\'ve forgotten what they are.

uioped1
I can\'t help with optimised BOINCs, as there are so many, and not enough people posting with problems when they use them, to get a feel for what may be wrong.

But my feeling on excess trickles, is that if they don\'t cause problems, don\'t worry.
You could try \'Disable network access\' for a few hours/days, to accumulate a few trickle_up files in the model\'s folder, and then have a look at them with notepad.
There\'s not much info in them, so comparing them isn\'t hard.
Main thing to look at would be the timestep, to see if it increments by a fixed amount, or if you have files with duplicate entries.
The server ignores trickles with timesteps that it has already received, which is why I said not to worry.

Please post back here with what you find out.

Main thing to look at would be the timestep, to see if it increments by a fixed amount, or if you have files with duplicate entries.

Please post back here with what you find out.

I have done some testing, and it seems that every time the result is resumed after being removed from memory, it sends a trickle. The trickle does not use the current timestep of the model, but rather the last multiple of 10802 sent. The trickle also contains the message \"<csf>restart.day</csf>\". I do not have a copy of a regularly scheduled trickle to compare with, so I don\'t know if that is expected.

It seems that removing the wu from memory (e.g. when boinc shuts down, or if you do not have \'Leave applications in memory while preempted?\' selected) cpdn does not write a checkpoint, and so restarts from the last checkpoint. It is possible that this symptom is caused by the resuming from a non-paged app, or it is caused by the act of resuming from a model not in memory.

You are correct in your assertion that extra trickles will not cause a problem, however this may point to a more subtle bug.

The wasted cpu cycles caused by the model reverting to the last checkpoint are not great. On average (checkpointing every 3 days, divided by 2) 72 timesteps are wasted. For my pc, I estimate that that amounts to about 5 minutes every 4 hours of work, or a 2% loss. That\'s not terribly significant, but over the life of a model that\'s almost a day. I\'m going to post this under feature requests.

---

Save points, known in BOINC as checkpoints, are hardwired into the CPDN program, and in current models occur every 6 model days. There is no ability to create intermediate save points. If an application is removed from memory it necessarily has to restart from the last save point, known in the CPDN program as as restart day (because it has the ability, if necessary, to go back to a previous month or year). There is mare about BOINC checkpointing here.

---

Save points, known in BOINC as checkpoints, are hardwired into the CPDN program, and in current models occur every 6 model days. There is no ability to create intermediate save points. If an application is removed from memory it necessarily has to restart from the last save point, known in the CPDN program as as restart day (because it has the ability, if necessary, to go back to a previous month or year). There is mare about BOINC checkpointing here.

Thanks for the info.

---