Message boards :
Number crunching :
no more work?
Message board moderation
Previous · 1 · 2 · 3 · 4 · 5 · Next
Author | Message |
---|---|
![]() Send message Joined: 23 Jan 07 Posts: 3 Credit: 13,331,737 RAC: 0 ![]() ![]() |
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 ! |
![]() Send message Joined: 25 Jan 11 Posts: 179 Credit: 83,858 RAC: 0 |
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. 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? |
![]() ![]() Send message Joined: 22 Sep 09 Posts: 12 Credit: 2,864,703 RAC: 0 ![]() ![]() |
+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. |
![]() ![]() Send message Joined: 22 Sep 09 Posts: 12 Credit: 2,864,703 RAC: 0 ![]() ![]() |
It's running again! But the WUs are very short just a poet. |
Send message Joined: 14 Oct 11 Posts: 1 Credit: 14,291 RAC: 0 |
It's running again! I've had a bunch of 6-7 second units roll through, short is an understatement. |
Send message Joined: 19 Nov 09 Posts: 6 Credit: 259,750 RAC: 0 |
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. |
![]() Send message Joined: 25 Jan 11 Posts: 179 Credit: 83,858 RAC: 0 |
You have 12 Sixtrack tasks in your cache. The server won't allow you more than 12. |
Send message Joined: 19 Nov 09 Posts: 6 Credit: 259,750 RAC: 0 |
I guess I didn't explain very clearly. I don't have any in the queue. Four tasks, all running. That's all. |
![]() Send message Joined: 25 Jan 11 Posts: 179 Credit: 83,858 RAC: 0 |
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. |
![]() ![]() Send message Joined: 22 Sep 09 Posts: 12 Credit: 2,864,703 RAC: 0 ![]() ![]() |
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. |
Send message Joined: 19 Nov 09 Posts: 6 Credit: 259,750 RAC: 0 |
jujube - thanks for the explanation. Nick |
![]() ![]() Send message Joined: 23 Oct 04 Posts: 358 Credit: 1,439,205 RAC: 0 |
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^^ |
Send message Joined: 2 Sep 08 Posts: 5 Credit: 121,460 RAC: 0 |
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? 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). |
Send message Joined: 25 Jul 05 Posts: 19 Credit: 670,692 RAC: 0 |
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? |
Send message Joined: 25 Jul 05 Posts: 19 Credit: 670,692 RAC: 0 |
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? |
Send message Joined: 23 Sep 11 Posts: 1 Credit: 24,990 RAC: 0 |
...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. |
Send message Joined: 17 Feb 07 Posts: 86 Credit: 968,855 RAC: 0 |
Server page is showing: tasks ready to send 0, so no new work at the moment. Greetings from, TJ |
Send message Joined: 12 Jul 11 Posts: 857 Credit: 1,619,050 RAC: 0 |
Hi Ralph; see my latest statu report. One I can't keep up and two, don't want to waste resources. Eric. |
Send message Joined: 15 Oct 11 Posts: 3 Credit: 1,292,103 RAC: 0 |
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? |
![]() Send message Joined: 25 Jan 11 Posts: 179 Credit: 83,858 RAC: 0 |
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 |
©2024 CERN