According to the applications page, CAMB 2.13 has been updated to CAMB 2.14 early this morning.

Hopefully, this will fix the problems we are all experiencing right now.

I am still not getting any response from the server even though the sever page indicates that there is work available.

One of my machines (Windows Intel quad core) has downloaded seven of the v2.14 wu\'s in the last hour. I\'ve suspended the other tasks on that machine tempoarily so I can run these asap. They have been going nearly 15 minutes and showing good progress on Boincview, fingers firmly crossed.

Incidentally, all seven are re-sends of units originally downloaded with the abortive v2.13 last night.

Phoneman1

Five of the seven I downloaded earlier have now finished and been uploaded and reported. Three of these ran for nearly 4 hours on my Intel Q6700 running Windows Vista HP and Boinc only (with update responses every few seconds to Boincview running on another machine). These three wu\'s have claimed a credit of between 60 and 70, so I don\'t know what will be awarded until the wingmen complete - this could be an issue for some I guess (not me). The other two took just under one hour and just under two hours and claimed credits of 14.5 and 35 respectively.

All the 2.4 wu\'s to finish so far have an stderr text rather different from the 2.12\'s - the 2.14 version is

<core_client_version>5.10.45</core_client_version>
<![CDATA[
<stderr_txt>
called boinc_finish

</stderr_txt>
]]>

I\'ve being looking at Boincview occassionaly as they have been crunching and I think the reported progress seems to slow around the 20% mark and speed up again around the 80% mark. a rather subjective observation as I wasn\'t watching them for the full 4 hours! If I\'m right this will have implications in guessing your work buffer and doubtless for Boinc to do the same!

Phoneman1

Finally picked up a camb 2.14 on my slowest box(266g p4) and immediately got a message that I couldn\'t get another wu because it was \"committed to other platforms\"? And my Quad(Intel(R) Xeon CPU 3.00GHz) has been \"kicking the client\" for over a day with no results. And since that box is halfway across the country I have no idea what the log file is on it, just that it has no work.

---

A clear conscience is usually the sign of a bad memory

Good job guys!

But why I can\'t get newest CAMB version? Last 5 days I\'ve tried every day to get WU\'s.

23.07.2008 21:54:58|Cosmology@Home|Sending scheduler request: Requested by user. Requesting 68176 seconds of work, reporting 0 completed tasks
23.07.2008 21:55:03|Cosmology@Home|Scheduler request succeeded: got 0 new tasks
23.07.2008 21:55:03|Cosmology@Home|Message from server: No work sent

Results ready to send 4,815

Server Status OK.

In sheer desperation I\'m running Einstein@home now.
But first I will help this project!

It looks like I\'m getting jobs that have been around for a few weeks and are being re-issued. Each has previously been run on version 2.12 by someone else. They get the following result and a compute error with zero claimed credit.

<core_client_version>5.10.45</core_client_version>
<![CDATA[
<message>
too many normally harmless exit(s)
</message>
<stderr_txt>

</stderr_txt>
]]>

BTW, when debugging some stuff on Docking@Home, it was learned that just doing a reset project will not always download new versions of everything so when Cosmology 2.14 came out I completely detached and re-attached to cosmology. That does cause all files to be re-downloaded. These errors are on a machine that had already been detached and re-attached.

These WUs seem to be from either the 1st or 13th/14th of the month. I\'m going to follow the advice on the front page and abort the ones that haven\'t run yet.

One of my machines (Windows Intel quad core) has downloaded seven of the v2.14 wu\'s in the last hour. I\'ve suspended the other tasks on that machine tempoarily so I can run these asap. They have been going nearly 15 minutes and showing good progress on Boincview, fingers firmly crossed.

Incidentally, all seven are re-sends of units originally downloaded with the abortive v2.13 last night.

Phoneman1

Well, at least no one will be complaining about credits being too high anymore...
Your machines, currently, seem to be granted about 1/3rd the credits per hour they were previously!?!
I wonder if this was intentional and can only hope it may be rectified in the near future.
Going from a high paying project to paying less per hour than seti standard app is pretty profound..
Was there pressure internally we aren\'t being aware of?
I am choose to remain optimistic and believing this is only temporary, it will get sorted.

---

Well, at least no one will be complaining about credits being too high anymore...

Don\'t bet the House on it ... ;)

Going from a high paying project to paying less per hour than seti standard app is pretty profound..

I like to Fondly call it Project Suicide, it\'s okay though, that\'s why they put an Abort Button in the BOINC Manager ... :) ... I like the way Scott was quick to mentioned that the Credit had been increased, but failed to mention that the Wu\'s would take 10-12 Times longer ...

We make about 5000 WUs per hour, and people seem to be grabbing them up immediately. Eventually this will normalize, but the more \"greedy\" users are going to get a lot of the WUs for a little while.

---

Scott Kruger
Project Administrator, Cosmology@Home

Don\'t forget that you can control that \"greed\" a bit through the fpops_est settings of the workunits.

The new workunits need 4.5 times longer than the previous ones, so their fpops_est should be the \"old\" fpops_est multiplied with 5.5 .

The absolute value of fpops_est isn\'t extremely important, as that is equaled out by including the duration correction factor into the estimated time calculation. So the absolute value affects only new attached boxes that have a default DCF of 1.

The relation between different WU series within a project is important for the cache control though, the ratio between fpops_est of two series should always be close to the ratio between their crunching times.

Going from a high paying project to paying less per hour than seti standard app is pretty profound..

Looks like Cosmology has gone to a zero-paying project here. All 2.13 units failed instantly on startup, and 2.14 units are now doing the same thing. I can only conclude that the Linux version of the application doesn\'t really get tested before putting it in the field.

I\'m wondering about the new cpu times of the Linux 64-Bit-app.
These three here:
http://www.cosmologyathome.org/result.php?resultid=10892997
http://www.cosmologyathome.org/result.php?resultid=10892968
http://www.cosmologyathome.org/result.php?resultid=10892657
take about 30% more time (and are all over 3,5 hours) than before the lensing was removed from the parameters.
I\'m not sure if this is intended that some WUs now take longer, but according to some known Win 64-Bit values I assume, that there were missing some optimization flags during the compiling of the 64-Bit apps and they are now slowering down the 64-Bit hosts.
In addition, 70 credits would be way too low for that OS times.
Can anybody agree the times?

---

Life is Science, and Science rules. To the universe and beyond
Member of BOINC@Heidelberg
My BOINC-Stats

Hi,
In the download directory, the CAMB 2.14 application for Linux x86 is 0 byte in length. For the other platforms, it\'s ok.

That cause all work for that platform to be in error.

Thanks for the good work.

Hi,
In the download directory, the CAMB 2.14 application for Linux x86 is 0 byte in length. For the other platforms, it\'s ok.

That cause all work for that platform to be in error.

Thanks for the good work.

After your post Avatar1966, I noticed that I had a few CAMB 2.14 WU\'s download, so I checked my CAMD 2.14 file under boinc/projects and also found it to be of 0 kB in size.
My CAMB 2.13 file is 3.2 MB in size so a problem it seems.

As all my 2.13 work units are getting ZERO when a wingman returns a result, from either \"Too Many Error Results\" (even though there are 2 successful results that meet quorum), or \"Too Many Success Result\" (can\'t work that one out), I have set my computer to \'No More Work. for Cosmology.

With no data in the CAMB 2.14 file then they will most likely error out as well.

So to save wasting my time and electricity for no results or even any credit (the only ones that seem to get credit, and this about 1 to 2 WU\'s a day, are the ones that complete in under 20,000 seconds, anything over you get ZERO), I think that I will abort all my current work, and wait and see what the project comes up with.

Due to the large number of Pending and zero results at Cosmology and the huge WU length and low credit at The Lattice Project, my daily output has plunged.
My RAC at Cosmology has gone from a high of around 4,000 down to now at 1,200, and falling.

So sorry Cosmology but I have now aborted all work, sorry also to all wingmen, but at the moment I am very disappointed with all this, mainly no project response.
I know you are busy, but we don\'t just sit here either.

I will keep an eye on this as I really like this project, it was my favorite, and I hope it to be again.

---

After your post Avatar1966, I noticed that I had a few CAMB 2.14 WU\'s download, so I checked my CAMD 2.14 file under boinc/projects and also found it to be of 0 kB in size.
My CAMB 2.13 file is 3.2 MB in size so a problem it seems.

Yup. This has been reported over and over again, but no one on the project admin team seems to be doing anything about it. The lack of communication is truly disappointing. They could at least say \"OK, we know about this and are trying to fix it\" but instead, nothing.

Shows how much they appreciate volunteer efforts.