Results processed more than three times?


log in

Advanced search

Message boards : Number crunching : Results processed more than three times?

1 · 2 · Next
Author Message
Petu
Send message
Joined: 19 May 99
Posts: 2
Credit: 302,790
RAC: 0
Finland
Message 8967 - Posted: 17 Jul 2004, 7:16:05 UTC

Yesterday I downloaded six results/WUs where the last digit in their "name" was 3. They were all from the 10ja04ab batch. And today I got one whose last digit was 5. I didn't get any other kind of results.

Previously this digit has been 0, 1 or 2 and occasionally 3 (a replacement for an abandonded result).
It seems quite unlikely that all these six results had fallen prey to somekind of a download error and had to be resent with a new last digit.

Have I understood the names totally wrong or have they recently changed the naming so that the count starts from 1 instead of 0 (producing last digits from 1...3)? The worst case scenario would be that the results are now processed more than three times. I believe in the latter. Please tell me I'm wrong.

Profile Keck_Komputers
Volunteer tester
Avatar
Send message
Joined: 4 Jul 99
Posts: 1575
Credit: 1,684,452
RAC: 555
United States
Message 8977 - Posted: 17 Jul 2004, 8:10:29 UTC

There will be some results sent out more than three times. This happens automatically when there is a problem with one or more of the original set that was sent out.

John Keck
BOINCing since 2002/12/08

Petu
Send message
Joined: 19 May 99
Posts: 2
Credit: 302,790
RAC: 0
Finland
Message 8982 - Posted: 17 Jul 2004, 8:56:11 UTC - in response to Message 8977.

> There will be some results sent out more than three times. This happens
> automatically when there is a problem with one or more of the original set
> that was sent out.
>
John Keck
> BOINCing since 2002/12/08

Yes, I know. It just seemed too unlikely to get six of them in a row. Though I have to admit that the other possibilities are just as unlikely. I just can't help being paranoid. If I only had access to that results page...

Bill Barto
Send message
Joined: 28 Jun 99
Posts: 860
Credit: 19,737,749
RAC: 25,924
United States
Message 9049 - Posted: 17 Jul 2004, 15:55:57 UTC

Last night I started to get work units with the high "to completion" times again. They all have four, five, or six as the last digit. It appears that people that didn't understand what was happening dumped their caches thinking that they would actually take that long to process.

Profile Toby
Volunteer tester
Avatar
Send message
Joined: 26 Oct 00
Posts: 1005
Credit: 5,622,795
RAC: 2
United States
Message 9061 - Posted: 17 Jul 2004, 17:11:09 UTC

Also, I recall a time when my client was trying to download work but there was some major error on the server so it failed 15-20 times before I noticed it and shut off network access until they had a chance to fix things. If this happened to a lot of people, it is quite possible that there are a lot of 'error' results that need to be re-sent now.

Profile [HWU] GHz & CO. - BOINC.Italy
Volunteer tester
Avatar
Send message
Joined: 1 Jul 02
Posts: 139
Credit: 1,279,729
RAC: 0
Italy
Message 9065 - Posted: 17 Jul 2004, 17:37:38 UTC - in response to Message 9049.
Last modified: 17 Jul 2004, 17:40:18 UTC

> Last night I started to get work units with the high "to completion" times
> again. They all have four, five, or six as the last digit. It appears that
> people that didn't understand what was happening dumped their caches thinking
> that they would actually take that long to process.
>
>

I think the same.

But there isn't an official comunication that talk about this problem.

On what this problem depends?

WU that have a long "To completation time" thake the same time to process, but with the credits? Are the same?

With the long time to completition there is the problem that the wu in cache are a minor number, and we must set many day of work in cache from the profile to have many WU to crunc.

GHz
Hardware Upgrade - Seti@home


Profile Sir Ulli
Volunteer tester
Avatar
Send message
Joined: 21 Oct 99
Posts: 2246
Credit: 6,098,790
RAC: 468
Germany
Message 9100 - Posted: 17 Jul 2004, 19:42:42 UTC

July 17, 2004
A server bug was preventing new results from being created in response to failed results. If 2 out of 3 results for a WU succeeded and the 3rd failed, the 2 successful results would not be validated or credited. This is now fixed and the system will issue new results for all workunits in this state.

http://setiweb.ssl.berkeley.edu/

Greetings from Germany NRW
Ulli [/url]

Profile [HWU] GHz & CO. - BOINC.Italy
Volunteer tester
Avatar
Send message
Joined: 1 Jul 02
Posts: 139
Credit: 1,279,729
RAC: 0
Italy
Message 9163 - Posted: 17 Jul 2004, 23:23:49 UTC - in response to Message 9100.

> July 17, 2004
> A server bug was preventing new results from being created in response to
> failed results. If 2 out of 3 results for a WU succeeded and the 3rd failed,
> the 2 successful results would not be validated or credited. This is now fixed
> and the system will issue new results for all workunits in this state.
>
> http://setiweb.ssl.berkeley.edu/
>
> Greetings from Germany NRW
> Ulli [/url]

Profile BigDawg
Send message
Joined: 16 Apr 04
Posts: 113
Credit: 6,927
RAC: 0
United States
Message 9168 - Posted: 17 Jul 2004, 23:30:43 UTC

You need to have a look at the begining of this thread;

http://setiweb.ssl.berkeley.edu/forum_thread.php?id=1243

In short the units will process in the normal time. The Seti team made some changes to values that make the completion estimates report to be 6x longer.
They were working on correcting it, i thought they had it fixed, but maybe not.

Profile Christopher Hauber
Avatar
Send message
Joined: 10 Feb 01
Posts: 196
Credit: 71,611
RAC: 0
United States
Message 9184 - Posted: 18 Jul 2004, 0:14:23 UTC - in response to Message 9168.

They did fix it and start sending new units out. If Bill is right about a lot of people dumping workunits that were marked with the long times (and a lot probably did), then it is possible that those units still use the x6 time system that they had originally. A high deletion rate (from the reattach instructions given when they changed the scheduler and high processing time estimates) plus the bug mentioned on the front setiweb page plus the way SETI is supposed to resend failed workunits anyway could very well explain why the short times went away again and why there are suddenly lots of units getting processed again.

There are also problems where the software can't process properly and downloads 50 in a day and fails all of them. And it may take a while for that to get fixed, especially if someone can't figure what is happening. I've seen other people have that problem. And I wasted 100 workunits before I figured out that I had the problem and then figured out that SETI couldn't delete some files because they were locked by the CLI. So suspicious looking or not, it appears that this time around there are a lot of things that all happened at the same time to cause it to be able to happen.

Chris

> You need to have a look at the begining of this thread;
>
> http://setiweb.ssl.berkeley.edu/forum_thread.php?id=1243
>
> In short the units will process in the normal time. The Seti team made some
> changes to values that make the completion estimates report to be 6x longer.
> They were working on correcting it, i thought they had it fixed, but maybe
> not.
>
>

Ingleside
Volunteer developer
Send message
Joined: 4 Feb 03
Posts: 1546
Credit: 3,576,058
RAC: 0
Norway
Message 9188 - Posted: 18 Jul 2004, 0:26:30 UTC - in response to Message 9168.

> You need to have a look at the begining of this thread;
>
> http://setiweb.ssl.berkeley.edu/forum_thread.php?id=1243
>
> In short the units will process in the normal time. The Seti team made some
> changes to values that make the completion estimates report to be 6x longer.
> They were working on correcting it, i thought they had it fixed, but maybe
> not.
>

The estimated report-time is based on parameters added to a wu then this was generated. All "results" from the same wu has the same parameters.
Since they've fixed a bug that prevented the generating of new results then an error had happened, these 6x-longer wu is now being re-distributed.

So then all these is distributed normal wu will follow. Note, since the re-distributed wu can stop again in error or someone doesn't return before deadline, it can take some weeks before all "long" wu is out of the system.

Since the actual crunch-time isn't influenced it's no big problem, except for dialup-users that gets shorter cache than expected and therefore must connect more often.

Profile [HWU] GHz & CO. - BOINC.Italy
Volunteer tester
Avatar
Send message
Joined: 1 Jul 02
Posts: 139
Credit: 1,279,729
RAC: 0
Italy
Message 9302 - Posted: 18 Jul 2004, 7:35:51 UTC

Thanks to all for the clarifications

But there are two days that my total credit don't increase....:(
That happen whit other member of the team.....we will have to still wait for a lot?



GHz
Hardware Upgrade - Seti@home


Tiziano
Send message
Joined: 20 Aug 00
Posts: 4
Credit: 3,823
RAC: 0
Portugal
Message 9530 - Posted: 19 Jul 2004, 0:15:25 UTC - in response to Message 9302.

I´ve posted at least 19 WU´s the last 2 days, my total credits didn´t increase but my average credits became less. There is something to work on. It would be nice to have access to this database which shows us all the 3x successfull processed WU´s and the pending ones. WORK ON IT!!!!!!!!!!!!!!!!!!!!!!!!!!!

Profile [B^S] MattDavis
Volunteer tester
Avatar
Send message
Joined: 11 Nov 99
Posts: 919
Credit: 608,470
RAC: 4
United States
Message 9536 - Posted: 19 Jul 2004, 0:31:45 UTC

Calm down.

STE\/E [BlackOps]
Volunteer tester
Send message
Joined: 29 Mar 03
Posts: 1137
Credit: 3,041,146
RAC: 0
United States
Message 9540 - Posted: 19 Jul 2004, 1:02:43 UTC
Last modified: 19 Jul 2004, 1:03:34 UTC

It would be nice to have access to this database which shows us all the 3x successfull processed WU´s and the pending ones.
===========

They may never bring that option back. If they do once everybody see's how bad they got screwed on their Credits on a lot of their WU's thats when the real uproar will begin...

The people have a right to be upset Matt, this site has not worked right from day 1, and it seems to be getting worse by the day. They expect everybody to just sit back and take it easy & everything will be okie-dokie in due time, pppfffftttttt, I'll believe that when I see it happen.
JOIN TEAM

Profile [B^S] MattDavis
Volunteer tester
Avatar
Send message
Joined: 11 Nov 99
Posts: 919
Credit: 608,470
RAC: 4
United States
Message 9552 - Posted: 19 Jul 2004, 1:43:56 UTC
Last modified: 19 Jul 2004, 1:44:12 UTC

I guess I just don't see how thirty exclamation points will help the situation. But I've always been a bit slow, and I'm sure I'll figure it out eventually.

STE\/E [BlackOps]
Volunteer tester
Send message
Joined: 29 Mar 03
Posts: 1137
Credit: 3,041,146
RAC: 0
United States
Message 9558 - Posted: 19 Jul 2004, 1:56:19 UTC

It was only 27, don't exaggerate ... :/ ;)

Profile [B^S] MattDavis
Volunteer tester
Avatar
Send message
Joined: 11 Nov 99
Posts: 919
Credit: 608,470
RAC: 4
United States
Message 9562 - Posted: 19 Jul 2004, 2:04:08 UTC

I was using sig. figs. This IS a board revolving around a scientific project, remember 8)

Profile bfarrant
Avatar
Send message
Joined: 4 Jun 99
Posts: 228
Credit: 36,710
RAC: 0
Canada
Message 9596 - Posted: 19 Jul 2004, 4:38:07 UTC - in response to Message 9558.

Matt: > I guess I just don't see how thirty exclamation points will help the situation.

PoorBoy: > It was only 27, don't exaggerate ... :/ ;)


OK, well we have one result in claiming 30 and a second result in at 27. We'll wait for the 3rd result to arrive (hopefully within 2 weeks) and we'll assume the middle figure is the correct one.




Profile BigDawg
Send message
Joined: 16 Apr 04
Posts: 113
Credit: 6,927
RAC: 0
United States
Message 9599 - Posted: 19 Jul 2004, 4:57:02 UTC

third result = 28.5

so all get 28.5

1 · 2 · Next

Message boards : Number crunching : Results processed more than three times?

Copyright © 2014 University of California