Reporting timer?

Message boards : Questions and problems : Reporting timer?
Message board moderation

To post messages, you must log in.

Previous · 1 · 2

AuthorMessage
Profile Keith Myers
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 17 Nov 16
Posts: 863
United States
Message 93583 - Posted: 8 Nov 2019, 7:50:21 UTC

I donated to BoincStats and never got put on the donor list to not be bugged by ads. So have no remorse turning on my adblocker on their site.
ID: 93583 · Report as offensive
Profile Joseph Stateson
Volunteer tester
Avatar

Send message
Joined: 27 Jun 08
Posts: 641
United States
Message 93607 - Posted: 10 Nov 2019, 2:20:02 UTC - in response to Message 93566.  
Last modified: 10 Nov 2019, 2:27:04 UTC


Milkyway has
<request_delay>91.000000</request_delay>
I'm more interested in

<min_sendwork_interval> N </min_sendwork_interval>
Minimum number of seconds between sending jobs to a given host. You can use this to limit the impact of faulty hosts.
I'm not yet certain that this is the one which emerges as <request_delay>, but I think it's a more plausible candidate.
Edit - candidacy confirmed (I think) by https://github.com/BOINC/boinc/blob/master/sched/sched_types.cpp#L784


I have been looking at this and found a code change to the client to correct for the deficiency, or more likely, improper setup at the Milkyway project. I am not proposing to change the client, rather want to know what is wrong at the project end that allows my change to cause the work flow to work properly.

The problem as stated (many times): A block of MW work units arrive with the scheduler reply which has that 91 second delay requirement. A number of work units are processed, usually takes a minute each, and, a minimum of 91 seconds later results can be returned. Unlike other projects I am familiar with, Milkyway does not download any new work when results are uploaded. No work is download until the last of the work units are uploaded and only after a 10 minute delay.

I looked in cs_scheduler.cpp at
// Write a scheduler request to a disk file,
// to be sent to a scheduling server
//
int CLIENT_STATE::make_scheduler_request(PROJECT* p) {


and noticed that results, if any, are attached to the scheduler request a the location
p->nresults_returned = 0;
		for (i = 0; i<results.size(); i++) {
			rp = results[i];
			if (rp->project == p && rp->ready_to_report) {
				p->nresults_returned++;
				rp->write(mf, true);
			}


On a hunch, I allowed the results to be attached only if 91 seconds had elapsed since the last actual upload of results. However, the 91 second value was not available as that variable was in scheduler_reply, not scheduler_request so I used a local constant that could be obtained from the cc_config file for testing purposes.

I made a linux version in addtion to win32 and win64 and put the source code here along with printouts of work flow.

Looking at those event messages (work flow) from the three different systems running milkyway, you can see that new data is downloaded concurrently with uploads as is the normal behavior of on other projects.

To restate my solution: The project only "honors" a request for work if no existing results are attached to the scheduler request for at least 91 seconds.
Perhaps this can be a clue to find the real problem.
ID: 93607 · Report as offensive
Profile Keith Myers
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 17 Nov 16
Posts: 863
United States
Message 93609 - Posted: 10 Nov 2019, 2:43:05 UTC

Great detective work. Interesting workaround. Wish the MW administrators would look at your code examples and see where they have the server software misconfigured. I think you have asked for the server configuration files from the project to examine. Richard could probably work out what they have done wrong.
ID: 93609 · Report as offensive
Profile Joseph Stateson
Volunteer tester
Avatar

Send message
Joined: 27 Jun 08
Posts: 641
United States
Message 93613 - Posted: 10 Nov 2019, 12:26:52 UTC - in response to Message 93609.  

Great detective work. Interesting workaround. Wish the MW administrators would look at your code examples and see where they have the server software misconfigured. I think you have asked for the server configuration files from the project to examine. Richard could probably work out what they have done wrong.


Thanks Keith!

Going to restate my conclusion as it is too late to edit the previous post and it might be misleading.

The client properly recognizes and uses the 91 second RPC delay. No problem there. All requests to the project have a 91 second delay whether results are attached or not.

What I found was that the project requires at least one request to HAVE NO RESULTS ATTACHED . That time delay of 256 seconds before I allow results to be attached will cause at least one request (all these requests are for data) to be sent WITH NO RESULTS ATTACHED So, if I had actually used 91 seconds for my delay (instead of 256) the project would exhibit the same behavior and nothing would have been downloaded.
ID: 93613 · Report as offensive
Previous · 1 · 2

Message boards : Questions and problems : Reporting timer?

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.