LHC@home

dunno what happened here , never thought i'd be saying 'too much'.
My amd xp2100 linux machine requested 864 seconds of work and got 68 w.u..

lets see @ 2hrs ~ thats 126 /24 = 5 days

24 hours to spare, should be ok {as long as burp or pirates dont feed that p.c. too}

gotta love Alpha projects, lol, j.k..

I'm sure the fault is all in My pc, the old cruncher just trying to make me happy :D

This p.c. errored out all the LHC wu it recieved this summer { thats why its 'connect every is .01 days' }.
I either fixxed the 'hang' problem it had or it's running good because it's -25c

---

dunno what happened ...
This p.c. errored out all the LHC wu it recieved this summer { thats why its 'connect every is .01 days' }.

Sure it errored them all?

My best guess is that you had a few short successes, you know the kind of WU that runs for 12sec then finishes early for a good science reason, like the beam hits the wall of the tube in the sim.

On the figures you give, the server reckons your box will take just under 13sec per WU. It might just be a bit over optimistic ;) but the figure must have come from somewhere. Hence my guess that that box has had a run of 7 to 15 sec jobs and the client has "learned" from the past.

I've just had the same happen - one of my boxes grabbed 150 days work - ok it has 2 cpus so it is really "only" 75 days worth. On Sunday I will have to prune it drastically (sorry everyone I won't have time today).

If you find your box cannot meet the deadline after it has run the first few of those 68 tasks, it would be friendly to the project and to other participants to give them back. If you have time, please do the following

1) work out how many it is realistic to keep
2) abort the appropriate number of tasks, working down the list in the work tab from the one under the current running task - this is because you want them to be processed as aborted as soon as possible
3) wait for current running task to finish, and check that the aborted tasks are processed as aborted.
4) update LHC from the project tab to force immediate reporting of the aborted tasks.

The sooner you get to step 4, the sooner someone else can start to crunch those tasks. Obviously keep what you can use, but it is project-friendly to return the rest early so that the scheduler does not have to wait for the deadline to re-issue them. It is participant friendly as the scheduler will re issue that work to some lucky participant who checks in for more work a few minutes after you send it back.

When I get time to sort out my box, I intend to keep enough so that I run out of work between 12 and 36 hours before the deadline, and give the rest back.

If you despite the above, you find you get close to or past the deadline and still have a significant backlog, the easiest thing to do at that point is to reset the project. There is very little point processing after the deadline.

Best regards,
River~~

---

yup they all died, so did every seti simap etc etc etc,
either because i spoke or because i opened the heat vent wu#2 'hung me' {it resumed ok} this wu is heading towards a 3 hour time tho so I was going to turf 30 or so ( wish I could send them to 1 of these other machines :) )

I don't believe a reset should be nesc. as the schedualar bumps up in one step the completion estimate

I did note that on this end completion estimate was ~1 hour before the first wu completed , now its 2:17

I sent back them wu's & I'll check it again when I get up.

13 seconds on a pc benching 878/1504 'optimistic'

p.s. These boards realy need a preview I always seem to need edit (im on the wrong machine this is firefox 1.x still and doesn't spellcheck like 2.x

---

Hmmm hung me twice (woke me up cuz the fan slowed down) funny i can hear it over all the others)

gave back another dozen

---