Could someone fill in the meaning of the acronyms and abbreviations of the end of line on the cpu_sched_debug? I am wondering why I have one machine who is steadfastly refusing to work on onboard AP tasks with a deadline of 09Sept2015 and keeps running MB tasks with a deadline of 11Oct2015.

Pipsqueek

26043 SETI@home 8/19/2015 6:26:26 PM [cpu_sched_debug] 4: 22jn08ab.19254.1797154.438086664199.12.80_0 (MD: no; UTS: yes)
26044 SETI@home 8/19/2015 6:26:26 PM [cpu_sched_debug] 5: 22jn08ab.19254.1797154.438086664199.12.48_1 (MD: no; UTS: yes)
26045 SETI@home 8/19/2015 6:26:26 PM [cpu_sched_debug] 6: ap_27dc14ac_B6_P0_00106_20150816_22599.wu_3 (MD: no; UTS: no)
26046 SETI@home 8/19/2015 6:26:26 PM [cpu_sched_debug] 7: ap_21my15ab_B4_P1_00185_20150802_26481.wu_2 (MD: no; UTS: no)
26047 SETI@home 8/19/2015 6:26:26 PM [cpu_sched_debug] 8: ap_26dc14aa_B2_P1_00080_20150812_27856.wu_2 (MD: no; UTS: no)
26048 SETI@home 8/19/2015 6:26:26 PM [cpu_sched_debug] 9: ap_22jn08ab_B1_P0_00078_20150819_29731.wu_1 (MD: no; UTS: no)


What does the (MD: no; UTS: no) mean versus the (MD: no; UTS: yes)

I can't figure out the acronyms.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

These are basically guesses, but I think they're in the right ballpark.

MD: Missing Deadline. Needs to jump the queue, not run FIFO.
UTS: umm... Time Slice. A measure of whether the task can be switched out - 'pre-empted' - in favour of a task from another project, to honour Resource Share. Related to Task Switch Interval.

Thanks for the guesses, Richard. I think you're in the ballpark too. I set both cpu_sched_debug along with priority_debug to try and see why these MB tasks are jumping the FIFO schedule and my old AP tasks are just sitting on their hands. None of the numbers in the various log options pointed to the MB's taking priority. Then I noticed the difference on the AP tasks where none of them had the Yes flag in the deadline but the MB's do. Needed to understand what the acronyms stood for. Thanks. Still no clarity, though. I know they'll eventually get done before deadline but was hoping to add to RAC for the contest. So why has the other machine crunched all of its AP's in the FIFO schedule for the same batch of AP's issued on the same date and time?

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

I noticed that you are running with 7.6.6, so it just might be a case of CPU starvation, a bug that was recently discovered. Check out the FIFO thread, http://setiathome.berkeley.edu/forum_thread.php?id=77858, in there is as a private drop that you may want to check out and is currently being tested. It cured the problem on my machine. Please note that the bug was found on an Intel machine so I don't know if it will work on AMD. Smarter minds then mine should be able to answer that question.

[edit] If you find that you can use the private drop, just download it and unzip the files into the BOINC folder on your system drive. Just be sure to stop and exit BOINC prior to doing it. [/edit]

---

I don't buy computers, I build them!!

I remember following that thread. I didn't put much value into the discussion because I hadn't seen any sign of CPU starvation on my two machines. My problem or irritation is that I have some AP GPU tasks that were issued first in FIFO order than the MB GPU tasks that are currently preempting their running. Only seeing it on one machine though, hence the confusion about what it different about that machine compared to the other. Basically the machines are twins adding to the confusion.

Does that private drop from ROM roll up the new stuff in the 7.6.7 client that Jord has posted? I was entertaining actually trying out that beta.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Does that private drop from ROM roll up the new stuff in the 7.6.7 client that Jord has posted? I was entertaining actually trying out that beta.

I think Jord's v7.6.7 is even more inclusive than Rom's last private drop. It's certainly newer.

(Edit: the 160815 private drop was a very specific problem - I hadn't bothered to take out a GPU exclusion relating to a graphics card which burned out six months ago and hasn't been replaced. Not many people will encounter that - it took me six months, and a WOW! challenge, to come across it)

Thanks, Richard. I think I will give Jord's latest drop a tryout. He's said he hasn't run into any showstoppers. As long as I am smart about it, and stop everything before upgrading, I think I can manage without an official installer.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

I remember following that thread. I didn't put much value into the discussion because I hadn't seen any sign of CPU starvation on my two machines. My problem or irritation is that I have some AP GPU tasks that were issued first in FIFO order than the MB GPU tasks that are currently preempting their running.

That's exactly the same condition I ran across when I started the thread. Many thought that the MB tasks were being run in high priority and it took some serious persistence to prove that theory wrong. Sir Richard Haselgrove was the one who detected the possible problem through a dump of the event log with the cpu_sched_debug flag. That was passed upstairs along with other event log dumps and a fix was made, which is still being tested, but I've not encountered the problem since.

---

I don't buy computers, I build them!!

Well I tried the 7.6.7 debug drop and got scared away when the benchmarks it ran, plummeted to nothing. Thought it was a fluke and ran the benchmarks standalone and got the same result. I notice the files comprised more than 13 MB compared to the stock 7.6.6 installer size of 9 MB. I'm guessing the debug payload significantly slows things down. So I backed out of the 7.6.7 release and went back to 7.6.6. I finally let the cpu_sched_debug run for a couple of contacts and, FINALLY, I saw the manager reschedule my first in FIFO AP tasks to get ahead of the MB tasks it was running. I don't know whether it was the temporary run of the 7.6.7 client that kicked things into gear or just letting the debug run through several contact cycles, but the AP tasks are finally running. Yay!!

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)