4.13 is causing crunchable work units to be sent into the waiste basket again!!!

TOO MANY DOWNLOAD ERRORS

---

98SE XP2500+ @ 2.1 GHz Boinc v5.8.8

And God said"Let there be light."But then the program crashed because he was trying to access the 'light' property of a NULL universe pointer.

4.13 is causing crunchable work units to be sent into the waiste basket again!!!

TOO MANY DOWNLOAD ERRORS

====================
Yep, have had a few of mine reported up and rejected (Zero credits) due to too many errors DLing from sub 4.19 crunchers. Until Berkeley/Boinc forces them to upgrade and the UL/DL problems persist with Seti, best thing to do is no new work for Seti and crunch different project(s) for a week or two while they sort it out.

---

It may well be like myself (a few weeks ago) that they do not know that there is a "better" version available to them.
Please do not "damn" people out of ignorance.
They are not all dedicated crunchers like you & I!

Regards,
Graeme Murphy.
www.setiuk.com

---

It may well be like myself (a few weeks ago) that they do not know that there is a "better" version available to them.
Please do not "damn" people out of ignorance.
They are not all dedicated crunchers like you & I!

Regards,
Graeme Murphy.
www.setiuk.com

======================
Seti/Boinc has it in their power to fix the problem by denying sub 4.19 versions from DLing work until they do upgrade. That is supposed to be one of the finer points of Boinc.

I am curious to know why they haven't forced the upgrade. I think the last time they forced an upgrade was when moving from ver 3.xx to ver 4.xx

Jim

======================
Seti/Boinc has it in their power to fix the problem by denying sub 4.19 versions from DLing work until they do upgrade. That is supposed to be one of the finer points of Boinc.

---

I am curious to know why they haven't forced the upgrade. I think the last time they forced an upgrade was when moving from ver 3.xx to ver 4.xx

Jim

======================
Seti/Boinc has it in their power to fix the problem by denying sub 4.19 versions from DLing work until they do upgrade. That is supposed to be one of the finer points of Boinc.

And, If I'm not mistaken shouldn't we be seeing the move to a new major version number very soon? Rom already tried to do it earlier, but found the projects need to do some adjustments that would take a "couple weeks". So we should be very near that move

Yes, I do believe we are close to a new major version number.

It will be very interesting to see how this new major upgrade works now that so many projects are online. I think we'll see some of the projects really drag their feet on upgrading the backend server software.

I really think this is going to be a big learning experience for all involved.

Jim

And, If I'm not mistaken shouldn't we be seeing the move to a new major version number very soon? Rom already tried to do it earlier, but found the projects need to do some adjustments that would take a "couple weeks". So we should be very near that move

---

I am curious to know why they haven't forced the upgrade. I think the last time they forced an upgrade was when moving from ver 3.xx to ver 4.xx

Jim

======================
Seti/Boinc has it in their power to fix the problem by denying sub 4.19 versions from DLing work until they do upgrade. That is supposed to be one of the finer points of Boinc.

================
In light of the DL problems Berkeley is having, I see many of the 4.13 CC users failing 20-50+ results before they get a DL or full cache. Maybe in two weeks their DL quota will reduce but by then Berkeley should have the DL/UL problem fixed.

It may well be like myself (a few weeks ago) that they do not know that there is a "better" version available to them.
Please do not "damn" people out of ignorance.
They are not all dedicated crunchers like you & I!

Regards,
Graeme Murphy.
www.setiuk.com

Better version than 4.13? Holy cow where have you been? The last of the "best" versions was 4.19 and at that point in time the BOINC devs should have asked the projects to alter the min required release to 4.19 to overcome the severe problems with the consequences of 4.13 not being able to fully download a file. Well at least 2 months later.

The date stamp on the BOINC V4.13 on my system shows 29 Oct 2004. The problems with 4.13 were quickly highlighted on Predictor and we went through a few versions before 4.19 was found to be a very stable release (date stamp 27 Jan 05). This was the recommended release (and still is on some projects) for quite a while until 4.25 and the BOINC Manager came along (date stamp 21 March 05). Recently V4.45 (date stamp 10 June 05) became the recommended version. I think there has been sufficient time for people to have upgraded from 4.13 to at least 4.19 by now.

If folks don't have 4.19 and want it all they need to do is ask the question and a heap of people can point them in the right direction to find it.

DAMN YOU PEOPLE USING BOINC 4.13.

I'm lucky enough not to have been adversely affected just yet but this host http://setiathome.berkeley.edu/results.php?hostid=1184839 came pretty close. Check out the wu's and notice that each wu has at least 1 download error and each of those is due to a host running 4.13!

I can't wait for the major version change to take place, but then beta is only at 4.71 so we have a while to go.

Live long and crunch.

---

Paul
(S@H1 8888)
And proud of it!

I believe this information fits in with the topic of this thread. I too have pending results with users using v4.13 core client. Upon further investigation, I discovered this user's pending result, which is pending for me as well:

Result ID-------------87411572
Name------------------09ja05aa.8723.31184.490920.66_0
Sent------------------17 Jul 2005 8:46:35 UTC
Received--------------17 Jul 2005 19:37:52 UTC
....
stderr out

Validate state--------Initial
Claimed credit--------26.8278088208543
Granted credit--------0
application version---4.08

I was under the impression that the app client was downloaded automatically when a new one was released. This WU was sent and result recieved today. How, then, can v4.08 still be used? I feel something's hinky in SETIville, unless there's a real reason for what I found.

---

CAPT Siran d'Vel'nahr - L L & P _\\//
Winders 11 OS? "What a piece of junk!" - L. Skywalker
"Logic is the cement of our civilization with which we ascend from chaos using reason as our guide." - T'Plana-hath

I was under the impression that the app client was downloaded automatically when a new one was released. This WU was sent and result recieved today. How, then, can v4.08 still be used? I feel something's hinky in SETIville, unless there's a real reason for what I found.

If they are using a self compiled version ... they can change the nuvber to whatever they wish ...

---

I got caught on the previous outage/recovery period with 2 units I crunched that got big fat 0 because of 4.13 download errors. So now I check all units received at times of server stress and so far this time I've aborted 3 units that have too many errors, on at least one of them somebody has crunched one of them sucessfully but will get 0 again.

If Ver 5 is more than a week away I think that Berkeley should stop all downloads to 4.13 hosts immediately, because they must be part of the cause for server overload. Yesterday at this time after clearing my upload queue previously I had 4 units waiting to UL now I have 17 on the transfer screen, because Einstien won't give me any more work until later today.

Andy

It's true that mostly old clients such as 4.13 cause excessive DL errors. But not allways. Check this result: http://setiweb.ssl.berkeley.edu/result.php?resultid=87954664

---

Metod ...

It's true that mostly old clients such as 4.13 cause excessive DL errors. But not allways. Check this result: http://setiweb.ssl.berkeley.edu/result.php?resultid=87954664

From above's last line: application version 4.18

---

Click here to join the #1 Aussie Alliance in SETI

It's true that mostly old clients such as 4.13 cause excessive DL errors. But not allways. Check this result: http://setiweb.ssl.berkeley.edu/result.php?resultid=87954664

From above's last line: application version 4.18

It doesn't matter. What matters is core client version.

---

Metod ...

Why?

Why doesn't BOINC allow "unlimited" dl-errors?

The wu's are scientificaly completely valid, and dl'ing over internet are error-prone, so a dl error should never influence the validity of a wu!

Without this unneccessary limitation, no-one would loose credit due to others dl-problems, whatever the reason.

Please see for details:
http://setiweb.ssl.berkeley.edu/forum_thread.php?id=16563

---

Why?

Why doesn't BOINC allow "unlimited" dl-errors?

...SNIP...

It is because of DB size.

Happy crunching,

---

Well, if it is because of DB size, then it's designed wrong.

No new wu's should be created until existing wu's with dl errors are satisfactory sent-crunched-received-validated. Then the DB will be kept at a proper size.

Why? Because the wu's are still valid scientifically. Dl errors should never hamper this.

---

I think they did it because sometimes there problems that cause dl errors that have nothing to do with the science. Some of these errors could include improper signing of the WU's or results or the science app, or some other problem of which I'm not familiar.

In an effort to keep these types of problems from constantly failing a transfer, they put in a number of failures before ditching the WU.

Jim

Well, if it is because of DB size, then it's designed wrong.

No new wu's should be created until existing wu's with dl errors are satisfactory sent-crunched-received-validated. Then the DB will be kept at a proper size.

Why? Because the wu's are still valid scientifically. Dl errors should never hamper this.

---

If so it's a real pity.

I can't see why it would cost them too much to differentiate the network induced errors (timeout etc) from the rest (improper signing?).

It must be more expensive to drop a scientifically correct wu that has been validated ok by one or two others!

---