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.

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

> 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...

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.

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.

> 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

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]

> 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]

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.

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.
>
>

> 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.

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

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!!!!!!!!!!!!!!!!!!!!!!!!!!!

Calm down.

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

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.

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

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

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.

third result = 28.5

so all get 28.5