Given that Moore's Law applies to server hardware too, do we have any evidence that any current BOINC project server would be over-stressed by one RPC per hour per active host? CPDN have adopted a 3600 second backoff between RPCs, but I believe this is mostly to prevent individual hosts downloading too many new tasks when available.
I've been running v7.2.36 with the one-hour reporting for three days now, and I'm pleased with it: with a fast GPU at SETI, I'm reporting up to 20 tasks at a time, although slower CPU projects can report singly. With piggyback work fetch applied to the reporting RPCs when needed, I'm seeing a more even application of Resource Share between projects, with less of BOINC v7's tendency to lurch between 100% saturation for Project A and 100% for Project B (as anticipated in ClientSchedOctTen). >________________________________ > From: "McLeod, John" <[email protected]> >To: "McLeod, John" <[email protected]>; David Anderson ><[email protected]>; "[email protected]" ><[email protected]> >Sent: Monday, 6 January 2014, 16:02 >Subject: Re: [boinc_dev] RFC: Don't let a task be in the state "Ready to >report" if its files were uploaded immediately before > > >Instead of reporting after an hour which will have the consequence of >reporting almost every task on its own, how about reporting no later than 48 >hours prior to deadline (this will cope with one day vacations for most >machines with some added slop if there is a delay turning the machine back >on), and report no later than min_queue + 24 hours (this will avoid a >reporting late because of turning off the machine a few minutes early because >of a longer vacation). > >-----Original Message----- >From: boinc_dev [mailto:[email protected]] On Behalf Of >McLeod, John >Sent: Monday, January 06, 2014 10:46 AM >To: David Anderson; [email protected] >Subject: Re: [boinc_dev] RFC: Don't let a task be in the state "Ready to >report" if its files were uploaded immediately before > >Changing it to one hour will essentially disable multi task reporting for most >projects. > >-----Original Message----- >From: boinc_dev [mailto:[email protected]] On Behalf Of David >Anderson >Sent: Monday, December 30, 2013 1:31 PM >To: [email protected] >Subject: Re: [boinc_dev] RFC: Don't let a task be in the state "Ready to >report" if its files were uploaded immediately before > >The policy for when to report tasks is in >CLIENT_STATE::find_project_with_overdue_results(). >One of the clauses is that tasks are reported within 24 hours of completion. >I changed this to 1 hour. >-- David > >On 27-Dec-2013 10:11 AM, Toralf Förster wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> On 12/27/2013 02:30 PM, Toralf Förster wrote: >>> The topic was discussed kin the past - yes. And I do understand to >>> objection to not overload the network resources of a BOINC server >>> with tasks which could be done a day later or so. >>> >>> But today I ran (again) into a case, where a task was solved fine >>> and its files were uploaded successfully to to the World Community >>> Grid server around 23th of December, but the task itself stayed in >>> the state "Ready to report". Then the computer was s2disked. >>> >>> Today I came back - and the task is marked as "Too late" (the dead >>> line was yesterday). >>> >>> Well, Christmas is a rare case (within a year) - but I think, >>> there's place for an improvement to upload *and* report a task >>> immediately instead of reporting it (at least at my system almost) >>> later. >>> >>> >>> >> FWIW here're the last 500 lines of /var/lib/boinc/stdoutdae.txt : >> http://bpaste.net/show/162219/ >> >> and I do refer to this task : >> >> >> >> Workunit Status >> >> Project Name: FightAIDS@Home - Vina >> Created: 12/16/2013 11:04:43 >> Name: FAHV_x1ZTZ_prnotAS2_0621789_0533 >> Minimum Quorum: 1 >> Replication: 2 >> >> >> - -- >> MfG/Sincerely >> Toralf Förster >> pgp finger print:1A37 6F99 4A9D 026F 13E2 4DCF C4EA CDDE 0076 E94E >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.22 (GNU/Linux) >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iF4EAREIAAYFAlK9wrgACgkQxOrN3gB26U5YpwD/eBz0CbBnc2wZMjTS74tFnRFW >> yVoTLxpMhLacpIy/jcwA/j3CYUDvmjrMuCzKpFTGaJYO5vYjILvVKsEsroAKTf1X >> =uBvX >> -----END PGP SIGNATURE----- >> _______________________________________________ >> boinc_dev mailing list >> [email protected] >> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >> To unsubscribe, visit the above URL and >> (near bottom of page) enter your email address. >> >_______________________________________________ >boinc_dev mailing list >[email protected] >http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >To unsubscribe, visit the above URL and >(near bottom of page) enter your email address. >_______________________________________________ >boinc_dev mailing list >[email protected] >http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >To unsubscribe, visit the above URL and >(near bottom of page) enter your email address. >_______________________________________________ >boinc_dev mailing list >[email protected] >http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >To unsubscribe, visit the above URL and >(near bottom of page) enter your email address. > > _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
