LHC@home

Ahhrrrgg !!! No more WU !!!
What's the hell !!!! I cannot wait longer !!!

.
.
.
.

Just kinding ! xD (Obviously)
Hope this batch went well !
Looking forward the new one !

Keep crunching !

Reducing the deadline to 5 days would not eliminate hosts with a 6.6 day turnaround time as Gary R. seems to think. Those hosts would still receive tasks if the scheduler thinks they are able to complete the tasks before the deadline. I doubt that any of the hosts attached to this project needs more than 4 days to crunch a Sixtrack task so there is no reason a 5 day deadline wouldn't work for everybody.

You'd be correct if all computers run 24/7... With a deadline of 5 days and a turnaround of 6.6 days, you'll have a lot more tasks to resend

Not necessarily. A turnaround of 6.6 days doesn't mean the host takes 6.6 days to crunch a task, it just means the host doesn't return the task for 6.6 days, probably because it sits in the host's cache for 4 days before the host even starts it. With a 5 day deadline, tasks won't sit around in caches for so long, that's all.

and the scheduler won't send any new task to those computers that run, e.g. 12 hs 5 days a week. If someone downloads a task in a Friday, and doesn't run it Saturday and Sunday, will have only 3 days to the deadline. A bigger chance to not get it completed in time... And one more task to resend. And another user excluded.

BOINC keeps track of how many hours per day a machine is turned on, how many of those "on hours" BOINC is allowed to crunch, and takes that into consideration when scheduling work. As long as the machine in your scenario can complete a Sixtrack task in 3 days it'll get Sixtrack tasks. I would say even the slowest computer here can likely do a task in 3 days though it might have to crunch that task non-stop for 2.5 days to do it. But suppose you're right and the scheduler refuses to get Sixtrack work for the machine, thinking it can't meet the deadline. Why should Sixtrack cater to that owner and keep the deadline at 7 days? Why shouldn't that machine be excluded? Sixtrack doesn't owe work to anybody. By excluding machines that can't do a task in 5 days and sending the work instead to a machine that does a task in 1 day, the batch of WUs will be finished sooner. If that's what the project wants then why should they not have it?

+1

for all in this thread:
I understand these problems: deadline, number of days of crunch, etc...
personally, I run LHC carefully and sent all my tasks (1 in pending), and I wait...

---

just a poet.

It's running again!
But the WUs are very short

---

just a poet.

It's running again!
But the WUs are very short

I've had a bunch of 6-7 second units roll through, short is an understatement.

11/2/2011 2:07:28 PM | LHC@home 1.0 | (reached limit of 12 tasks in progress)

I keep getting this message though I don't have any WUs waiting. I have a Qual Core system and all the cores are occupied but I can't seem to download any "spares". I've reset the project but it still does the same thing.

You have 12 Sixtrack tasks in your cache. The server won't allow you more than 12.

I guess I didn't explain very clearly. I don't have any in the queue. Four tasks, all running. That's all.

Look at the list of tasks for your quad core here on the website. The server thinks you have 12 tasks in your cache, possibly because you didn't abort cached tasks before reseting. There is nothing you can do except wait for those tasks to timeout on the server.

there are longer WUs too (45mn on my PC), but effectively there are very short tasks too (valid or pending).
Sorry for my english

---

just a poet.

jujube - thanks for the explanation.

Nick

Something is wrong calculated with the turnaround time. Because none of my 2 hosts had more than 1.5 days for returning the task (Check here) , but they have 2.07 and 2.17). 2 Days before they had 2.07 and 1.81 with 3 pending. 2 pending are done by slower users and that gave for that computer then 2.17 (before it was 1.81). Why?

It seems to me that the turnaround time is calculated when both tasks are returned ((Time from last WU returned(of the 2 crunchers)) - (Time when the WU was sent)) and that is incorrect!

My correct turnaround Time is ((time when it is back)-(time when it was sent))

Sorry it's hard for me to explain, I hope you unterstand what I want to say^^

greetz littleBouncer
BTW: both machines have now work to crunch^^

Something is wrong calculated with the turnaround time. Because none of my 2 hosts had more than 1.5 days for returning the task (Check here) , but they have 2.07 and 2.17). 2 Days before they had 2.07 and 1.81 with 3 pending. 2 pending are done by slower users and that gave for that computer then 2.17 (before it was 1.81). Why?

It seems to me that the turnaround time is calculated when both tasks are returned ((Time from last WU returned(of the 2 crunchers)) - (Time when the WU was sent)) and that is incorrect!

My correct turnaround Time is ((time when it is back)-(time when it was sent))

Sorry it's hard for me to explain, I hope you unterstand what I want to say^^

greetz littleBouncer
BTW: both machines have now work to crunch^^

Your computer with turnaround of 2.17 days had it's last task validated in Nov. 2, and this task had been returned by your computer in almost 3 days. So the average turnaround has increased (only already validated WU's are used in this calculation).

Still there seems to be something wrong i think, i went from 1.05 days to 0.3 days in less then 1 day. (Computer = http://lhcathomeclassic.cern.ch/sixtrack/show_host_detail.php?hostid=9931831) Most WU's have a turnaround time of 12 hours+, today there where a few shorter WU's but i do not think that based on a few WU's that my avarage should be so low. Maybe the avarage turnaround time only looks at the last 10? or so WU's? Or the avarage of 1.05 days off all WU's is being recalculated by getting avarage plus the latest WU runtime dived by 2?

---

After returning 1 WU with a return time of around 12 hours the avarage is 0.59, could it be based on the last reported WU only?

---

...same problem here. I had to detach and reattach o project.
After that I saw:
Mon 07 Nov 2011 10:59:12 PM CET LHC@home 1.0 Scheduler request completed: got 1 new tasks
Mon 07 Nov 2011 10:59:15 PM CET LHC@home 1.0 Started download of sixtrack_530.10_i686-pc-linux-gnu.exe
Mon 07 Nov 2011 10:59:15 PM CET LHC@home 1.0 Started download of w3mass5_lhc500_00__10__s__64.28_59.31__14_16__5__9_1_sixvf_boinc5139.zip
Mon 07 Nov 2011 10:59:17 PM CET LHC@home 1.0 Finished download of w3mass5_lhc500_00__10__s__64.28_59.31__14_16__5__9_1_sixvf_boinc5139.zip
Mon 07 Nov 2011 10:59:20 PM CET LHC@home 1.0 update requested by user
Mon 07 Nov 2011 10:59:23 PM CET LHC@home 1.0 Sending scheduler request: Requested by user.
Mon 07 Nov 2011 10:59:23 PM CET LHC@home 1.0 Requesting new tasks for GPU
Mon 07 Nov 2011 10:59:24 PM CET LHC@home 1.0 Scheduler request completed: got 0 new tasks
Mon 07 Nov 2011 10:59:24 PM CET LHC@home 1.0 Message from server: No work sent

Then, that message seems a bit strange, but it is normal
Mon 07 Nov 2011 10:59:26 PM CET LHC@home 1.0 Finished download of sixtrack_530.10_i686-pc-linux-gnu.exe

After a while, it resumed calculations:
Mon 07 Nov 2011 11:09:42 PM CET LHC@home 1.0 Starting w3mass5_lhc500_00__10__s__64.28_59.31__14_16__5__9_1_sixvf_boinc5139_1
Mon 07 Nov 2011 11:09:42 PM CET LHC@home 1.0 Starting task w3mass5_lhc500_00__10__s__64.28_59.31__14_16__5__9_1_sixvf_boinc5139_1 using sixtrack version 53010

I just hope things will go smooth for you as well.

Server page is showing: tasks ready to send 0, so no new work at the moment.

---

Greetings from,
TJ

Hi Ralph; see my latest statu report. One I can't keep
up and two, don't want to waste resources. Eric.

---

I haven't seen any tasks in 5 days now, server status shows 0 to send, but 3k to now 15k in progress. Something strange going on?

Nothing strange going on. The secret to understanding what you are seeing is to realize that the project status page is NOT refreshed every time you click on the link to the project status page. The page is cached which means that the page is refreshed every once in a while and a copy of the page is saved (cached) and sent to anyone who clicks the link before the next time the page is refreshed. When you click the project status link you receive the cached page which probably was refreshed several minutes ago which means it probably doesn't show the true number of "Tasks ready to send". So what can happen is:

1) the status page refreshes when there are 0 tasks ready to send and 3,000 tasks in progress
2) 5 minutes later you click the link and see 0 tasks ready to send and 3,000 in progress
3) 5,000 tasks are put into the ready to send queue
4) the 5,000 tasks put into the queue in 3) are gobbled up by the thousands of machines requesting Sixtrack tasks which leaves 0 tasks ready to send and 8,000 in progress
5) the status page refreshes again and since there are 0 tasks in the queue, the cached page shows 0 tasks ready to send and 8,000 in progress
6) you click the project status link and see the *cached* numbers which are 0 and 8,000