This is not good. I first thought that this was a bug in the Account Manager BAM!, and posted it on their forum. But the owner Willy's reponse made me dig deeper, and found out that GPUGRID's reply back to the host including a <global_preferences> section with wrong data was resetting the time restriction to NONE.

My posts there are rather detailed, and I didn't want to copy/paste it here. Please jump to https://boincstats.com/en/forum/18/10640 to see the details. There are two ways to fix it: Either do not include the <global_preferences> section in your reply, or do what POEM does and include a <venue name="..."> section with the correct data. I would think the first one is easier...

Thanks
Tuna

---

Transferring <global_preferences> from project to project via the scheduler_request and scheduler_reply files is part of the fundamental design of BOINC. Those settings are defined to be global (love them or loathe them).

If it's a problem, use global_prefs_overide on the machine you want to crunch here.

Richard, I urge you to read the full thread on BOINCstats I linked to in my original post on this thread here. I have done a few other tests and added the results to that thread which puts GPUGRID squarely into the hot seat. As fundamental as this might be, out of the 49 projects this particular host churns through, it is only GPUGRID that does this. A few things I can think of:

- Maybe a project needs to NOT include this section in its reply if the original values are coming from an account manager (and the project knows this since the URL of the basis is in the global_preferences section as "<source_project>http://bam.boincstats.com/</source_project>"): BAM! & GridRepublic are the current managers, I believe... After all, shuffling such values from project to project makes more sense in the absence of a manager, so that changing global settings in one project will spread to all; but an account manager already takes care of that.

- Or, GPUGRID is not dealing with the data given to it via the sched_request_www.gpugrid.net.xml before GPUGRID sends its reply, since the request has this "venue" data which GPUGRID completely ignores and omits in its reply:

<global_preferences>
   <source_project>http://bam.boincstats.com/</source_project>
   . . .
   <start_hour>0</start_hour>
   . . .
   <end_hour>0</end_hour>
   . . .
   <venue name="No TV Recording">
      . . .
      <end_hour>18</end_hour>
      . . .
      <start_hour>2</start_hour>
   </venue>
</global_preferences>

Thanks
Tuna

This is not good. I first thought that this was a bug in the Account Manager BAM!, and posted it on their forum. But the owner Willy's reponse made me dig deeper, and found out that GPUGRID's reply back to the host including a <global_preferences> section with wrong data was resetting the time restriction to NONE.

I really don't know if this is related, but I have nothing else to hang it on, so I will mention it here. I usually set my resource share to "0", so that my GTX 750 Ti's operate with a zero cache and can return their results within the 24 hour bonus time limit. However, on two different machines (with two GTX 750 Ti's on each machine), I find that the work units often download an hour or two early. That is not supposed to be able to happen.

You need to set in Computing Preferences

Store at least 0

Store additional 0

Nothing to do with resource share this is only relative to other projects you may be running

Until a month or two ago, it was sufficient just to set resource share to zero, regardless of the buffer settings. In fact, that was another advantage, so that I could maintain a non-zero buffer size for my CPU projects. But apparently something changed recently; maybe it was a BOINC update, or maybe the project server?