5/5/2019 1:35:28 AM | | [work_fetch] shortfall 0.00 nidle 0.00 saturated 395513.63 busy 19859.02

I've tried looking through the source code but that left me even more confused. It's reset to zero in
"struct BUSY_TIME_ESTIMATOR", and when BUSY_TIME_ESTIMATOR goes through
the instances and finds the lowest value, then adds that value to the busy time of the others.

rr_sim sets the busy time to non-zero but I've only looked at it for a few minutes and that's not long enough to fully understand what's going on. Also, why does rr_sim use a time slice of 3600 seconds when I have it set to 720 minutes (12 hours aka 43200 secs) so my large jobs will run straight through? The large time slice keeps me from having a bunch of partially complete jobs that I have to wonder when it will get around to finishing, and the extra jobs that are started increase the memory footprint. The large time slice is especially good on projects where the jobs have about a 1GB memory footprint.

What does the "busy 19859.02" in the above event log entry mean?

Does a non-zero value for "busy" in the log entry mean that it's run into trouble completing the work on time?

Sorry if I'm being a pain with my question. It sort of grew beyond the basic question when I looked at the source code.

-- David

I cannot help with the sources, maybe one of the developers can.

However, I have used 720 minutes myself for various projects: srbase, WCG.

Unless I am mistaken, you have a non-gpu system and are currently working only WCG and Rosetta.

What problem are you seeing?

I think it's to do with https://github.com/BOINC/boinc/blob/master/client/work_fetch.h#L153:

// estimate the time a resource will be saturated
// with high-priority jobs.

High-priority jobs are those in danger of missing their deadlines. They are run as 'Earliest deadline first' in an effort to return them as quickly as possible, jumping the normal resource-share queue.

Thanks for the help. I realize now that busy just meant that it was giving an extra little bit of runtime to Rosetta. My original post was on the 5th. I was configured to get 4 days of work. The Rosetta work units were due on the 12th. rr_sim had apparently figured out that they would miss the deadline due to additional work being fetched to maintain 4 days of work.

One thing I noticed: While it was still showing some busy time, but not as much as in the original post, I shortened the configuration for the amount of work that Iit was getting by 0.25 days ( from 4.00 to 3.75) and that made the "busy" work go to zero. rr_sim sure has to deal with a lot of complicated things.

Thanks,

David