5.10.20 - uploading but not reporting

Message boards : BOINC client : 5.10.20 - uploading but not reporting
Message board moderation

To post messages, you must log in.

1 · 2 · Next

AuthorMessage
David Ball

Send message
Joined: 2 Dec 06
Posts: 69
United States
Message 12288 - Posted: 4 Sep 2007, 2:34:45 UTC

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


<global_preferences>
<run_on_batteries>1</run_on_batteries>
<run_if_user_active>1</run_if_user_active>
<start_hour>0.000000</start_hour>
<end_hour>0.000000</end_hour>
<net_start_hour>0.000000</net_start_hour>
<net_end_hour>0.000000</net_end_hour>
<leave_apps_in_memory>1</leave_apps_in_memory>
<confirm_before_connecting>0</confirm_before_connecting>
<hangup_if_dialed>0</hangup_if_dialed>
<dont_verify_images>0</dont_verify_images>
<work_buf_min_days>0.000000</work_buf_min_days>
<work_buf_additional_days>2.000000</work_buf_additional_days>
<max_cpus>1</max_cpus>
<cpu_scheduling_period_minutes>60.000000</cpu_scheduling_period_minutes>
<disk_interval>300.000000</disk_interval>
<disk_max_used_gb>15.000000</disk_max_used_gb>
<disk_max_used_pct>50.000000</disk_max_used_pct>
<disk_min_free_gb>5.000000</disk_min_free_gb>
<vm_max_used_pct>75.000000</vm_max_used_pct>
<ram_max_used_busy_pct>40.000000</ram_max_used_busy_pct>
<ram_max_used_idle_pct>75.000000</ram_max_used_idle_pct>
<max_bytes_sec_up>25600.000000</max_bytes_sec_up>
<max_bytes_sec_down>51200.000000</max_bytes_sec_down>
<cpu_usage_limit>100.000000</cpu_usage_limit>
</global_preferences>


Here's the log file since the conversion:

2007-09-03 14:02:01 [---] Starting BOINC client version 5.10.20 for windows_intelx86
2007-09-03 14:02:01 [---] log flags: task, file_xfer, sched_ops
2007-09-03 14:02:01 [---] Libraries: libcurl/7.16.4 OpenSSL/0.9.8e zlib/1.2.3
2007-09-03 14:02:01 [---] Data directory: C:\Program Files\BOINC
2007-09-03 14:02:01 [---] Processor: 1 GenuineIntel Intel(R) Pentium(R) 4 CPU 2.80GHz [x86 Family 15 Model 2 Stepping 9]
2007-09-03 14:02:01 [---] Processor features: fpu tsc sse sse2 mmx
2007-09-03 14:02:01 [---] OS: Microsoft Windows XP: Professional Edition, Service Pack 2, (05.01.2600.00)
2007-09-03 14:02:01 [---] Memory: 1.49 GB physical, 4.35 GB virtual
2007-09-03 14:02:01 [---] Disk: 74.53 GB total, 31.67 GB free
2007-09-03 14:02:01 [---] Local time is UTC -6 hours
2007-09-03 14:02:01 [---] Version change (5.10.13 -> 5.10.20)
2007-09-03 14:02:01 [ABC@home] URL: http://abcathome.com/; Computer ID: 17286; location: work; project prefs: default
2007-09-03 14:02:01 [rosetta@home] URL: http://boinc.bakerlab.org/rosetta/; Computer ID: 73825; location: work; project prefs: default
2007-09-03 14:02:01 [boincsimap] URL: http://boinc.bio.wzw.tum.de/boincsimap/; Computer ID: 35658; location: work; project prefs: default
2007-09-03 14:02:01 [The Lattice Project] URL: http://boinc.umiacs.umd.edu/; Computer ID: 869; location: work; project prefs: default
2007-09-03 14:02:01 [QMC@HOME] URL: http://qah.uni-muenster.de/; Computer ID: 51132; location: work; project prefs: default
2007-09-03 14:02:01 [Spinhenge@home] URL: http://spin.fh-bielefeld.de/; Computer ID: 40621; location: work; project prefs: default
2007-09-03 14:02:01 [malariacontrol.net beta] URL: http://www.malariacontrol.net/; Computer ID: 33430; location: work; project prefs: default
2007-09-03 14:02:01 [uFluids] URL: http://www.ufluids.net/; Computer ID: 52155; location: work; project prefs: default
2007-09-03 14:02:01 [---] General prefs: from rosetta@home (last modified 2007-06-20 05:05:46)
2007-09-03 14:02:01 [---] Host location: work
2007-09-03 14:02:01 [---] General prefs: no separate prefs for work; using your defaults
2007-09-03 14:02:01 [---] Reading preferences override file
2007-09-03 14:02:01 [---] Preferences limit memory usage when active to 610.99MB
2007-09-03 14:02:01 [---] Preferences limit memory usage when idle to 1145.61MB
2007-09-03 14:02:01 [---] Preferences limit disk usage to 13.97GB
2007-09-03 14:02:02 [---] Running CPU benchmarks
2007-09-03 14:02:04 [---] Access to reference site failed - check network connection or proxy configuration.
2007-09-03 14:02:33 [---] Benchmark results:
2007-09-03 14:02:33 [---] Number of CPUs: 1
2007-09-03 14:02:33 [---] 1106 floating point MIPS (Whetstone) per CPU
2007-09-03 14:02:33 [---] 2070 integer MIPS (Dhrystone) per CPU
2007-09-03 14:02:34 [QMC@HOME] Restarting task last_bench13_jsch2005s22.1031_0 using Amolqc-preRC1 version 501
2007-09-03 14:02:52 [QMC@HOME] Sending scheduler request: Requested by user
2007-09-03 14:02:52 [QMC@HOME] (not requesting new work or reporting completed tasks)
2007-09-03 14:02:58 [QMC@HOME] Scheduler RPC succeeded [server version 509]
2007-09-03 14:02:58 [QMC@HOME] Deferring communication for 7 sec
2007-09-03 14:02:58 [QMC@HOME] Reason: requested by project
2007-09-03 14:03:33 [QMC@HOME] Sending scheduler request: Requested by user
2007-09-03 14:03:33 [QMC@HOME] (not requesting new work or reporting completed tasks)
2007-09-03 14:03:38 [QMC@HOME] Scheduler RPC succeeded [server version 509]
2007-09-03 14:03:38 [QMC@HOME] Deferring communication for 7 sec
2007-09-03 14:03:38 [QMC@HOME] Reason: requested by project
2007-09-03 14:06:48 [boincsimap] Sending scheduler request: Requested by user
2007-09-03 14:06:48 [boincsimap] (not requesting new work or reporting completed tasks)
2007-09-03 14:06:54 [boincsimap] Scheduler RPC succeeded [server version 511]
2007-09-03 14:06:54 [boincsimap] Deferring communication for 7 sec
2007-09-03 14:06:54 [boincsimap] Reason: requested by project
2007-09-03 15:06:57 [boincsimap] Restarting task 7090103.014963_1 using simap version 510
2007-09-03 15:35:13 [boincsimap] Computation for task 7090103.014963_1 finished
2007-09-03 15:35:13 [QMC@HOME] Resuming task last_bench13_jsch2005s22.1031_0 using Amolqc-preRC1 version 501
2007-09-03 15:35:15 [boincsimap] [file_xfer] Started upload of file 7090103.014963_1_0
2007-09-03 15:35:49 [boincsimap] [file_xfer] Finished upload of file 7090103.014963_1_0
2007-09-03 15:35:49 [boincsimap] [file_xfer] Throughput 23468 bytes/sec
2007-09-03 16:36:22 [boincsimap] Starting 7090103.014964_1
2007-09-03 16:36:22 [boincsimap] Starting task 7090103.014964_1 using simap version 510
2007-09-03 16:55:26 [boincsimap] Sending scheduler request: Requested by user
2007-09-03 16:55:26 [boincsimap] Reporting 1 tasks
2007-09-03 16:55:32 [boincsimap] Scheduler RPC succeeded [server version 511]
2007-09-03 16:55:32 [boincsimap] Deferring communication for 7 sec
2007-09-03 16:55:32 [boincsimap] Reason: requested by project
2007-09-03 16:56:20 [---] General prefs: from rosetta@home (last modified 2007-06-20 05:05:46)
2007-09-03 16:56:20 [---] Host location: work
2007-09-03 16:56:20 [---] General prefs: no separate prefs for work; using your defaults
2007-09-03 16:56:20 [---] Reading preferences override file
2007-09-03 16:56:20 [---] Preferences limit memory usage when active to 610.99MB
2007-09-03 16:56:20 [---] Preferences limit memory usage when idle to 1145.61MB
2007-09-03 16:56:20 [---] Preferences limit disk usage to 13.97GB
2007-09-03 17:36:24 [QMC@HOME] Resuming task last_bench13_jsch2005s22.1031_0 using Amolqc-preRC1 version 501
2007-09-03 19:49:25 [boincsimap] Resuming task 7090103.014964_1 using simap version 510
2007-09-03 20:24:18 [boincsimap] Computation for task 7090103.014964_1 finished
2007-09-03 20:24:18 [QMC@HOME] Resuming task last_bench13_jsch2005s22.1031_0 using Amolqc-preRC1 version 501
2007-09-03 20:24:20 [boincsimap] [file_xfer] Started upload of file 7090103.014964_1_0
2007-09-03 20:24:53 [boincsimap] [file_xfer] Finished upload of file 7090103.014964_1_0
2007-09-03 20:24:53 [boincsimap] [file_xfer] Throughput 23968 bytes/sec
2007-09-03 20:59:43 [QMC@HOME] Computation for task last_bench13_jsch2005s22.1031_0 finished
2007-09-03 20:59:43 [QMC@HOME] Starting last_bench4_jsch2005s22.442_0
2007-09-03 20:59:43 [QMC@HOME] Starting task last_bench4_jsch2005s22.442_0 using Amolqc-preRC1 version 501
2007-09-03 20:59:45 [QMC@HOME] [file_xfer] Started upload of file last_bench13_jsch2005s22.1031_0_0
2007-09-03 20:59:45 [QMC@HOME] [file_xfer] Started upload of file last_bench13_jsch2005s22.1031_0_1
2007-09-03 20:59:48 [QMC@HOME] [file_xfer] Finished upload of file last_bench13_jsch2005s22.1031_0_1
2007-09-03 20:59:48 [QMC@HOME] [file_xfer] Throughput 2366 bytes/sec
2007-09-03 20:59:51 [QMC@HOME] [file_xfer] Finished upload of file last_bench13_jsch2005s22.1031_0_0
2007-09-03 20:59:51 [QMC@HOME] [file_xfer] Throughput 19652 bytes/sec
2007-09-03 21:03:37 [boincsimap] Sending scheduler request: Requested by user
2007-09-03 21:03:37 [boincsimap] Reporting 1 tasks
2007-09-03 21:03:42 [boincsimap] Scheduler RPC succeeded [server version 511]
2007-09-03 21:03:42 [boincsimap] Deferring communication for 7 sec
2007-09-03 21:03:42 [boincsimap] Reason: requested by project
2007-09-03 21:03:52 [QMC@HOME] Sending scheduler request: Requested by user
2007-09-03 21:03:52 [QMC@HOME] Reporting 1 tasks
2007-09-03 21:03:58 [QMC@HOME] Scheduler RPC succeeded [server version 509]
2007-09-03 21:03:58 [QMC@HOME] Deferring communication for 7 sec
2007-09-03 21:03:58 [QMC@HOME] Reason: requested by project

ID: 12288 · Report as offensive
Keck_Komputers
Avatar

Send message
Joined: 29 Aug 05
Posts: 304
United States
Message 12290 - Posted: 4 Sep 2007, 6:08:47 UTC

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 · Report as offensive
Profile KSMarksPsych
Avatar

Send message
Joined: 30 Oct 05
Posts: 1239
United States
Message 12296 - Posted: 4 Sep 2007, 11:00:56 UTC

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 · Report as offensive
Alinator

Send message
Joined: 8 Jan 06
Posts: 36
United States
Message 12301 - Posted: 4 Sep 2007, 19:23:13 UTC
Last modified: 4 Sep 2007, 19:48:28 UTC

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 · Report as offensive
zombie67
Avatar

Send message
Joined: 14 Feb 06
Posts: 136
United States
Message 12306 - Posted: 5 Sep 2007, 2:14:06 UTC

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 · Report as offensive
MikeMarsUK

Send message
Joined: 16 Apr 06
Posts: 386
United Kingdom
Message 12307 - Posted: 5 Sep 2007, 7:17:46 UTC
Last modified: 5 Sep 2007, 7:20:18 UTC


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 · Report as offensive
Profile Jord
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 29 Aug 05
Posts: 14732
Netherlands
Message 12308 - Posted: 5 Sep 2007, 8:49:33 UTC - in response to Message 12307.  

The Work scheduler is still in effect. Tasks with a short deadline will be reported before their deadline.

ID: 12308 · Report as offensive
MikeMarsUK

Send message
Joined: 16 Apr 06
Posts: 386
United Kingdom
Message 12315 - Posted: 5 Sep 2007, 19:25:43 UTC


That's good to know, thanks.

ID: 12315 · Report as offensive
CyberSchnook

Send message
Joined: 6 Sep 07
Posts: 1
Message 12323 - Posted: 6 Sep 2007, 2:42:37 UTC

/me reverts to 5.10.13 and parks

projects requiring later versions get detached.
ID: 12323 · Report as offensive
David Ball

Send message
Joined: 2 Dec 06
Posts: 69
United States
Message 12324 - Posted: 6 Sep 2007, 3:22:09 UTC - in response to Message 12306.  

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.


Agreed. What an annoying change. Does anyone know why this was done?
ID: 12324 · Report as offensive
MikeMarsUK

Send message
Joined: 16 Apr 06
Posts: 386
United Kingdom
Message 12327 - Posted: 6 Sep 2007, 7:30:49 UTC
Last modified: 6 Sep 2007, 7:33:14 UTC


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 · Report as offensive
Heflin

Send message
Joined: 26 Jun 07
Posts: 29
Message 12341 - Posted: 6 Sep 2007, 17:59:18 UTC - in response to Message 12327.  

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 · Report as offensive
Profile Jord
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 29 Aug 05
Posts: 14732
Netherlands
Message 12342 - Posted: 6 Sep 2007, 18:20:43 UTC - in response to Message 12341.  

So, when ready to upload WU status is 'Ready to Report'
After WU upload, status is something like 'Results uploaded. Reporting to Server'

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 · Report as offensive
googloo

Send message
Joined: 7 Sep 07
Posts: 4
Message 12349 - Posted: 7 Sep 2007, 3:18:04 UTC

Because of this annoying behavior, I'm going back to 5.10.11. Anybody know where I can get 5.10.13?
ID: 12349 · Report as offensive
SekeRob

Send message
Joined: 25 Aug 06
Posts: 1596
Message 12355 - Posted: 7 Sep 2007, 13:01:22 UTC - in response to Message 12349.  
Last modified: 7 Sep 2007, 13:05:21 UTC

Because of this annoying behavior, I'm going back to 5.10.11. Anybody know where I can get 5.10.13?


Here are the rules that make part 2 of the result reporting, all there to ensure nothing ever gets lost in transmission, take place:

http://www.boinc-wiki.info/Ready_to_Report

Results will be reported automatically at the following triggers:

1. New work is needed. Completed work will be reported at the same time.
2. The Deadline is less than 24 hours away.
3. The Result is less than the Work Buffer setting from it's Deadline (New for v5.4.xx)
4. The Result has been in the Ready to Report status for 24 hours. (New for v5.10.14)
5. The Result has been in the Ready to Report status longer than the Work Buffer setting. (Removed in v5.10.14 and later)
6. If "net_status.have_sporadic_connection" will report immediately. (Not sure, but maybe something for dialup-users?)


It continues to be beyond the comprehension of many why one wants to push out these "Ready To Report" lines, when the important thing, The Result Files, have already been sent up. Website statistics do not update more frequent than 4x a day, and Team statistics and comparisons most often are not run and discussed but for reference to refreshes done every 24 hours. Set you connect times to a time frame of 1 day and a network schedule of e.g. 20:00 UTC to 21:00 UTC and all gets flushed daily, new work pulled and, validated work ready to show off the results in forthcoming statistics update at e.g. your teams website.

If you have the download link for any version of BOINC, simply change the link address to the number you want to download or go to next address to get the full list: http://boincdl.ssl.berkeley.edu/dl/

Coelum Non Animum Mutant, Qui Trans Mare Currunt
ID: 12355 · Report as offensive
Heflin

Send message
Joined: 26 Jun 07
Posts: 29
Message 12366 - Posted: 7 Sep 2007, 18:45:01 UTC - in response to Message 12342.  

...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.


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 · Report as offensive
MikeMarsUK

Send message
Joined: 16 Apr 06
Posts: 386
United Kingdom
Message 12368 - Posted: 7 Sep 2007, 20:56:49 UTC - in response to Message 12355.  

...
http://www.boinc-wiki.info/Ready_to_Report

Results will be reported automatically at the following triggers:

1. New work is needed. Completed work will be reported at the same time.
2. The Deadline is less than 24 hours away.
3. The Result is less than the Work Buffer setting from it's Deadline (New for v5.4.xx)
4. The Result has been in the Ready to Report status for 24 hours. (New for v5.10.14)
5. The Result has been in the Ready to Report status longer than the Work Buffer setting. (Removed in v5.10.14 and later)
6. If "net_status.have_sporadic_connection" will report immediately. (Not sure, but maybe something for dialup-users?)

...


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 · Report as offensive
googloo

Send message
Joined: 7 Sep 07
Posts: 4
Message 12698 - Posted: 23 Sep 2007, 2:47:53 UTC

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 · Report as offensive
Nicolas

Send message
Joined: 19 Jan 07
Posts: 1179
Argentina
Message 12700 - Posted: 23 Sep 2007, 3:13:54 UTC - in response to Message 12698.  

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 · Report as offensive
googloo

Send message
Joined: 7 Sep 07
Posts: 4
Message 12706 - Posted: 23 Sep 2007, 14:19:59 UTC - in response to Message 12700.  

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?


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 · Report as offensive
1 · 2 · Next

Message boards : BOINC client : 5.10.20 - uploading but not reporting

Copyright © 2021 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.