LHC@home

Take a gander at this workunit stuck in my pending list.

It appears to be validated and complete and will not be reissued for additional processing. Three hosts have been granted credit while mine and one other are still pending. WU was sent out 21 Apr and had 5 successful responses by the next day, 22 Apr.

Two of three hosts granted credit were Intel, the other AMD. My PC is AMD, the other pending result is from an Intel. So the problem (if there is one) appears to not be vendor-specific. Any ideas?

---

> Take a gander at this workunit
> stuck in my pending list.
>
> It appears to be validated and complete and will not be reissued for
> additional processing. Three hosts have been granted credit while mine and
> one other are still pending. WU was sent out 21 Apr and had 5 successful
> responses by the next day, 22 Apr.
>
> Two of three hosts granted credit were Intel, the other AMD. My PC is AMD,
> the other pending result is from an Intel. So the problem (if there is
> one) appears to not be vendor-specific. Any ideas?
>
@ Travis DJ
I have the same missbehaviour with the following list of 'pending' as you describe:

Result ID Claimed credit
419272___110.50
419289___100.30
419304___99.01

419334 61.56
419387___100.19
419391___103.97
419424 44.64
419471___103.74
419490___103.53
419501___103.72
419508___100.67
etc....
>

btw: THX for your words on the 'Fortran-error'-thread.

---

I'm afraid these results will never be granted credit. It's because the work unit has been already assimilated and the related result files (including canonical result) have been deleted or moved. However, these results will disappear from the "pending" list when the database entry is also deleted from the database.

I admit that it's unfair that you don't credit for these successfully completed results. We will try to find a way to prevent this in future.

---

Markku Degerholm
LHC@home admin

> I'm afraid these results will never be granted credit. It's because the work
> unit has been already assimilated and the related result files (including
> canonical result) have been deleted or moved. However, these results will
> disappear from the "pending" list when the database entry is also deleted from
> the database.
>
> I admit that it's unfair that you don't credit for these successfully
> completed results.
-----
Maybe it was worth for a 'LHC@home T-shirt' ... o

> We will try to find a way to prevent this in future.
>
>

Thank you Markku for your reply (even it was 'negativ')!
So we know why those 'pending'(from over 1 month ago) will not be granted (and will disappear soon). :-(

greetz littleBouncer
BTW: Those are bad news for you too PoorBoy, aren't they?

BTW: Those are bad news for you too PoorBoy, aren't they?
=========

Awwwww what the hecks 4000 - 5000 credits anyway, after last years fiasco over at the Seti Site where I crunched for over a month with no credit this is just a drop in the bucket when compared to that.

Besides that I never really expected to get any Credit for them anyway, once WU's sit that long you might as well forget about any Credit for them. Thats how the new & improved Projects run anymore ... You have to crunch 2000 credits worth to get 1000 credits out of it ... ;)

>
> I admit that it's unfair that you don't credit for these successfully
> completed results. We will try to find a way to prevent this in future.
>
>

I went through my pending..... found this

reported it 2 days after I recieved it..... that's a quick response, isn't it?

---

Looks to me like a bug in the validator...

http://lhcathome.cern.ch/workunit.php?wuid=177772

It's wrong that a wu is returned 2 days after it is received but is not granted credit. Not that it's much though, but this was only last week!

Live long and crunch!

---

Paul
(S@H1 8888)
BOINC/SAH BETA

> Looks to me like a bug in the validator...

No it's not a validator bug. Validator can only validate if it has the canonical result for comparison.

It's just the over-eager file deleter program which does its work correctly in principle, but because of high redundancy currently used, some results will always be delivered after the other files have been deleted.

I'm planning to put a little delay into the file deleter. I hope that will be ready before the next big pile of work.

---

Markku Degerholm
LHC@home admin

> I'm planning to put a little delay into the file deleter. I hope that will be
> ready before the next big pile of work.

Thank you! :)

I kinda hate to drop back into "cheerleading" role, but, guys, we are still in early days...

When we were in Beta test, I predicted that when we started to do multi-projects we would see a whole new class of issues. I hate to be right all the time, but this was based on past experience.

Still, we have come a long way. We found the issue with the checkpointing and 0 CPU time, the BOINC Daemon scheduler is being worked to solve a lot of problems people were having with multi-project scheduling (though I don't think it is going to change things for me that much), and so on.

Anyway, the laws of averages say that we all were hit by the same percentage ...

---

> It's just the over-eager file deleter program which does its work correctly in
> principle, but because of high redundancy currently used, some results will
> always be delivered after the other files have been deleted.
>
> I'm planning to put a little delay into the file deleter. I hope that will be
> ready before the next big pile of work.
>

I would have thought the file deleter should not delete a file until after all outstanding results have been received or gone past the deadline and have sufficient results. I don't think a little delay is really the way to go. IMHO a check on the server state or the like would be better.

Live long and crunch!

Paul.

> > It's just the over-eager file deleter program which does its work
> correctly in
> > principle, but because of high redundancy currently used, some results
> will
> > always be delivered after the other files have been deleted.
> >
> > I'm planning to put a little delay into the file deleter. I hope that
> will be
> > ready before the next big pile of work.
> >
>
> I would have thought the file deleter should not delete a file until after all
> outstanding results have been received or gone past the deadline and have
> sufficient results. I don't think a little delay is really the way to go.
> IMHO a check on the server state or the like would be better.
>
> Live long and crunch!
>
> Paul.
>
It does check the server state. But a delay would prevent people that are 5 minutes late from not getting credit.

---

BOINC WIKI

BOINCing since 2002/12/8

> > It's just the over-eager file deleter program which does its work
> correctly in
>
> I would have thought the file deleter should not delete a file until after all
> outstanding results have been received or gone past the deadline and have
> sufficient results. I don't think a little delay is really the way to go.
> IMHO a check on the server state or the like would be better.

I believe that scientists were over-eager to get the data as soon as validated, and by mistake cleared the database so there was nothing left to compare to.
There is really nothing wrong with hw/sw.

Database was cleared late 22april or early 23april CERN time, as all my earlier results were validated and later from that batch are still pending.

For the new batch of 100k results everything is working fine.


Tony

[edit]
Sorry, its friday and ISP showtime.

> It does check the server state. But a delay would prevent people that are 5
> minutes late from not getting credit.

If only that were the problem with mine, which was returned 2 days after I received it (which is 12 days before the deadline). An over eager file deleter maybe, but in this case it definitely did not look at the server state on each of the returned or not yet returned wu's. If it had been 5 minutes late then I would understand (like a few that I have not posted about).

Oh well...in this case it's only 6 ot 7 cs.

Live long and crunch!

Paul.

> An over eager file deleter ..

hehe that rhymed

---

Will the database also be cleared as fast as the last time?

I will avoid worthless crunching....

littleBouncer

It's just the over-eager file deleter program which does its work correctly in principle, but because of high redundancy currently used, some results will always be delivered after the other files have been deleted.
==========

This does not sit well with me at all, the LHC Project justs needs to start ignoring the all Cry Baby's that instantly start Whining for more Wu's when the Server runs out of work to do ... If there's no WU's to do then there's no WU's to do, thats what the other Projects are for ...

It doesn't do anybody any good at all when the Server starts sending out Redundant Wu's that have no chance to get any Credit just to pacify the Cry Baby's ...

It's a absolute waste of my CPU Time and the Servers Resources for me to be Processing WU's that the Server has no use for anymore, that CPU Time could be better spent Processing WU's for a Project that needs the WU's done and still has a use for them ... IMO

Will the database also be cleared as fast as the last time?
I will avoid worthless crunching....littleBouncer
==========

I agree LB, since I keep a rather high amount of WU's in my Caches I'm going to keep a close eye on my pending credits & if it starts to abnormally rise again like the last time then I think it will be time to do a little Spring Cleaning and & get rid of the WU's I have left ...

I don't need to spend several more days running WU's that are not going anywhere to start with & are not needed by the Server anymore like the last time my pending credits took a leap upward ...

> Will the database also be cleared as fast as the last time?
> I will avoid worthless crunching....littleBouncer
> ==========
>
> I agree LB, since I keep a rather high amount of WU's in my Caches I'm going
> to keep a close eye on my pending credits & if it starts to abnormally
> rise again like the last time then I think it will be time to do a little
> Spring Cleaning and & get rid of the WU's I have left ...
>
> I don't need to spend several more days running WU's that are not going
> anywhere to start with & are not needed by the Server anymore like the
> last time my pending credits took a leap upward ...
>
>
>
I completely agree with you on this point !
LB

>> since I keep a rather high amount of WU's in my Caches

Perhaps you could reduce the size of your cache. If you think you might end up deleting them why not let someone else crunch them?

---

Gaspode the UnDressed
http://www.littlevale.co.uk