This drove me crazy until I figured it out...

One of my work profiles has the host churning only between 02:00-18:00. On the one host that uses that profile, if I do Tool/SyncBAM, and then look at my Options/ComputingPrefs, I see it as "Using Web based prefs" and 02:00-18:00. Just like it is supposed to be.

But a bit later, I would notice that my TV watching on this host would be really choppy, my TV recordings would be jumpy & freezing, check BOINC, and find it churning after 18:00. What? I look at Options/ComputingPrefs, and it says "Using WEB prefs" with NO time restriction. Huh? I do manual sync, it is fine, a few hours later it is bad again...

The reason: My machines also automatically sync with BAM hourly in the background. So, the data that comes from manual sync is correct, but the automated background sync gets the bad result. Another "$val = $val ? $val : 0;" issue that needs to be "$val = isset($val) ? $val : 0;"?

Tuna

For BAM! there is no difference between a scheduled sync and a manual sync.

You could compare the acct_mgr_reply.xml files after each sync.

It could be possible that a project is also sending preferences which conflict with the BAM! preferences.

Thanks for the insight! I looked for which reply XMLs contain a global_preferences section and which one has 18 vs. 0. I actually have 50 reply XMLs but only a few have global_preferences section, and only one that is not playing well.

C:\ProgramDataBOINC>dir *reply*.xml

......

 Directory of C:\ProgramDataBOINC

....

              50 File(s)        726,628 bytes

               0 Dir(s)  92,813,819,904 bytes free



C:\ProgramDataBOINC>findstr global_preferences *reply*.xml

acct_mgr_reply.xml: <global_preferences>

acct_mgr_reply.xml: </global_preferences>

sched_reply_boinc.fzk.de_poem.xml:<global_preferences>

sched_reply_boinc.fzk.de_poem.xml:</global_preferences>

sched_reply_www.distributeddatamining.org_DistributedDataMining.xml:<global_preferences>

sched_reply_www.distributeddatamining.org_DistributedDataMining.xml:</global_preferences>

sched_reply_www.gpugrid.net.xml:<global_preferences>

sched_reply_www.gpugrid.net.xml:</global_preferences>



C:\ProgramDataBOINC>findstr /L "<end_hour>18" *reply*.xml

acct_mgr_reply.xml:  <end_hour>18</end_hour>

sched_reply_boinc.fzk.de_poem.xml:<end_hour>18</end_hour>



C:\ProgramDataBOINC>findstr /L "<end_hour>0" *reply*.xml

sched_reply_boinc.fzk.de_poem.xml:<end_hour>0</end_hour>

sched_reply_www.gpugrid.net.xml:<end_hour>0</end_hour>

It seems the culprit is sched_reply_www.gpugrid.net.xml. It has start & end_hour set to 0. Why would a project send back a global_preferences section, anyways?

Your acct_mgr_reply.xml contains:

<global_preferences>

   <host_specific/>

   <source_project>http://bam.boincstats.com/</source_project>

   <mod_time>1452908003</mod_time>

   <run_if_user_active>0</run_if_user_active>

   <run_gpu_if_user_active>0</run_gpu_if_user_active>

   <suspend_if_no_recent_input>0</suspend_if_no_recent_input>

   <cpu_scheduling_period_minutes>60</cpu_scheduling_period_minutes>

   <idle_time_to_run>3</idle_time_to_run>

   <work_buf_min_days>1</work_buf_min_days>

   <work_buf_additional_days>2</work_buf_additional_days>

   <max_cpus>1024</max_cpus>

   <max_ncpus_pct>100</max_ncpus_pct>

   <suspend_cpu_usage>25</suspend_cpu_usage>

   <cpu_usage_limit>100</cpu_usage_limit>

   <disk_interval>60</disk_interval>

   <disk_max_used_gb>50</disk_max_used_gb>

   <disk_max_used_pct>20</disk_max_used_pct>

   <disk_min_free_gb>5</disk_min_free_gb>

   <vm_max_used_pct>75</vm_max_used_pct>

   <ram_max_used_busy_pct>20</ram_max_used_busy_pct>

   <ram_max_used_idle_pct>90</ram_max_used_idle_pct>

   <max_bytes_sec_down>0</max_bytes_sec_down>

   <max_bytes_sec_up>0</max_bytes_sec_up>

   <start_hour>2</start_hour>

   <end_hour>18</end_hour>

   <net_start_hour>0</net_start_hour>

   <net_end_hour>0</net_end_hour>

</global_preferences>

Their sched_reply_www.gpugrid.net.xml contains:

<global_preferences>

   <source_project>http://bam.boincstats.com/</source_project>

   <mod_time>1452908004</mod_time>

   <disk_max_used_gb>50</disk_max_used_gb>

   <start_hour>0</start_hour>

   <disk_max_used_pct>20</disk_max_used_pct>

   <net_start_hour>0</net_start_hour>

   <max_bytes_sec_down>0</max_bytes_sec_down>

   <ram_max_used_idle_pct>90</ram_max_used_idle_pct>

   <net_end_hour>0</net_end_hour>

   <run_gpu_if_user_active>0</run_gpu_if_user_active>

   <suspend_if_no_recent_input>0</suspend_if_no_recent_input>

   <run_if_user_active>0</run_if_user_active>

   <idle_time_to_run>3</idle_time_to_run>

   <max_cpus>1024</max_cpus>

   <vm_max_used_pct>75</vm_max_used_pct>

   <max_bytes_sec_up>0</max_bytes_sec_up>

   <max_ncpus_pct>100</max_ncpus_pct>

   <work_buf_min_days>1</work_buf_min_days>

   <cpu_usage_limit>100</cpu_usage_limit>

   <suspend_cpu_usage>25</suspend_cpu_usage>

   <cpu_scheduling_period_minutes>60</cpu_scheduling_period_minutes>

   <end_hour>0</end_hour>

   <work_buf_additional_days>2</work_buf_additional_days>

   <ram_max_used_busy_pct>20</ram_max_used_busy_pct>

   <disk_min_free_gb>5</disk_min_free_gb>

   <disk_interval>60</disk_interval>

</global_preferences>

Clearly, what BAM! sent to my host is later overridden (I checked the timestamps of the XMLs) by GPUGRID.

POEM seems to get it right by listing both the "parent preferences" and having a subsection for the "specific preferences" in their sched_reply_boinc.fzk.de_poem.xml:

<global_preferences>

   <source_project>http://bam.boincstats.com/</source_project>

   <mod_time>1452908004</mod_time>

   <disk_max_used_gb>50</disk_max_used_gb>

   <start_hour>0</start_hour>

   <disk_max_used_pct>20</disk_max_used_pct>

   <net_start_hour>0</net_start_hour>

   <max_bytes_sec_down>0</max_bytes_sec_down>

   <ram_max_used_idle_pct>90</ram_max_used_idle_pct>

   <net_end_hour>0</net_end_hour>

   <run_gpu_if_user_active>0</run_gpu_if_user_active>

   <suspend_if_no_recent_input>0</suspend_if_no_recent_input>

   <run_if_user_active>0</run_if_user_active>

   <idle_time_to_run>3</idle_time_to_run>

   <max_cpus>1024</max_cpus>

   <vm_max_used_pct>75</vm_max_used_pct>

   <max_bytes_sec_up>0</max_bytes_sec_up>

   <max_ncpus_pct>100</max_ncpus_pct>

   <work_buf_min_days>1</work_buf_min_days>

   <cpu_usage_limit>100</cpu_usage_limit>

   <suspend_cpu_usage>25</suspend_cpu_usage>

   <cpu_scheduling_period_minutes>60</cpu_scheduling_period_minutes>

   <end_hour>0</end_hour>

   <work_buf_additional_days>2</work_buf_additional_days>

   <ram_max_used_busy_pct>20</ram_max_used_busy_pct>

   <disk_min_free_gb>5</disk_min_free_gb>

   <disk_interval>60</disk_interval>

   <venue name="No TV Recording">

      <ram_max_used_busy_pct>20</ram_max_used_busy_pct>

      <work_buf_additional_days>2</work_buf_additional_days>

      <disk_min_free_gb>5</disk_min_free_gb>

      <disk_interval>60</disk_interval>

      <end_hour>18</end_hour>

      <cpu_scheduling_period_minutes>60</cpu_scheduling_period_minutes>

      <work_buf_min_days>1</work_buf_min_days>

      <cpu_usage_limit>100</cpu_usage_limit>

      <suspend_cpu_usage>25</suspend_cpu_usage>

      <max_ncpus_pct>100</max_ncpus_pct>

      <max_bytes_sec_up>0</max_bytes_sec_up>

      <vm_max_used_pct>75</vm_max_used_pct>

      <max_cpus>1024</max_cpus>

      <idle_time_to_run>3</idle_time_to_run>

      <run_if_user_active>0</run_if_user_active>

      <suspend_if_no_recent_input>0</suspend_if_no_recent_input>

      <net_end_hour>0</net_end_hour>

      <ram_max_used_idle_pct>90</ram_max_used_idle_pct>

      <run_gpu_if_user_active>0</run_gpu_if_user_active>

      <net_start_hour>0</net_start_hour>

      <max_bytes_sec_down>0</max_bytes_sec_down>

      <start_hour>2</start_hour>

      <disk_max_used_pct>20</disk_max_used_pct>

      <disk_max_used_gb>50</disk_max_used_gb>

   </venue>

</global_preferences>

I'll post to the GPUGRID forum, pointing to this thread.

By the way, what is <host_specific/>?

Thanks
Tuna

<host_specific/>: this pref is specifically used for this host.

Thanks. In the meantime, until this is fixed by GPUGRID, all I can do is to switch to local preferences on that host, and if I change the prefs on BAM!, I would need to manually repeat them on this host.

Willy, the thread on GPUGRID is https://www.gpugrid.net/forum_thread.php?id=4240. The comment there is below. I am out of my depth here. Can you help, please? Do you have an account there?



Clearly, since I am now using manual override on the host in question, there exists a global_prefs_overide.xml. But the whole idea of having different prefs per machine and BAM! sending them down to the hosts vs. Richard's response above seem to contradict (along with seemingly only 3 out of 50 projects doing that, and only one correctly), and I don't have enough knowledge and authority to contribute much.

The way things stand, it would seem to me that GPUGRID would override any host-specific Work Preferences created on BAM!, making the whole feature useless. Unless, somehow, I am caught in some la-la-land here, and enjoying the fruits of some weird set of circumstances that nobody else is...

Thankful for any help you can provide...
Tuna

The inner workings of the BOINC client are sometimes somewhat mysterious. However, I did not write a single line of code for it so I'm not sure why it's behaving like it's behaving.

What I do know is the client should use the preferences from whatever project (including BAM!) you changed the prefs last. But only BAM! can (as far as I know) issue host specific prefs and they should be used before anything else.

If the client is not behaving like it should there is either a bug in the client or one of the projects is sending wrong pref-XML.

So, sometime yesterday (about 32.5hrs ago) I switched to manually overridden settings on this host (.ie. just typed the 02:00-18:00 values into the dialog myself), and now I see this:

C:\ProgramDataBOINC>findstr global_preferences *reply*.xml

acct_mgr_reply.xml: <global_preferences>

acct_mgr_reply.xml: </global_preferences>

In other words, all the project reply files are now NOT sending a global_preferences section, including DistributedDataMining, POEM and GPUGRID, which were yesterday.

Interesting. I'll reset the machine back to using BAM!'s non-global host-specific settings for this machine and see what happens in a few hours.

Tuna

And, as I expected, as soon as I reverted the host to using BAM!'s settings, right after BAM!'s reply with 02:00-18:00, GPUGRID (and ONLY GPUGRID and not any of the other 48 projects I have running on this host) also sends another reply with 0:00-0:00, resetting the time restriction to nothing. I'll let them know...

C:\ProgramDataBOINC>findstr global_preferences *reply*.xml

acct_mgr_reply.xml: <global_preferences>

acct_mgr_reply.xml: </global_preferences>

sched_reply_www.gpugrid.net.xml:<global_preferences>

sched_reply_www.gpugrid.net.xml:</global_preferences>



C:\ProgramDataBOINC>dir *reply*gpugrid*.xml

 Volume in drive C has no label.

 Volume Serial Number is 7CC4-B6B1



 Directory of CrogramDataBOINC



01/23/2016  10:37 PM             6,067 sched_reply_www.gpugrid.net.xml

               1 File(s)          6,067 bytes

               0 Dir(s)  91,296,366,592 bytes free



C:\ProgramDataBOINC>dir acct_mgr_reply.xml

 Volume in drive C has no label.

 Volume Serial Number is 7CC4-B6B1



 Directory of CrogramDataBOINC



01/23/2016  10:30 PM             2,398 acct_mgr_reply.xml

               1 File(s)          2,398 bytes

               0 Dir(s)  91,296,362,496 bytes free

Tuna