Many thanks to SETI. More than 40 hours of work have gone with the wind... :-(

Many thanks to SETI. More than 40 hours of work have gone with the wind... :-(

And the world turns, life goes on............

---

IAS - Where Space Is Golden!

It appears that at least some late results are getting credit when returned after the other results have been validated. Here is one I was watching:

http://setiathome.berkeley.edu/workunit.php?wuid=23946052

It appears that at least some late results are getting credit when returned after the other results have been validated. Here is one I was watching:

http://setiathome.berkeley.edu/workunit.php?wuid=23946052

The deadline of this WU was on monday. You are lucky and the siblings of your WU haven't been deleted yet. (From the tech news: "We turned the public servers back on yesterday even though the assimilation/deletion queue hadn't fully drained.")

The deadline of my WUs was on saturday and the siblings have been deleted. And therefore: granted credit: 0.00

see http://setiathome.berkeley.edu/workunit.php?wuid=23769271 and others

It's me again...

I've just gone through the old workunits. And I like to know what happened around Sat 27 Aug 2005 22:55 UTC.

Just look at these WUs:
WU 23804912
WU 23804934

Right now, both have three results, which were validated before the outage. Both have one result still missing. But WU 23804912 shows a fifth result with the outcome "didn't need", WU 23804934 does not show a fifth result. As far as I know WU 23804912 is closed and WU 23804934 is still waiting to get the missing result.
And as far as I can tell from my own results, this is correct:

no credit: WU 23769301
waiting for credit: WU 24233506

So: What exactly happened on 22:55 UTC on that Saturday? Did you switch of the deleter? Or have you done anything else? (If you have done anything else, why havn't you done it before, so that *everybody* gets the credit for the work he/she has done...?)

Kind regards,
Carsten

edit: fixed a bad URL

I've just gone through the old workunits. And I like to know what happened around Sat 27 Aug 2005 22:55 UTC.

Just look at these WUs:
WU 23804912
WU 23804934

Right now, both have three results, which were validated before the outage. Both have one result still missing. But WU 23804912 shows a fifth result with the outcome "didn't need", WU 23804934 does not show a fifth result. As far as I know WU 23804912 is closed and WU 23804934 is still waiting to get the missing result.

Validator2 was working a little faster than Validator4, so Validator2 hit WU 23804934 before 27.08.2005 at 22:05:07 UTC, meaning this wu was already validated when the "missing" result timed-out.

Validator4 on the other hand worked a little bit slower, so WU 23804912 wasn't validated when the "missing" result timed-out. Since wu wasn't validated, this meant a new "result" was generated and ready to send out. But, since Validator4 at last came to this wu and validated wu before the newly-generated result was sent out, this was marked "didn't need" and is never sent out.

For BOINC's part both these wu is now finished, but it's possible one or both wu is currently stuck in Assimilator-backlog or file_deleter-backlog, so if timed-out result manages to be reported and validated before file_deleter catches-up it will give credit.


WU 23769301 is already finished, and nothing else will happen except db_purger will eventually remove it from database.

WU 24233506 was also reported after deadline, but for this wu the file_deleter have not yet catched-up. As long as validator get to it before the file_deleter, it should give credit.

Hello Ingleside,

Validator2 was working a little faster than Validator4, so Validator2 hit WU 23804934 before 27.08.2005 at 22:05:07 UTC, meaning this wu was already validated when the "missing" result timed-out.

Validator4 on the other hand worked a little bit slower, so WU 23804912 wasn't validated when the "missing" result timed-out. Since wu wasn't validated, this meant a new "result" was generated and ready to send out. But, since Validator4 at last came to this wu and validated wu before the newly-generated result was sent out, this was marked "didn't need" and is never sent out.

Thank you for your answer, but I do not understand it...

...because *each* WU before 27 Aug 22:55 UTC with three validated results and one missing result looks like WU 23804912. And *each* WU after 27 Aug 22:55 UTC with three validated results and one missing result looks like WU 23804934. In my opinion, this cannot be explained with faster/slower validators (by the way: where do you see when and which validtor did the validation?)

Carsten

hm, probably I understand now:

as far as I remember the "Waiting for validation"-queue went down to 0 on the weekend. Each validated WU with a deadline before the weekend was closed, each younger WU still waits for the missing results. And as the file-deleters and db_purge are turned off in the moment this will last on for a while.

But there is one more question:

Why don't you avoid that results, which are still in time before an outage, are thrown into the rubbish bin?

Carsten

I just managed to get one WU uploaded with a transfer rate of 3.12KBps. What kind of modem would that translate to? 300 baud?

3Kbs=3000 bits per second
3KBs= 3000 Bytes/second or 24,000bits/second or 1/2 a 56K connection

Since most everyone has some late work sitting on thier computers a much larger percentage of them will validate than normal.

How do you know that? Have you read it somewhere or do you just think that will be the case? I have not read it anywhere other than as speculation.

Live long and crunch.

When a result is reported late, its sibling files could be in one of three states: (1) not yet validated because units were reissued or results haven't matched, (2) already validated but not yet deleted, or (3) long gone.

In the first case, SETI appears to accept the late result and validate it along with the others, granting credit in the process.

In the second case, the sender doesn't get any credit, but the result file is cleaned up by the system.

In the third case, the result file becomes an antique... slowing the entire project down to a crawl and spawning hundreds of angry Message Board posts :-)

Assuming for the sake of argument no special accomodation is made when the project comes back on-line, result files will start pouring in. The work unit can't be validated until a certain number of result files return, even if every one of them is late. Thus, credit should not be an issue since everyone is going to be late.

The problem is if the system delcares all of those results overdue and re-issues them as soon as downloads resume. This would represent a huge amount of wasted computing effort... the work is already out there.

I hope that the project keeps the reissue-due-to-expired-results process held up for a few days after everything gets rolling again. Hopefully this would not prevent the validator from reissuing work units in cases where the result files are inconsistent with each other.

That's right the Result Nr. 99882072 is a good exampleforthe third case

---

<a><img src="http://www.boincstats.com/stats/banner.php?cpid=3837f9fafc28ff2e9df5b13ae2f8aaf7"></a> A member of the <a><img src="http://www.boincstats.com/stats/teambanner.php?teamname=SETI.Germany"></a> team.

3Kbs=3000 bits per second
3KBs= 3000 Bytes/second or 24,000bits/second or 1/2 a 56K connection

well in the boinc transfer column is KBps really KBps or Kbps?

3Kbs=3000 bits per second
3KBs= 3000 Bytes/second or 24,000bits/second or 1/2 a 56K connection

well in the boinc transfer column is KBps really KBps or Kbps?

I'm on dial up so I get to watch the speed column for a period of time and it says KBps and given that when four different wus (2 per project) are trying to download I'll see the "bandwidth" divided up between them and be like 1.03 KBps, where as if there is only one It'll be closer to 4 KBps. I believe it is KBps.

3Kbs=3000 bits per second
3KBs= 3000 Bytes/second or 24,000bits/second or 1/2 a 56K connection

well in the boinc transfer column is KBps really KBps or Kbps?

I'm on dial up so I get to watch the speed column for a period of time and it says KBps and given that when four different wus (2 per project) are trying to download I'll see the "bandwidth" divided up between them and be like 1.03 KBps, where as if there is only one It'll be closer to 4 KBps. I believe it is KBps.

Usually measuring a transfer rate in K(M, G)bits per sec makes sense only if you are talking about a serial data flow, such as Ethernet, serial COM port or telephone line, where bits physically are going one at a time after another through a single wire. If you're interested in gross performance, e.g. how fast a file is transfered, you don't want to (or may not) know the low-level implementation. Then you use K(M, G)bytes per sec. Boinc Manager of course is the last case.

---

Kitty@SETI team (Russia). Our cats also want to know if there is ETI out there