So after a week of failed downloads for version 2.14, I was startled this morning when I saw CAMB 2.15 being downloaded by a Linux x86 machine. Since the home page claims that Linux app problems have been \"fixed\" but gives no details, I had hope. It downloaded successfully.

But, when it started to run it failed in 1 second with \"received signal 11\" which is a segmentation fault or memory reference error. Normally this is a sign of application coding errors such as missing address references or uninitialized pointers. So much for testing, eh?

So after a week of failed downloads for version 2.14, I was startled this morning when I saw CAMB 2.15 being downloaded by a Linux x86 machine. Since the home page claims that Linux app problems have been \"fixed\" but gives no details, I had hope. It downloaded successfully.

But, when it started to run it failed in 1 second with \"received signal 11\" which is a segmentation fault or memory reference error. Normally this is a sign of application coding errors such as missing address references or uninitialized pointers. So much for testing, eh?

Not to worry, by CAMB 9.99 it coulda, woulda, shoulda, be or been fixed ... ;) ... I\'m surprised anybody even wants any Wu\'s from this Project anymore, I had to tip the Barrel over to even find it on the Stats Sites anymore ... :)

So after a week of failed downloads for version 2.14, I was startled this morning when I saw CAMB 2.15 being downloaded by a Linux x86 machine. Since the home page claims that Linux app problems have been \"fixed\" but gives no details, I had hope. It downloaded successfully.

But, when it started to run it failed in 1 second with \"received signal 11\" which is a segmentation fault or memory reference error. Normally this is a sign of application coding errors such as missing address references or uninitialized pointers. So much for testing, eh?

As long as they fail @ 1 sec I don\'t mind, when they run to completion and won\'t download.... thats when I have a problem! We\'ll see how they do on windoze 64.

---

A clear conscience is usually the sign of a bad memory

It could just be \"luck of the draw\" that the first couple of lensing-enabled tasks were short-running anyway, but 2.15 seems to be faster than 2.14.

I reserve the right to change my opinion on that, obviously, because it could be that I just lucked out...

It sure would be nice if we were kept informed of the changes...

---

Bah... just missed the edit window...

It seems as though it was luck, as the runtime estimates are now creeping back up again...

Well I am not at this point going to download CAMB 2.15, when I still have the issue of all the CAMB 2.13 work units that I processed and have been granted ZERO credit for when they were all successful.
My results were successful but because the server sent out too many results I got zero due to error messages like \"Too many Successful Results\", \"Too Many Error Results\" (not mine too many others), and a couple of other error messages that mostly boiled down to the fact that of an initial set quorum the server kept sending out more than required.

So I would very much like credit for all the Zero granted results I have been given (and my Wingmen as well were given), I have a printout of them all so if they are needed I can get them to you.

And please Cosmology we all would love to hear from you, we just don\'t know what is going on and lots of people are leaving the project, I also have stopped waiting to hear from you.
I would love to get to a million cobblestones on this project.

---

Sorry to hear that Conan, but do keep an eye on the message boards here things could change.

On the subject of which, I have had a bit of a shock this morning, well actually two shocks. Firstly, both machines have filled their queues with Cosmology work overnight. I could hardly believe that one and went to check the messages log. BoincView\'s handy filter feature confirmed there had been no \"no work\" or \"committed to other platform\" messages since 20:49:45 UTC. BOINC had made an automatic repeat request a minute later at 20:50:45 utc and got work. Every request for a non-zero number of seconds since then has been met with a least one WU.

Did anyone do anything with the server around 20:50 UTC yesterday? If so it worked - keep that setting! Of course it could have beeen someone else had pulled out of Cosmology at the time and the straw which was breaking the server\'s back was removed!

The other shock was about the 2.15 run time being down. Sadly as Brian has discovered that one turned out to be false. BoincView is showing an estimated completion times on the machine into the 2.15 work down to 2hrs 15 mins this morning; the machine still on 2.14 is showing over 5 hours. However, closer inspection shows that the first batch of 2.15 work consisted mainly of re-sends of work sent out on July 10th under 2.12 - they all completed under an hour with 2.15. The newer work created since July 24 is all taking very similar times whether 2.14 or 2.15 is used. I should add both machines are identiacal save for a different model of motherboard and graphics card.

Phoneman1

just completed 2wu\'s and they ran for 12 and 13 hrs to completion and downloaded correctly. Now I\'m gonna put cosno in a holding pattern till these validate so I dont waste a lot more time.... just in case. ;)

---

A clear conscience is usually the sign of a bad memory

So far so good 2.15 seems to working properly on my linux box. A few of the wu\'s I have crunched have already been awarded credit. As brian pointed out it looks like the 0 credit WU\'s from 2.14 are clearing cue before the 0 credit issue can be dealt with. I can\'t remember which project it was but I do recall having some problems with credit ,and having the project award partial credit for lost time to it\'s participants hopefully this will be the case here as well(just an Idea meet us half way).

---

So far so good 2.15 seems to working properly on my linux box. A few of the wu\'s I have crunched have already been awarded credit. As brian pointed out it looks like the 0 credit WU\'s from 2.14 are clearing cue before the 0 credit issue can be dealt with. I can\'t remember which project it was but I do recall having some problems with credit ,and having the project award partial credit for lost time to it\'s participants hopefully this will be the case here as well(just an Idea meet us half way).

Ok, I have made a last try für cosmo. 7 WUs Camb 2.15, all errored out with:

SIGSEGV: segmentation violation

after s couple of minutes.

I\'m holding cosmo until the errors disappear. There are other projects which are granting credit for my CPU-time.

Bye for now (hopefully not for the next months??)

Frank

Well to top off all the CAMB 2.13 results I sent back and have been getting granted ZERO credits for each and every one, I noticed that some of my remaining pending are now being resent out as CAMB 2.15 work units.

This of course means that the results don\'t match and a third result has to sent out, a CAMB 2.15 naturally, so my 2.13 wont match the two 2.15 results so I get a big fat ZERO again.

It looks like I wasted well over 240 hours (closer to 250 hours, equal to over 10 days worth of computer processing) of computer time for no return at all (as in ZERO credits), for all the work units I returned over the last week.

Not a happy camper, and very disappointed with the lack of communication from the project.
It used to be the best project for keeping the volunteers up to date now it has dropped down near the bottom.

I know Scott has his hands full but we need to know what is going on.

---

...I know Scott has his hands full but we need to know what is going on.

I shall rephrase what you said \"The project needs to put somebody in charge who KNOWS what is going on and can get results, otherwise the project will continue to be encumbered and plagued with ongoing problems.\" Personally I don\'t see how any science is getting done; I feel like I\'m doing nothing more than helping some boy scout earn a computer science badge rather than solve the mysteries of cosmology. I hope I\'m wrong.

...I know Scott has his hands full but we need to know what is going on.

I shall rephrase what you said \"The project needs to put somebody in charge who KNOWS what is going on and can get results, otherwise the project will continue to be encumbered and plagued with ongoing problems.\" Personally I don\'t see how any science is getting done; I feel like I\'m doing nothing more than helping some boy scout earn a computer science badge rather than solve the mysteries of cosmology. I hope I\'m wrong.

Cosmology administrator job posting

That was posted sometime yesterday...

Given all the problems, if someone wants to take it on, I\'d hope they\'d be smart enough to ask for the higher pay... Oh, and I don\'t see how 10-15 hours a week will cut it either...

However, this does point to some reasons why nothing is happening around here with the problems...

---

...I know Scott has his hands full but we need to know what is going on.

I shall rephrase what you said \"The project needs to put somebody in charge who KNOWS what is going on and can get results, otherwise the project will continue to be encumbered and plagued with ongoing problems.\" Personally I don\'t see how any science is getting done; I feel like I\'m doing nothing more than helping some boy scout earn a computer science badge rather than solve the mysteries of cosmology. I hope I\'m wrong.

Cosmology administrator job posting

That was posted sometime yesterday...

Given all the problems, if someone wants to take it on, I\'d hope they\'d be smart enough to ask for the higher pay... Oh, and I don\'t see how 10-15 hours a week will cut it either...

However, this does point to some reasons why nothing is happening around here with the problems...

Agree...from the job description it appears that the project is asking a lot from an undergraduate; it further supports my fear that problems will be ongoing. Must be on a tight budget.

So far so good 2.15 seems to working properly on my linux box. A few of the wu\'s I have crunched have already been awarded credit. As brian pointed out it looks like the 0 credit WU\'s from 2.14 are clearing cue before the 0 credit issue can be dealt with. I can\'t remember which project it was but I do recall having some problems with credit ,and having the project award partial credit for lost time to it\'s participants hopefully this will be the case here as well(just an Idea meet us half way).

APoch, what Linux distribution are you using, and what is your CPU? I\'m beginning to suspect pretty strongly that this project doesn\'t know how to code and test a distribution-neutral Linux application. They must be assuming specific library and file structures that are not the same everywhere, as often happens with stuff developed and tested exclusively on RedHat products. That\'s the only way I can understand how you could be getting 2.15 units to run, while others of us crash with instant segmentation errors the minute the app starts.

In other words, they might be using dynamic calls to a library name that isn\'t the same in all distributions, just as an example. That will get a SIGSEGV in some but work in others. Such calls should be static linked or else check for the library name before trying to use it.

So far so good 2.15 seems to working properly on my linux box. A few of the wu\'s I have crunched have already been awarded credit. As brian pointed out it looks like the 0 credit WU\'s from 2.14 are clearing cue before the 0 credit issue can be dealt with. I can\'t remember which project it was but I do recall having some problems with credit ,and having the project award partial credit for lost time to it\'s participants hopefully this will be the case here as well(just an Idea meet us half way).

APoch, what Linux distribution are you using, and what is your CPU? I\'m beginning to suspect pretty strongly that this project doesn\'t know how to code and test a distribution-neutral Linux application. They must be assuming specific library and file structures that are not the same everywhere, as often happens with stuff developed and tested exclusively on RedHat products. That\'s the only way I can understand how you could be getting 2.15 units to run, while others of us crash with instant segmentation errors the minute the app starts.

In other words, they might be using dynamic calls to a library name that isn\'t the same in all distributions, just as an example. That will get a SIGSEGV in some but work in others. Such calls should be static linked or else check for the library name before trying to use it.

I am using Ubuntu 64 bit os ver # 8.04 on a AMD 64 bit athalon,3200.

---

Something caught my eye in this job listing \"the student will work closely with the previous project administrator. \" This line makes me think he will be sticking around ,perhaps in a some what diminished capacity, or the position will be divided between two instead of just one with the new person taking the lead. It also suggests what we all feared the person running the show up until now was under qualified. I for one hope that we get two people. even if they are both part time, two heads are normally better than one

Good luck Ben even though your project is a pain in the ass atm I will stand by it. I look forward to the day when this project leaves the alpha stage LOL

---

I am using Ubuntu 64 bit os ver # 8.04 on a AMD 64 bit athalon,3200.

Ah, that explains it. 64 bit is completely different. I wonder if they are passing out the 64 bit application code to 32 bit machines? That would certainly explain the segmentation errors. I swear, the sudden bumbling ineptitude of this project team knows no bounds. It is exceeded only by their constant failure to communicate the truth about what is going on.