| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Support
Forum: Website Support
Thread: Reserve WUs (workunits) stopped filling up the stock. |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 40
|
|
| Author |
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Sorry, andzgrid, we can't help you.
|
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Hello Didactylos.
I never expected any help from you, so it is OK. As I stated right off the bat in the very first post (Jul 2, 2009 3:19:46 PM) I made to start off the thread, and I quote: "So, WCG tech group members, your ideas please as to what may have caused the "reserve" WUs to cease filling up the stock?". Of course, if any other WCG group can help with ideas, that's fine as well. Again, thanks for your time. |
||
|
|
BobCat13
Senior Cruncher Joined: Oct 29, 2005 Post Count: 295 Status: Offline Project Badges: 
|
BOINC will attempt to contact WCG at least every 3 days, regardless of any other settings. <next_rpc_delay>345600.000000</next_rpc_delay> is 4 days. Is there another option that forces contact more often? |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
andzgrid: http://catb.org/esr/faqs/smart-questions.html
BobCat13: Kevin originally set it to 3 days. I do not know why this has changed. http://www.worldcommunitygrid.org/forums/wcg/viewthread?thread=10022#100830 |
||
|
|
JmBoullier
Former Community Advisor Normandy - France Joined: Jan 26, 2007 Post Count: 3716 Status: Offline Project Badges: 
|
Let's make another try...
---------------------------------------- andzgrid, From what I can see on this site and after reading your previous posts several times you have connected your client on June 18 and on July 2 for returning the work that your machine had done. I will assume from your posts that the first connection for downloading the first batch has been done on June 4. At this date the HCMD2 work units (WUs) had actually a 14-day deadline. They were also suffering from a great difficulty to estimate their size. To solve this problem the techs have implemented a new way to chomp them into smaller WUs. Practically they introduced duration limits which make sure that a difficult WU never exceeds 8 hour, with the majority being around 4 hours in average. As this mechanism has proven to work successfully they have reverted the deadline for all HCMD2 WUs to 10 days as for all other projects at WCG. That means that from June 29 all WUs distributed by WCG servers had a deadline of 10 days (with the exception of "rush" WUs which can have shorter deadlines, but the profile of your client is such that it should not receive such WUs). The network connection interval that you have set in your client (10 days if I am right) is used by the client for computing when and how much it should request work from the servers. But on the server side your actual connection interval (14 days) is known and remembered. Therefore, on July 2 the server was unable to send you work that you would be able to return in time, hence the message that you quoted in your opening post, "Message from server: (won't finish in time)". If you cannot connect more often there is no solution at WCG. If you can connect, say, once a week, or at least less than every 10 days proceed as follows: - (re)start your Boinc client - make sure that it is connected to the network - go to the Project tab of the Advanced view - select the WCG project - click on the "Reset project" button. If this is not enough to see new WUs coming down try detaching and re-attaching to the project. Let us know the result and if it is still not OK, please do copy the message log of your client here. It is very uncomfortable for us to not know your configuration better. Good luck. Jean. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Hello JmBoullier.
The message in your (Jul 12, 2009 5:19:00 AM) post shed some light on the issue I was having and on the surrounding related areas. It prompted me to look closer at those things. The results --------------- Under WCG-client BOINC_v6.2.28: 1. Advanced > Preferences > network usage (tab), the "Connect about every" (CAE) parameter was set to a value of 14-days. I was therefore in error when I stated to the effect that the value is 10-days. 2. Advanced > Preferences > network usage (tab), the "Additional work buffer" (AWB) parameter was set to a value of 10-days and remains consistent with my assertions in my earlier posts. 3. Apparently, I confused the parameters CAE and AWB. I was not able to find any help material in WCG websites that explain the difference, if any. I assumed that they would play out to effect the same result (i.e. network connect times/freq) whichever is earlier (lower value = more frequent = more desirable) The change ---------------- I next changed the CAE value to 10-days and left the AWB value to 10-days (which is 1-day less than your stated "at least less than every 10 days". I hope my new settings would still be good). Then, I did a "Reset project" as you detailed. Result: 67 workUnits were downloaded, with each of those workUnits carrying a 10-day deadline. That 67 count is a far cry from the 4 count I previously had. So, I guess my issue appears to have been solved and with that, my thanks to you. Still in the woods? ------------------------ But, my case may not be out of the woods yet. Recall that the main issue I was having is about the idea that my machine is left without work for a great deal of time. Even if I had it wrong with the value for the sync-up times under the local preferences, the WCG server grossly under-estimated (assuming it was looking, else read signs incorrectly) the time my machine would complete work. I had numerous instances of 4-workUnit downloads -- workloads that my machine could complete in, at most (from what I understood from you) in 8hours -- workloads at which rate my machine could easily do a 12-workunit-downloads daily, thus. Looking forward --------------------- As I see it, unless the WCG server assesses a given machine's performance accurately (which, im my case, it did not after the first two sync-ups; the first two sync-ups was right on the money though), the quota given will tend to fall more on the short side than on the long one, assumimg that WCG tends to prefer (and I guess understandably so) more frequent sync-up times/periods. However, that remains to be seen. In any case, I'll keep WCG posted. For now, my thanks. . |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
I am forced to repeat my advice of using default settings or presets when the settings are not fully understood. Alternatively, if you don't understand something, just ask!
I don't understand what settings you are trying to achieve. 10 days is not one day less than 10 days. The AWB and CAE values are combined (to use your terminology). You are trying to request up to 20 days, which is not permitted. Your problem remains a problem with your settings, and not a problem with the server. I hope you will take our advice and reduce your combined AWB and CAE settings such that you do not risk missing deadlines and damaging your quota and/or performance statistics. |
||
|
|
Ingleside
Veteran Cruncher Norway Joined: Nov 19, 2005 Post Count: 974 Status: Offline Project Badges:
|
Hello JmBoullier. The message in your (Jul 12, 2009 5:19:00 AM) post shed some light on the issue I was having and on the surrounding related areas. It prompted me to look closer at those things. The results --------------- Under WCG-client BOINC_v6.2.28: 1. Advanced > Preferences > network usage (tab), the "Connect about every" (CAE) parameter was set to a value of 14-days. I was therefore in error when I stated to the effect that the value is 10-days. No wonder you've never got anything except wu's with a 14-day-deadline, since as long as you've been running with "Connect about every" = 14 days, you've basically told BOINC "Don't send me any work with less than 14 days deadline. Since AFAIK all new WCG-work now uses a 10-day deadline, you'll only get more work in case of idle cpu with so large connect-setting. Not sure with v6.2.xx, but with a 10-day deadline, chances are that any "Connect about every N days" > 9 days will immediately force client to run in "High priority"-mode, and if not mis-remembers v6.2.xx will block work-request to any project that runs "High priority", except idle cpu... 2. Advanced > Preferences > network usage (tab), the "Additional work buffer" (AWB) parameter was set to a value of 10-days and remains consistent with my assertions in my earlier posts. The total cache-size is the sum of both, so you're in practise been asking for 24 days of work, something that of course is impossible to give as long as all WCG-work has 14 days or shorter deadline. 3. Apparently, I confused the parameters CAE and AWB. I was not able to find any help material in WCG websites that explain the difference, if any. I assumed that they would play out to effect the same result (i.e. network connect times/freq) whichever is earlier (lower value = more frequent = more desirable) WCG runs a heavily-customized web-pages, this most likely means any BOINC-changes must manually be customized before they're being added. Probably from around the launch of v6.2.xx (or possibly v6.4.xx), the full BOINC-text for the preferences are: Computer is connected to the Internet about every N days. (Leave blank or 0 if always connected. BOINC will try to maintain at least this much work.) Maintain enough work for an additional N days. Enforced by version 5.10+  "I make so many mistakes. But then just think of all the mistakes I don't make, although I might." |
||
|
|
nasher
Veteran Cruncher USA Joined: Dec 2, 2005 Post Count: 1423 Status: Offline Project Badges:
|
is there a reason you only have your computer connect to BOINC and WCG every 14 days?
----------------------------------------personaly i have mine set real low .1 days or so so i dont have this type of problem if you can have (and are willing to have) your computer connect more often you might want to go and setup the project to do just that. If you can only connect every 10-14 days then i am sorry i do not have any idea on how to fix your problem  |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Hello WCG.
Attention: JmBoullier (your Jul 12, 2009 5:19:00 AM) post Ingleside (your Jul 18, 2009 9:18:53 PM) post nasher (your Jul 22, 2009 7:23:02 AM) post WCG tech/CommunityAdvisors Gentlemen: My main issue is that my machine runs out of workUnits before the sync-up deadline. In search for a solution to that main issue, I need to know and understand the things that go into defining the WUs that are sent to any user in a WCG sync-up session. It just happened that WU_buffers, connectTimes, WU_duration, and all those things are some of the involved parameters. I had tried the 10-days, and the 14-days as the value for the "Connect about every" (CAE) parameter, but I still have the main issue that prompted me to start (my Jul 2, 2009 3:19:46 PM) post. Let us focus in WU runtimes. ------------------------------------ 1. What determines when a given WU's execution ends? Is this control coded in the WU itself? 2. Is there a mechanism somewhere that reads a machine's crunch-capacity and from there adjusts a WU execution runtimes so that the machine is not left idle where it could do more crunching, or end a WU if the deadline for a WU is at risk of not being met? If there is no such mechanism, I suggest that this mechanism be made. I take it that a WU fashioned for public crunching, would likely need to go through many batches of crunching before the data (the WU is crunching on) may be considered usable by the end-user (scientist, etc.), or before the WU is deemed for pullout from public crunching. If the above mechanism is in place, then the said WU may be cycled back to the cruncher-user for next-round crunching should the WU need furthur crunching (but is ended otherwise), and the machine was earlier correctly assesed by the mechanism as having (what would otherwise be unused/idle) capacity to do the crunch and still meet the deadline. 3. Failing the availability of the above mechanism, I suggest that the WCG server do the equivalent functionality during sync-ups. For this, the server needs to extrapolate past performance of a user's machine as well as be governed by current settings and use the insight gained there to meter the amount of WUs, their runtimes, and the like before clearing the WUs for upload to a user. Why idle? Why not connect and get WU? --------------------------------------------------- If I could get online daily, all the above issues are rendered unimportant else moot. But, as I have said before, my situation is not that ideal: I cannot get online as often as necessary to get my stock/buffer filled up in a WCG sync-up. If the WCG server would only read my machine's recent-past performance, it would not hand me out WUs that load my machine up to only 25% to 30% regardless of the setting (10-day or 14-day) I have for the "Connect about every" CAE parameter. Or, if only there is a way to sync-up via an intermediary device, say via a USB thumbDrive, and that would help too. The latest sync-up ------------------------ I uploaded the 60+ WUs from the earlier sync-up and got a download of less than 60 WUs for today's sync-up. The earlier batch of (60+) WUs represented up to 33% workload for my machine. That is, 66% of the crunching power of my machine would have been not used had I not gone online today. Another way to put it is that, had I not gone online today and sync-up with WCG, my machine would not have been doing crunching until the 10-day deadline, with WCG unable to tap 66% of the available power. Setting the sync-times to shorter times, say 1-day, does not play out to have WCG give my machine enough WU to last 1-day, and that is the problem that I hope I have stated clearly. Again, and this takes me back to a subject not far nor unrelated to the the same subject as my first post of this thread, and I quote: "Reserve WUs (workunits) stopped filling up the stock." I am still hoping for a solution. Thanks. . |
||
|
|
|