...
<snip>

4/18/2008 9:08:12 AM|climateprediction.net|Message from server: Project encountered internal error: shared memory

Why shared memory should be a problem I don\'t know.
</snip>
...

Or change Sent to Received.

<snip>
Ergo, I reckon that what we\'re seeing is a timestamp in the server\'s local (Oxford or Milton Keynes) wall-clock time. If someone can match up their message log \'trickle-up\' entries with trickle timestamps, we could even work out where the server is (Oxford\'s are properly sychronised with an NTP time server: Milton Keynes, notoriously, is not, and the php board is currently about seven minutes slow).
</snip>

...
My hardware ran Einstein@home just fine, but with these climate models I have had some equipment freezes (but no ice world freezes, thank goodness! ;), and have had to throttle back my overclocking several times. The freezes are less and less frequent with each throttle back, and hopefully my latest larger throttle back will work on a long-term basis! ;)

For overclocking, I\'d recommend a full 24 hours of Prime95 before running the climate model (one copy running for each core you have - so on a quad core you\'d have 4 copies, using -A0, -A1, -A2, and -A3). It took a lot of work before I could get my Q6600 working properly overclocked.

I just had a huge jump in RAC, so they must have processed my trickles and zip files last night. :)

After I merged two computer id\'s for the same CPU, I noticed CPDN now thinks I\'m not sending up trickles. My log says I am. It looks like the client may be using the old computer id. Restarting the client doesn\'t fix it.
Two questions: is there a way to get the client to use the new computer id? And will the \"lack\" of trickles cause CPDN to do something like give the same WU to someone else?

==Mike

I\'ve run my 80yr coupled model to within 3hrs of completion and, with the end of the week coming, I wondered how things were getting on and whether it is deemed safe now to send the final trickle and result upload zips?

Ok thanks, since I\'m running various projects, suspending the task is the better option here although I did suspend network activity for a couple of days last week when the server probs were at their worst. Indeed I also backed up the model at 98% to protect the final lunge to the finish post.

I can see there is still quite a delay before trickles are showing in the model results. Keep us posted with Milo\'s progress - we\'re all cheering him on.

/pg

The trickle server was one of two that had filled up, so it may take a while for trickles to appear on accounts.
As long as the upload message was followed by a \"succeeded\" message, everything will be fine.

my 80yr coupled model is running fine, under a week away from finishing. I\'m just slightly curious at noticing on the full trickles results page that the seconds per timestep (s/TS) is gradually slowing down throughout the model. It started at abt 3.4s/TS then settled around 3.79s/TS for much of the long haul and during the last month it has slipped further to 3.96s/TS.

do models typically slow up slightly or could my pc have built up sludge processes using up crunching resources? I\'m not very tecchie about \'looking under the hood\'... lol

for the power of my pc it also seems a bit slower than others who typically report speeds under 3s/TS.

I\'ve opened the gate and let a new model download (a 160yr one this time) and run in the other core; it\'s kicked out the other projects and started crunching - probably some long term debt on cpdn. This is going a similar speed to the old 80yr model - currently 3.98s/TS.

When I\'m overclocking I use 24 hours of Prime95 (one per core). My Q6600 took a lot to get it completely stable, it had to go down a long way from being \'nearly stable\' to being \'entirely stable\'. The AMDs I\'ve overclocked were much easier, since the grey area between stable and unstable was much narrower.

Fred,

Your Quad had 37 Models. As best I can tell, two short Runs of that lot completed successfully. An 80-year Run, though logged a success, is short some Trickles.

How far overclocked is your machine?

Whether overclocked or not, some stability tests are due. (Hours of Memtest-86+, plus a full day of Prime95 Torture Test (four simultaneous copies).

Your results are not usual for such a machine.

You wouldn\'t read about it (well you will after I finish writing this).
It has happened again this time during a WU that the stats had already reset once on, now they have reset again.

The percentage done did not change (around 69%) but hours processed and hours to go changed, hours done reset to zero and hours to go reset to a new value of about 100 hours less than before.

It may have something to do with this message :-
(This all appears to have happened as the WU was getting it\'s information ready to send a trickle up message and I recall this is when this problem happened last time as well)


2008-02-20 01:43:05 [climateprediction.net] Task hadcm3inct_cmf7_1920_160_55869263_1 exited with zero status but no \'finished\' file
2008-02-20 01:43:05 [climateprediction.net] If this happens repeatedly you may need to reset the project.
2008-02-20 01:43:05 [climateprediction.net] Restarting task hadcm3inct_cmf7_1920_160_55869263_1 using hadcm3i version 544
2008-02-20 01:43:08 [climateprediction.net] Sending scheduler request: To send trickle-up message
2008-02-20 01:43:08 [climateprediction.net] (not requesting new work or reporting completed tasks)
2008-02-20 01:43:13 [climateprediction.net] Scheduler RPC succeeded [server version 509]

It appears that the WU started again from last checkpoint and in the process Boinc Manager resets the time counters but the progress stays the same.

I did not notice the last time it did this if the WU \'restarted\' or \'resumed\'. If it restarted then that is why the counters reset. If it resumed then it was a Boinc Manager thing?

The WU is still going and should of trickled again since this hiccup but it remains a mystery.

I am unsure if I have changed the Boinc Client version since the last time this happened.
I still think it is a Boinc thing as no other project has had any trouble.

Nope, that\'s just a configured entry in a database table. The wording of the message, and when it appears, is the problem...

The trouble is that this is code which is maintained by Berkeley, it can be modified here but the change would disappear again when the server-side code is updated.

I can remove this message from the scheduler if it would help.
But this would apply in all situations.

When you restore the contents of the BOINC folder there aren\'t many extra steps compared with backing up.

* In BOINC manager suspend all work in progress. Close X BOINC manager.

* Exit from BOINC manager by right-clicking on the BOINC icon & selecting Exit.

* Go to your BOINC folder, probably C\\Program files\\BOINC.

* Double-click on the BOINC folder to open up its contents.

* Now the apparently scary bit. You have to empty the BOINC folder to make room for what you\'re going to restore. Edit > Select all > Edit > Delete. Everything disappears. What you\'ve deleted will now be in the Recycle bin and in a worst-case scenario (eg the restore of your backup didn\'t work) you could send the BOINC files in the Recycle bin back to where they came from, and they\'d work again. So you never empty the Recycle bin until the restore is up and running.

* Go back one page so you see the BOINC folder in the list again.

* Keep that window open, make it half-size.

* In a new window, go to your backup, wherever you saved it.

* Double-click on the backup to open its contents.

* Edit > Select all > Edit > Copy

* Make this second window half-size.

* Take your mouse cursor over to the first window, right-click on the BOINC folder and in the menu that opens up, select Paste.

* When all the files have finished transferring, close the 2 windows.

* Start > Programs > click on the BOINC shortcut to start BOINC up again. You\'ll need to open the BOINC manager if it doesn\'t open up automatically, then resume tasks.