| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Support
Forum: GPU Support Forum
Thread: BOINC and new <fetch_on_update> in soon to come 7.0.54 (with a Q-mark) |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 25
|
|
| Author |
|
|
Crystal Pellet
Veteran Cruncher Joined: May 21, 2008 Post Count: 1403 Status: Offline Project Badges: 
|
... Exiting the client, stopping the daemon and restarting made it run again. Sunday's test on first Linux build of 7.0.54 was different. On restart the tasks resumed but then after a minute all running tasks were put in ""Scheduler wait: Waiting to acquire lock" and new tasks were started and ran properly. No amount of trying got them running again, until I upgraded to a new 7.0.54 build, and suddenly these tasks resumed. So when you get to try 7.0.55 and stay with it on Linux, be aware!... I had the same with a Test4Theory task and reported it to the devs. Reboot solved it. It was a XML parsing bug and should be solved in 7.0.55. Another strange thing is the asking for new work after update (fetch_on_update set), but with suspended tasks. In earlier versions you never get tasks when you even have 1 suspended task, but now you get until the minimum buffer is filled the suspended ones not counting ?? I asked whether this new feature should be fixed in 7.0.55 (no answer), but it isn't. [Edit 1 times, last edit by Crystal Pellet at Mar 12, 2013 11:56:22 AM] |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
hmmm, that's a regression to an early 5.xx version where suspended tasks were not counting, but work fetching could still be forced up to the point of buffer setting and thusly you could keep pumping WUs by suspending new work on and on. Agree, for consistency, the message should have been issued "no new work: tasks suspended for project" or whatever the exact language is.
Could be that Gianfranco already fixed the tag in his second build of 7.0.54. Certainly did not boot. But, the other main alert is the client crunch stopping [on Linux] when clock is set back and continuing to show as "Running". That's bad. If it repeats with 7.0.55 and others see same, simply change timezone from for instance CET to GMT or UTC [who knows has it always been a related tag issue], it will go to the alpha mail list. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
As I commented earlier, targeted for general public release after a 14 testing stay, 7.0.56 is now out for all major platforms, Android meant to become one too.
http://boinc.berkeley.edu/dev/forum_thread.php?id=6698&postid=48187 http://boinc.berkeley.edu/dev/forum_thread.php?id=8203&postid=48188 Go and test, and pretty please test clock time set back too to see if computing freezes. cheers P.S. My duo 32 bit is running it now... smooth "upgrade over" without any manual stopping / starting... all by itself. P.P.S, get a first go to test a potential WCG candidate with these mod notes: MGR: Modify the GUI for the Attach to Project Wizard for the World Community Grid version of the client. These changes should make clearer the difference between attaching to a new BOINC project vs changing which applications a user is choosing to run at World Community Grid. MGR: Further modifications to the World Community Grid installer and skin for BOINC 7. |
||
|
|
deltavee
Ace Cruncher Texas Hill Country Joined: Nov 17, 2004 Post Count: 4894 Status: Offline Project Badges: 
|
Go and test, and pretty please test clock time set back too to see if computing freezes. Windows 8. 7.0.56. Set the clock back and got this.: 3/14/2013 5:19:28 AM | | System clock was turned backwards; clearing timeouts Crunching paused but restarted when clock was set back up. hcc-gpus were not reset but continued with their previous elapsed time. Also app_config was read without having to stop and restart Boinc Manager.  |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Seems from a reply, the bug has been lingering since version 5.10.45 or as it ended with a diagnostic
If benchmarks have been run in the future (as envisioned by changeset [12128], lines 247-248), this static variable will be pre-initialised to some time in the indefinite future. The test at line 312 will always be satisfied, and the application hangs, by indefinite looping. Figure that, and wonder how many encounter this when DST ends. Nicolas [a developer of the Synecdoche BOINC branch] gave a link to a little Linux program to be at least notified of the clock change. http://lwn.net/Articles/432395/ At any rate, I have to watch this issue every time I dual boot from Windows to Linux and when then going back to Windows, low and behold, the clock shows 1 hour earlier, another "Figure that". For now, I've set DST to manual so that the clock does not change out-with my control. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
BTW, Locutus has a 7.0.56 version build in his ppa for Linux interestees too test, and have an easy install. https://launchpad.net/~costamagnagianfranco/+archive/locutusofborg-ppa
|
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
We have a reply by the Lord of BOINC, Dr. Anderson.
I checked in changes to the client so that it will continue to operate normally when the system clock is changed. These will appear in the next release. The Manager, however, essentially stops working for X seconds when the system clock is set back by X. This will be fixed at some point, but not immediately. Note: there should be no need to change your system clock when you move between time zones. System clock (seconds since 1970 UTC) is independent of time zone. Time zone just affects its human-readable display. -- David From history, if the OS clock was changed by more than 30 seconds, longer versions ago, tasks would reset to previous checkpoint, if there was one. Not nice if you ran CEP2 e.g. Then this was changed to just reset the counters, the message that deltavee saw. What David is saying is, that when you set the clock back by 1 hour, 3600 seconds, computing halts for 3600 seconds until the original time is reached again. I've never paid attention to this much since the last fix, but come October when DST is reversed there could be an issue for some or many. Maybe this only comes to light in a dual boot environment, but one of two is changing the clock in the BIOS. Certainly I was tired of the dual boot situation when each time going back to Windows the clock would be 1 hour early, set it forward, and then when going to Linux, the clock was again added an hour, so the clock was set back manually, to cause the computing freeze. To me there's an inconsistency the way the OSses handle time, and BOINC not responding well to this. Will resume testing when 7.0.57 or whatever next version comes out... hoping it will still make it into the coming public release as WCG will be holding on to that version for a longer time as the endorsed version. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Now there we have it, 3 sets of commits to git to include good old heartbeat getting a once-over, just because of a clock issue :D:
8 hours ago- Client: debug last commit. commit | commitdiff | tree David Anderson [Fri, 15 Mar 2013 08:03:01 +0100 (00:03 -0700)] - Client: debug last commit. Also fix bug where benchmarks don't end when clock goes backward. 11 hours ago- client: a couple of more clock-change fixes commit | commitdiff | tree David Anderson [Fri, 15 Mar 2013 05:03:24 +0100 (21:03 -0700)] - client: a couple of more clock-change fixes 11 hours ago- client: there were many places in the code where we keep track commit | commitdiff | tree David Anderson [Fri, 15 Mar 2013 04:43:29 +0100 (20:43 -0700)] - client: there were many places in the code where we keep track (usually in a static variable called "last_time") of the last time we did something, and we only do it again when now - last_time exceeds some interval. Example: sending heartbeat messages to apps. Problem: if the system clock is decreased by X, we won't do any of these actions are time X, making it appear that the client is frozen. Solution: when we detect that the system clock has decreased, set a global var "clock_change" for 1 iteration of the polling loop, and disable these time checks if clock_change is set. Looking forward to the next test build and see if we can break it [cosmetics not considered at this stage as showstopper] ;) |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Thanks for keeping us updated on the advancements in BOINC.
Last I saw (admittedly did not look too deeply) there were issues with doing a clean install on Win8 ... any better yet? |
||
|
|
deltavee
Ace Cruncher Texas Hill Country Joined: Nov 17, 2004 Post Count: 4894 Status: Offline Project Badges:
|
Last I saw (admittedly did not look too deeply) there were issues with doing a clean install on Win8 ... any better yet? I had no problems putting 7.0.56 on Windows 8. |
||
|
|
|