Being taken seriously is following the steps and suggestions of a CA, so when confirmed we can scratch our heads why to the microsecond assignment time sorted tasks do not process in the order shown in the client (provided it is showing the historical order and not the hand sorted). As a person who claims to understand basic problem diagnostics you would be aware of the principle of reproducibility. Got here 5 sciences in the queue on a quad and the C4CW are getting their natural turn, just how BOINC is coded.

Sweet Dreams

The ball remains in your court. You know what I've asked you to provide.

Sweet Dreams still.

David,

I'm not 100% sure what you are seeing is improper. But if you could turn on cpu_sched_debug in cc_config.xml and let us know what you see in your message logs.

I have multiple ideas in my head what may be causing what you are seeing. But like i said, I do not believe this to be improper for the agent.

Thanks,
-Uplinger

Hi Arnold,

How many days of work are cached based on the values currently showing in the Time To Completion (TTC) column?

It's as I laid out, the processing is as per the "Sent Time" sort order on the Result Status (RS) page, so even though the C4CW may have a 10 day deadline, they could have been received beforethe DDDT/HFCC. The 28th reads like a 4 day deadline which you can confirm at the RS pages.

Requested some years ago, a way to return the deadline column to historical order... sort on first click on column header, ascending, second click, descending, 3rd click, historic receipt time which must be stored somewhere as else the client would not know how to apply the FIFO rule.Getting historic back is I think deleting the keys in the registry that hold such things a windows position.

Yesterday received 4 C4CW and could see only 3. Appeared that one was a repair job that had jumped to near the top of the sort order as had a CEP2 repair task. They were still sitting there this morning, at the top and expect them to sit there until the client has worked almost completely through the 2 day buffer... LILO. To me all the proof needed to support the knowledge that "by Grid" processing is FIFO unless there is a panic state, down to the microsecond. Your client clearly does not compute that condition.

On those very long times, you may have had one or more tasks that took much longer and consequently the client inflates the TTC for all the results taking the FPOPS in the job header and multiplying that in the first instance with the Duration Correction Factor. It only slowly gets reduced with each task that completes faster than the current projected TTCs for the tasks in the Ready to Start state.

Happy crunching, (best leaving the client to do what it's best at, processing the tasks... it hates being watched)

Regarding the High Priority mode there is a parameter which has an influence on the threshold and for which WCG-only users might not care at all, that is the "Switch between applications every: xxxx minutes" setting.

Of course if a device is attached to several grids one has to set this parameter to achieve the desired time share between them.

But if crunching only for WCG you can set it for example
- to 4500 minutes to have jobs with a deadline of 3 days or less to start immediately after downloading
- or to 6000 minutes to have repair jobs with the normal 4-day deadline to start immediately.

It may not seem logical that this parameter has some effect even in a client attached to a single project, but really it does matter.