Scheduler bug with aborted wu's

Message boards : BOINC client : Scheduler bug with aborted wu's
Message board moderation

To post messages, you must log in.

AuthorMessage
Mibe, ZX-81 16kb

Send message
Joined: 22 Nov 05
Posts: 6
Sweden
Message 1197 - Posted: 27 Nov 2005, 13:31:38 UTC
Last modified: 27 Nov 2005, 13:52:06 UTC

If you abort a wu before it has started the scheduler doesn't recognize it until the next "Switch between applications every"-period. I have mine set to 180 minutes and the scheduler takes 180 minutes between each aborted wu. This is a complete waste of cpu time since no work is done during this period.

I'm using BOINC 5.2.5.

[edit] changed interrupted to aborted [/edit]

Log:
2005-11-27 08:32:33||Starting BOINC client version 5.2.5 for windows_intelx86
2005-11-27 08:32:33||libcurl/7.14.0 OpenSSL/0.9.8 zlib/1.2.3
2005-11-27 08:32:33||Data directory: E:\\Program\\Www\\BOINC
2005-11-27 08:32:33|SETI@home|Found app_info.xml; using anonymous platform
2005-11-27 08:32:33||Processor: 1 AuthenticAMD AMD Athlon(tm)
2005-11-27 08:32:33||Memory: 511.48 MB physical, 609.35 MB virtual
2005-11-27 08:32:33||Disk: 103.58 GB total, 8.25 GB free
2005-11-27 08:32:33|Einstein@Home|Computer ID: 308646; location: home; project prefs: default
2005-11-27 08:32:33|LHC@home|Computer ID: 44941; location: 6857.3; project prefs: default
2005-11-27 08:32:33|SETI@home|Computer ID: 1099446; location: home; project prefs: default
2005-11-27 08:32:33||General prefs: from SETI@home (last modified 2005-10-31 17:54:28)
2005-11-27 08:32:33||General prefs: no separate prefs for home; using your defaults
2005-11-27 08:32:33||Remote control not allowed; using loopback address
2005-11-27 08:32:33||Suspending work fetch because computer is overcommitted.
2005-11-27 08:32:33||Using earliest-deadline-first scheduling because computer is overcommitted.
2005-11-27 08:32:33|LHC@home|Unrecoverable error for result wjun4nmC_v6s4hhpac_mqx-nm__20__64.302_59.312__8_10__6__80_1_sixvf_boinc85391_2 (Aborted via GUI)
2005-11-27 08:32:33|LHC@home|Starting result wjun4nmC_v6s4hhpac_mqx-nm__20__64.302_59.312__8_10__6__80_1_sixvf_boinc85391_2 using sixtrack version 467
2005-11-27 08:32:34|LHC@home|Computation for result wjun4nmC_v6s4hhpac_mqx-nm__20__64.302_59.312__8_10__6__80_1_sixvf_boinc85391_2 finished
2005-11-27 08:32:38|LHC@home|Deferring communication with project for 54 seconds
2005-11-27 11:32:33|LHC@home|Unrecoverable error for result wjun4nmC_v6s4hhpac_mqx-nm__20__64.302_59.312__8_10__6__5_1_sixvf_boinc85376_0 (Aborted via GUI)
2005-11-27 11:32:33|LHC@home|Starting result wjun4nmC_v6s4hhpac_mqx-nm__20__64.302_59.312__8_10__6__5_1_sixvf_boinc85376_0 using sixtrack version 467
2005-11-27 11:32:34|LHC@home|Computation for result wjun4nmC_v6s4hhpac_mqx-nm__20__64.302_59.312__8_10__6__5_1_sixvf_boinc85376_0 finished
2005-11-27 11:32:39|LHC@home|Deferring communication with project for 54 seconds
2005-11-27 14:32:34|LHC@home|Unrecoverable error for result wjun4nmC_v6s4hhpac_mqx-nm__20__64.306_59.316__10_12__6__5_1_sixvf_boinc85665_3 (Aborted via GUI)
2005-11-27 14:32:34|LHC@home|Starting result wjun4nmC_v6s4hhpac_mqx-nm__20__64.306_59.316__10_12__6__5_1_sixvf_boinc85665_3 using sixtrack version 467
2005-11-27 14:32:35|LHC@home|Computation for result wjun4nmC_v6s4hhpac_mqx-nm__20__64.306_59.316__10_12__6__5_1_sixvf_boinc85665_3 finished
2005-11-27 14:32:39|LHC@home|Deferring communication with project for 1 minutes and 7 seconds

ID: 1197 · Report as offensive
Keck_Komputers
Avatar

Send message
Joined: 29 Aug 05
Posts: 304
United States
Message 1204 - Posted: 27 Nov 2005, 15:51:45 UTC

I think this one finally got fixed in 5.2.8, I haven't tried it yet though. 5.2.12 is the current recommended version btw.
BOINC WIKI

BOINCing since 2002/12/8
ID: 1204 · Report as offensive
Michael Roycraft
Avatar

Send message
Joined: 24 Nov 05
Posts: 129
United States
Message 1205 - Posted: 27 Nov 2005, 15:54:35 UTC
Last modified: 27 Nov 2005, 15:58:47 UTC

Mibe,

I don't see in the readout that you Updated a project, or Suspended one. I think that if you select the project (the one on which you've aborted the workunit) on the "Projects" tab, and click the Update button on the left, that it will resume working on the next WU for that particular project. If you instead click the Suspend button while that project is selected/highlighted, Boinc should show that project activity suspended and immediately begin work on the next project. I know, this doesn't happen automatically and requires a tiny bit of operator intervention, but that shouldn't be a problem. After all, manually abortng a workunit required your intervention, too.

BTW, 3 hours between switching projects is a rather long interval.

Michael

(edit) I see that John was quicker at composing a reply. Thanks, John 8-)
"The arc of history is long, but it bends toward Justice"
ID: 1205 · Report as offensive
Mibe, ZX-81 16kb

Send message
Joined: 22 Nov 05
Posts: 6
Sweden
Message 1208 - Posted: 27 Nov 2005, 18:39:33 UTC
Last modified: 27 Nov 2005, 18:40:51 UTC

Thanks for your help. I'll try out 5.2.12 and see if it works.

I can't see how a high switching time can be too long. So I'll stick with 180 minutes.

[edit] I didn't copy all the messages. The abort was done yestereday. I didn't suspend it. [/edit]
ID: 1208 · Report as offensive
Profile Andrew Hingston

Send message
Joined: 25 Nov 05
Posts: 55
United Kingdom
Message 1209 - Posted: 27 Nov 2005, 18:47:19 UTC - in response to Message 1208.  

I can't see how a high switching time can be too long. So I'll stick with 180 minutes.


I agree that this should not cause any problems. Long switching times are pretty well essential for those opting not to leave apps in memory when preempted.

ID: 1209 · Report as offensive
Michael Roycraft
Avatar

Send message
Joined: 24 Nov 05
Posts: 129
United States
Message 1212 - Posted: 27 Nov 2005, 21:19:43 UTC - in response to Message 1209.  
Last modified: 27 Nov 2005, 21:20:03 UTC

I can't see how a high switching time can be too long. So I'll stick with 180 minutes.


I agree that this should not cause any problems. Long switching times are pretty well essential for those opting not to leave apps in memory when preempted.

I think may I didn't make it very clear. He's remarked that 3 hours was too much time to waste, not crunching. If nothing is found to correct the problem, at least shortening the switching time would cut the waste, no?

"The arc of history is long, but it bends toward Justice"
ID: 1212 · Report as offensive

Message boards : BOINC client : Scheduler bug with aborted wu's

Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.