Thread '5.10.20 - uploading but not reporting'
Message boards : BOINC client : 5.10.20 - uploading but not reporting
Message board moderation
| Author | Message |
|---|---|
|
Send message Joined: 2 Dec 06 Posts: 69 
|
I upgraded to the new default version today. 5.10.13->5.10.20 I'm on DSL so I have my local preferences set to connect every 0 days, and additional work buffer is 2 days. This worked fine on 5.10.13... It would finish a WU, upload it, and contact the host to report it. On 5.10.20, it finishes the WU, uploads it, and stays in the "ready to report" state until I manually tell it to contact the BOINC project server for that WU or it decides to get more work and reports it as part of the request for more work. I don't have a cc_config.xml file. My global_prefs_override.xml file contains
Here's the log file since the conversion:
ID: 12288 ·  |
 Send message Joined: 29 Aug 05 Posts: 304
|
A small but non-zero connect interval seems to work better than zero, for example 0.01. That way the transfer is completely finished before the client tries to report it. BOINC WIKI   BOINCing since 2002/12/8 ID: 12290 · |
 KSMarksPsych Send message Joined: 30 Oct 05 Posts: 1239
|
And I think David (or it might have been Rom) changed the code slightly so that a CI of zero won't report results immediately. I'd have to check the change log to see where that came into play. Kathryn :o) ID: 12296 · |
|
Send message Joined: 8 Jan 06 Posts: 36
|
Yes, all the versions after 5.10.13 will sit on the report for a day, regardless of whether you have the CI set to less than that. Personally, I think this is a bad idea. The fact of the matter is when you decouple and set the CI to a value less than the Cache setting, the user has explicitly told BOINC, "No, I DO NOT want you sitting on reports for longer than this amount of time" (among other things). I'm tired of hearing the arguments of "Oh we have to do this in order to make better use of backend resources.... yada, yada, yada". I've heard it suggested it's not a problem, because most hosts will come looking for work before the contact override times out. While that may be true, it makes the assumption that all hosts are fast, run 24/7, and/or have unfettered internet connection times. It also neglects to take into account a user may prefer to not have the fate of their completed work hinging on the integrity of an active working file like the client_state, which can get messed up for any number of reasons not even related to a BOINC malfunction per se. The fact of the matter is that if a project has a problem with hosts 'pestering' it too frequently, the appropriate answer is for them to tell the Client during a contact session, "Oh BTW, I would like it if you would not contact me again about your work state situation for X amount of time". It is not my hosts problem if a project chooses to 'overbook' their backend's capacity to deal with the volume of work they have in progress, or appropriate to have the CC override by default in all cases the manner which the people who donate their computing resources to a project choose to have their machines behave. Alinator. ID: 12301 · |
 Send message Joined: 14 Feb 06 Posts: 139
|
Agreed! That is why I will stick with 5.10.13 (and 5.10.10 for the Mac), until forced to change. FWIW, the change came with 5.10.14. It is this line in the change log: - client: allow up to a day (rather than work_buf_min()) to elapsed between completing a result and reporting it. Reno, NV Team: SETI.USA 
ID: 12306 · |
|
Send message Joined: 16 Apr 06 Posts: 386 
|
Does this delayed reporting feature take into account the deadline on the tasks? I'm thinking of a few recent projects with very short deadlines (APS - 3days, and WCG/AfricanComputingAtHome - less than 24 hours). ID: 12307 · |
Jord Send message Joined: 29 Aug 05 Posts: 15573 
|
The Work scheduler is still in effect. Tasks with a short deadline will be reported before their deadline. ID: 12308 · |
|
Send message Joined: 16 Apr 06 Posts: 386
|
That's good to know, thanks. ID: 12315 · |
|
Send message Joined: 6 Sep 07 Posts: 1 |
/me reverts to 5.10.13 and parks projects requiring later versions get detached. ID: 12323 · |
|
Send message Joined: 2 Dec 06 Posts: 69
|
Agreed! That is why I will stick with 5.10.13 (and 5.10.10 for the Mac), until forced to change. Agreed. What an annoying change. Does anyone know why this was done? ID: 12324 · |
|
Send message Joined: 16 Apr 06 Posts: 386
|
I'm told that some tasks were being reported too early (before the data server had managed to save the files which had been uploaded), and as a result the work units were sometimes being mangled. ID: 12327 · |
|
Send message Joined: 26 Jun 07 Posts: 29 |
Technical vs Cosmetic solutions: A cosmetic solution may be to change the wording of the status of the WU on the client to something different AFTER the WU is uploaded & while it is waiting to report that upload to the project server. So, when ready to upload WU status is 'Ready to Report' After WU upload, status is something like 'Results uploaded. Reporting to Server' ID: 12341 · |
|
Jord Send message Joined: 29 Aug 05 Posts: 15573
|
So, when ready to upload WU status is 'Ready to Report' Right, and you think that won't confuse the average user? Are you going to answer all the questions that will definitely come, just like "It says it is reporting them to server, but nothing happens!!!! BOINC sux!!!!" ;-) Most of the time people don't see results uploading. I sure don't, but then again, I am blessed (??) with an always on ADSL connection. When my BOINC has a couple of results waiting to report, and I happen to see it, I'll update that project manually. And if I don't look at what is happening, it'll happen automagically. :-) When things are running as they should, BOINC doesn't need any micro-managing. That's my opinion, anyway. ID: 12342 · |
|
Send message Joined: 7 Sep 07 Posts: 4 |
Because of this annoying behavior, I'm going back to 5.10.11. Anybody know where I can get 5.10.13? 
ID: 12349 · |
|
Send message Joined: 26 Jun 07 Posts: 29 |
...And if I don't look at what is happening, it'll happen automagically. :-) I 'magically' agree!! I don't really care how long reporting, downloading, etc takes or when it happens. As long as 1 of 3 projects on each client has work to do which is the vast majority of time. I was just raising the concept that some solutions are cosmetic, semantics, etc vice having to change real actions in applications. I have great faith that most users are ALWAYS confused! They just don't know if most of the time! ID: 12366 · |
|
Send message Joined: 16 Apr 06 Posts: 386
|
... Possibly there should also be : 7. When a 'trickle' is uploaded to the server, completed work will be reported at the same time ID: 12368 · |
|
Send message Joined: 7 Sep 07 Posts: 4 |
Where would I lobby to get this changed back? Or at least give us a choice? I participate in one project in which its Resource Share and the length of time for processing a result (more than a day) will cause the Ready to Report status to always last 24 hours. In the second of the three projects I support it will occur frequently. That's two out of three, which is unacceptable. I thought there would be more activity in this thread, as other people would be as irritated as I, but that hasn't happened. Don't other people care about this?
ID: 12698 · |
|
Send message Joined: 19 Jan 07 Posts: 1179 
|
I participate in one project in which its Resource Share and the length of time for processing a result (more than a day) will cause the Ready to Report status to always last 24 hours. In the second of the three projects I support it will occur frequently. That's two out of three, which is unacceptable. Why is it unacceptable? I haven't seen any good argument in favor of report-results-immediately yet. What do you lose by having it wait 24 hours before reporting? If it needs work, it will get it (and report whatever is waiting as part of the request); if a trickle needs to be sent, it will be sent (and report whatever is waiting as part of the request); if work is in deadline trouble, it will report it; and it won't be waiting there forever, there is a 24-hour cap. What's wrong with that? ID: 12700 · |
|
Send message Joined: 7 Sep 07 Posts: 4 |
I participate in one project in which its Resource Share and the length of time for processing a result (more than a day) will cause the Ready to Report status to always last 24 hours. In the second of the three projects I support it will occur frequently. That's two out of three, which is unacceptable. Because basically I'm impatient to see how my projects are progressing. I'm not advocating report-results-immediately. I'd just like it to go back to what it was before--that is, reporting at the frequency I have chosen (connect about every). ID: 12706 · |
|
Send message Joined: 13 Mar 06 Posts: 14
|
Where would I lobby to get this changed back? Or at least give us a choice? I participate in one project in which its Resource Share and the length of time for processing a result (more than a day) will cause the Ready to Report status to always last 24 hours. In the second of the three projects I support it will occur frequently. That's two out of three, which is unacceptable. I thought there would be more activity in this thread, as other people would be as irritated as I, but that hasn't happened. Don't other people care about this? I don't. My concept of helping is to let them tell me what they want me to do and then doing it. I don't try to tell them what or how. ID: 12752 · |
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.