<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.distributed.boinc.devel">
    <title>gmane.comp.distributed.boinc.devel</title>
    <link>http://blog.gmane.org/gmane.comp.distributed.boinc.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6558"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6554"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6551"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6550"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6548"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6547"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6543"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6540"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6539"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6535"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6524"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6512"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6510"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6499"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6479"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6474"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6467"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6466"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6462"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6460"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6558">
    <title>[patch] .po files with issues</title>
    <link>http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6558</link>
    <description>&lt;pre&gt;Hello,

Debian performs a routine check on the .po files in all its packages. The one of BOINC 
http://i18n.debian.org/l10n-pkg-status/b/boinc.html
indicates a few issues. I then ran
msgfmt -c -o /dev/null &amp;lt;po file&amp;gt;
as indicated and for de.po prepared the attached patch.

Cheers,

Steffen

&lt;/pre&gt;</description>
    <dc:creator>Steffen Möller</dc:creator>
    <dc:date>2013-05-24T21:11:13</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6554">
    <title>Intel GPUs</title>
    <link>http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6554</link>
    <description>&lt;pre&gt;I'm having trouble with OpenCL Intel GPU work requests.  The problem is no
work ever gets sent.
If the Intel GPU is requesting 108000 seconds of work would the
work_req_seconds show as 0?  Is that a bug or is the work_req_seconds now
deprecated?  The log on the server shows:


013-05-23 09:34:21.4934 [PID=27500]    [send] CPU: req 0.00 sec, 0.00
instances; est delay 0.00
013-05-23 09:34:21.4934 [PID=27500]    [send] Intel GPU: req 108000.00 sec,
1.00 instances; est delay 0.00
013-05-23 09:34:21.4934 [PID=27500]    [send] work_req_seconds: 0.00 secs
013-05-23 09:34:21.4934 [PID=27500]    [send] available disk 95.47 GB,
work_buf_min 86400
013-05-23 09:34:21.4934 [PID=27500]    [send] active_frac 0.999834 on_frac
0.999692
013-05-23 09:34:21.4934 [PID=27500]    [send] CPU features: fpu vme de pse
tsc msr pae mce cx8 apic sep mtrr pge mca c$
013-05-23 09:34:21.4941 [PID=27500]    Sending reply to [HOST#123978]: 0
results, delay req 181.80
013-05-23 09:34:21.4945 [PID=27500]    Scheduler ran 0.005 seconds


Jon So&lt;/pre&gt;</description>
    <dc:creator>Jon Sonntag</dc:creator>
    <dc:date>2013-05-23T14:50:25</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6551">
    <title>Behavior of core client/GPU apps when remote desktophits</title>
    <link>http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6551</link>
    <description>&lt;pre&gt;I'm having some difficulty figuring out how to handle some hosts that I
think are getting their GPU access cut off by remote desktop.

Here's one such host...

http://setiweb.ssl.berkeley.edu/beta/show_host_detail.php?hostid=62767
He's using BOINC 7.0.64

If you check out the tasks list you'll see two sets of GPU apps that are
failing.  The ati_cal apps are failing with an error "-226
(0xffffffffffffff1e) ERR_TOO_MANY_EXITS" when attempting to use the GPU.
The opencl apps are exiting with "201 (0xc9) EXIT_MISSING_COPROC" which I
assume is the appropriate exit code.

In both cases, the max_jobs_per_day in host_app_version is getting
decremented, so it will take many days for this host to recover should the
GPU come back.

Not much can be done about the version that returns the error except build
a version that recognizes the GPU is gone, and exit properly.  But should
the core client, rather than aborting a result that has an
EXIT_MISSING_COPROC, just not attempt to run it again until a GPU is
detected?

Mayb&lt;/pre&gt;</description>
    <dc:creator>Eric J Korpela</dc:creator>
    <dc:date>2013-05-22T17:12:17</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6550">
    <title>PHP errors in user.log and syslog</title>
    <link>http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6550</link>
    <description>&lt;pre&gt;I noticed my log files were really, really large lately.  I have about 20GB
of the same errors showing up in the user and syslog files:

May 18 06:23:49 debian2 suhosin[9247]: ALERT - script tried to increase
memory_limit to 268435456 bytes which is above the allowed value (attacker
'46.105.102.130', file '/home/boincadm/projects/collatz/html/inc/util.inc',
line 33)

Line 33 of util.inc contains:
ini_set("memory_limit", "256M");

Having never changed the default settings in /etc/php5/apache2/php.ini the
memory_limit was set to 128M.  It seems that BOINCs attempt to increase the
query size to 256M was seen as an attack.  Has the value always been 256M
or was it increased recently?  Or, is the 128M a change in a recent PHP
version? I am using PHP 5.3.3-7+squeeze14 with Suhosin-Patch (cli) (built:
Aug  6 2012 14:18:06)

If BOINC needs to be 256M, then maybe something should be added to the
server install documentation that explains how the PHP settings need to be
edited to allow 256M to avoid every client visit&lt;/pre&gt;</description>
    <dc:creator>Jon Sonntag</dc:creator>
    <dc:date>2013-05-22T14:45:30</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6548">
    <title>7.1.1 also getting new work for suspended project</title>
    <link>http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6548</link>
    <description>&lt;pre&gt;I suspended Constellation since "No New Work" wasn't preventing boinc from requesting
new work units from it and just noticed that it's still requesting work units from
constellation. Here's the section of stdoutdae.txt where it got another WU.

5/21/2013 2:29:52 PM |  | [work_fetch] ------- start work fetch state -------
5/21/2013 2:29:52 PM |  | [work_fetch] target work buffer: 83808.00 + 11232.00 sec
5/21/2013 2:29:52 PM |  | [work_fetch] --- project states ---
5/21/2013 2:29:52 PM | The Lattice Project | [work_fetch] REC 0.000 prio 0.000000 can't
req work: suspended via Manager
5/21/2013 2:29:52 PM | superlinkattechnion | [work_fetch] REC 0.000 prio 0.000000 can't
req work: suspended via Manager
5/21/2013 2:29:52 PM | MindModeling&amp;lt; at &amp;gt;Beta | [work_fetch] REC 0.000 prio 0.000000 can't
req work: suspended via Manager
5/21/2013 2:29:52 PM | Constellation | [work_fetch] REC 24.280 prio 0.000000 can't req
work: suspended via Manager
5/21/2013 2:29:52 PM | rosetta&amp;lt; at &amp;gt;home | [work_fetch] REC 28.099 prio -0.065670 can &lt;/pre&gt;</description>
    <dc:creator>dball-HqyNYUSi2p9n0q4rP9l2pw&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2013-05-21T19:38:01</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6547">
    <title>Problems with 7.1.1 work fetch on projects set to Nonew tasks</title>
    <link>http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6547</link>
    <description>&lt;pre&gt;Yesterday, I upgraded to 7.1.1 and had to set the constellation project to "no new
tasks". I would have suspended it but it's work units take about 10 hours and it only
had about 2 hours to go on the one work unit it had.

Sometime late yesterday or overnight, it finished that work unit. However, even with "no
new tasks" set, it fetched another work unit at 11:11:41. I've included the relevant
section of stdoutdae.txt below. I included enough before and after the work fetch so you
can see that it definitely had "no new tasks" set.

FYI, the reason I set Constellation to "no new tasks" was because after the upgrade to
7.1.1, it started executing Constellation work units as NCI aqain, which it had not done
in 7.0.64, although it had this same problem in some earlier versions of 7.0.
Constellation is not NCI so this caused an extra work unit to be executed on my C2D
E6420, which slowed down other work units and anything that ran on the system.

I aborted the new Constellation work unit if fetched at 11:11:41 an&lt;/pre&gt;</description>
    <dc:creator>dball-HqyNYUSi2p9n0q4rP9l2pw&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2013-05-21T17:13:42</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6543">
    <title>Why won't Boinc schedule both GPUs?</title>
    <link>http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6543</link>
    <description>&lt;pre&gt;I am posting this here because the S&amp;lt; at &amp;gt;H Beta site message board will not let
me create a table.

 

Below you may see a table showing how Boinc scheduled the 2 GPUs in Computer
ID 52900 (S&amp;lt; at &amp;gt;H Beta) last night.  GPU 2 was vacant for most of the night.  My
conjecture is that when Boinc schedules an AP WU on one GPU, which is now
marked as using 0.805C + 1NV instead of the usual 0.02C + 1NV, it leaves the
other GPU vacant, but his does not explain all the rows in the table.  From
a credit per hour standpoint, it might be better to fully schedule the GPU
and let the O/S priority scheme worry about scheduling the CPU; if most of
the processes in the system are at normal priority, and Boinc tasks have a
lower priority, what it does it matter if the CPUs are over-scheduled?

 

Table: GPU Tasks scheduled on Computer 52900 (S&amp;lt; at &amp;gt;H Beta) 5/20/2013 

 


GPU 1

GPU 2



Start Time

Finish Time

WU Type

Start Time

Finish Time

WU Type


GPU GRID WU

GPU GRID WU



5/19 23:29

5/20 1:58

AP

-Infinity

1:53

GPU&lt;/pre&gt;</description>
    <dc:creator>Charles Elliott</dc:creator>
    <dc:date>2013-05-20T13:08:38</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6540">
    <title>Make 'receive PM of action taken by moderator' anopt-in option?</title>
    <link>http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6540</link>
    <description>&lt;pre&gt;Hi David,

Can't we make the 'action taken by moderator' PMs an opt-in option in
the preferences? I have just moved 29 messages between two people,
they'll both be looking at ~14 PMs detailing how I moved their posts
to a new thread. As if they didn't know this, they requested the move
themselves.

I also get PMs when I make a new thread and lock it, rename it,
sticky/desticky it. Normal moderator actions that don't really need
these messages. So, please, can we get a preference that says "Don't
receive PMs on moderator actions on your posts", with the default
being on, but the option to opt-out?

--
&lt;/pre&gt;</description>
    <dc:creator>Jorden van der Elst</dc:creator>
    <dc:date>2013-05-20T01:38:42</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6539">
    <title>Host getting more tasks that limits allow.</title>
    <link>http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6539</link>
    <description>&lt;pre&gt;There is a Boinc 7.0.64 host over at Setiathome that has at present got 
~2000 GPU tasks,
when it should be limited to 100 CPU tasks and 100 GPU tasks:

http://setiathome.berkeley.edu/forum_thread.php?id=71687

http://setiathome.berkeley.edu/results.php?hostid=6165045&amp;amp;offset=460&amp;amp;show_names=1&amp;amp;state=0&amp;amp;appid=



It's still managing to pick up fresh GPU tasks too, Any idea why?

Claggy
&lt;/pre&gt;</description>
    <dc:creator>Stephen Maclagan</dc:creator>
    <dc:date>2013-05-19T16:42:32</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6535">
    <title>Admin Pages: Result summary per app version</title>
    <link>http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6535</link>
    <description>&lt;pre&gt;If I check the "list unofficial App versions" box I get the error:

Notice: Trying to get property of non-object in
/home/boincadm/projects/collatz/html/ops/pass_percentage_by_platform.php on
line 121 Database Error

at the top of the page and with the listing of the apps:

Notice: Trying to get property of non-object in
/home/boincadm/projects/collatz/html/ops/pass_percentage_by_platform.php on
line 123 Notice: Trying to get property of non-object


I'll dig into it further unless it has already been fixed in a more recent
version.

Jon Sonntag
&lt;/pre&gt;</description>
    <dc:creator>Jon Sonntag</dc:creator>
    <dc:date>2013-05-17T23:04:08</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6524">
    <title>possible typo in configure.ac</title>
    <link>http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6524</link>
    <description>&lt;pre&gt;/me wonders if here's an unwanted "x" :

AM_CONDITIONAL(ENABLE_MANAGER, [ test "x${ac_cv_have_wxwidgets}" = xyes


BTW is still wxwidgets version &amp;lt;= 2.8.x required ?

&lt;/pre&gt;</description>
    <dc:creator>Toralf Förster</dc:creator>
    <dc:date>2013-05-16T17:40:02</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6512">
    <title>The ways in that BOINC tells app to quit</title>
    <link>http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6512</link>
    <description>&lt;pre&gt; Trying to solve non-suspending issue listed in this thread:  http://setiathome.berkeley.edu/forum_thread.php?id=71581&amp;amp;postid=1365551
I came to conclusion that either BOINC does something wrong in this situation or app doesn't check all needed flags and not aware about exit request.

I check these flags:
boinc_status.quit_request
boinc_status.abort_request

Maybe some another flag BOINC sets to inform app that suspend required ? 
_______________________________________________
boinc_dev mailing list
boinc_dev&amp;lt; at &amp;gt;ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.&lt;/pre&gt;</description>
    <dc:creator>Raistmer the Sorcerer</dc:creator>
    <dc:date>2013-05-10T23:46:24</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6510">
    <title>GPU and service under Windows</title>
    <link>http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6510</link>
    <description>&lt;pre&gt;We are considering using BOINC in an enterprise environment so I'm trying
the configure the client to be as invisible as possible to the user and
the only way I found was to install it as service (Protected application
execution) and uncheck "Allow all users on this computer to control
BOINC". It works well for our CPU application except we can't use the GPU.

Is there another to configure the BOINC client to be 'invisible' to the
user and have access to the CPU?

Thanks

Seb

&lt;/pre&gt;</description>
    <dc:creator>slauzier-ia4VozXN7idAFePFGvp55w&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2013-05-10T16:44:39</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6499">
    <title>Workunits no longer usable</title>
    <link>http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6499</link>
    <description>&lt;pre&gt;Hello:

 

                The S&amp;lt; at &amp;gt;H Beta site just released a new executable for plan
class cuda50.  For some reason the 

beta server does not recognize plan class cudaNN  (NN = 50, 42, 32, 22,
etc.); it  will only deliver WUs to 

a computer whose app_info file contains plan class cuda_fermi,
opencl_nvidia_100, etc.  So just as I 

had done when cuda42 came out, I changed all the references in these plan
classes from cuda42 to cuda50.  

I copied the Boinc data directory to a different hard disk, shut off the
network, and restarted Boinc.  

This was at 20:55:31.  Everything appeared to be working: Boinc deleted no
WUs, was using the new 

cuda50 executable to process the WUs it had, and communication with the
server proceeded normally, 

at least 10 times.  Then at 22:34:13, almost 2 hours after the change,
Boinc, the server, whatever, decided 

to delete about 5,000 WUs, saying "Result 01mr13ab.6367.7433.11.16.27_2 is
no longer usable," etc.  

There is no error message, absolutely no hint as to what is w&lt;/pre&gt;</description>
    <dc:creator>Charles Elliott</dc:creator>
    <dc:date>2013-05-07T14:08:23</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6479">
    <title>ASIC miners</title>
    <link>http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6479</link>
    <description>&lt;pre&gt;Hi!

Are you planning to support Bitcoin ASIC miners? (
http://www.butterflylabs.com/ )

At the moment I'm trying to use Wrapper method to BOINCify Bitcoin GPU
miners, but I still haven't figured it out...

Henri.
&lt;/pre&gt;</description>
    <dc:creator>Henri Heinonen</dc:creator>
    <dc:date>2013-05-05T10:10:47</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6474">
    <title>Boinc and XPM files problem</title>
    <link>http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6474</link>
    <description>&lt;pre&gt;Hi All, don't know if makes sense to report to you this problem.

Your xpm res files starts with the copyright comment
// Berkeley Open Infrastructure for Network Computing

[...]

// 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA


Many programs doesn't find when looking for the xpm resource

quoting the mail from Rodrigo Silva
header. So they don't thumbnail, no editor besides eog cannot open them, etc.

This is why in debian I accepted a patch for switching between xpm to png files
http://anonscm.debian.org/gitweb/?p=pkg-boinc/boinc.git;a=commit;h=83a343230bf609e29cf74e73d02107dd718fa6c9


Don't know, the solution might be put the copyright at the bottom?
Converting to png too?

Just reporting the problem


Gianfranco
&lt;/pre&gt;</description>
    <dc:creator>Gianfranco Costamagna</dc:creator>
    <dc:date>2013-05-04T09:54:56</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6467">
    <title>php warning messages</title>
    <link>http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6467</link>
    <description>&lt;pre&gt;Hi all,

 

I recently upgraded the NumberFields project to the latest branch
(boinc-v2).  I am now getting a bunch of warnings on the admin pages like
the following:

 

"Warning: Creating default object from empty value in
/home/boincadm/projects/NumberFields/html/inc/db_ops.inc on line 520"



I can turn off these warnings in the php code by using error_reporting(), in
which case the site acts just like it used to.  But are these warnings
telling me there is a problem somewhere in the php code, and if so does
anyone know how to fix this?

 

Thanks in advance!

Eric

 

&lt;/pre&gt;</description>
    <dc:creator>Eric Driver</dc:creator>
    <dc:date>2013-05-04T01:57:29</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6466">
    <title>twitter bootstrap and boinc</title>
    <link>http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6466</link>
    <description>&lt;pre&gt;Hello

I'm working on the php pages of BOINC using twitter bootstrap. You can have
a look to the status at http://alfa.ibercivis.es/ibercivis_alfa/index.php,
(not fully functional yet).

I read in the list that some people worked in this issue  time ago, do you
know something about that?

I´ll publish the code in github when finished

Un saludo

Francisco
&lt;/pre&gt;</description>
    <dc:creator>Francisco Sanz García</dc:creator>
    <dc:date>2013-05-03T09:18:13</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6462">
    <title>Scheduler returns "No end tag"</title>
    <link>http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6462</link>
    <description>&lt;pre&gt;Hello everyone,

Our project recently upgraded our 2010 BOINC server to commit 2091b257876cfdc4f12fedc0f2a1116f1c85cd8f and now when processing requests from clients, our server often says:

SCHEDULER_REQUEST::parse(): unexpected: ...a part of our result's stderr...
Incomplete request received from IP ......


And the message "no end tag" is displayed on the client's UI.

I am wondering if  this error is related to the size of our task's stderr because our task does produce a remarkably large stderr but this error didn't happen to us when we used our 2010 BOINC server source code. 

Any help would be very much appreciated.

Best regards,
&lt;/pre&gt;</description>
    <dc:creator>Nx Hien</dc:creator>
    <dc:date>2013-05-02T19:09:23</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6460">
    <title>automatic minimum buffer size.</title>
    <link>http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6460</link>
    <description>&lt;pre&gt;I have been thinking about what the appropriate automatic sizes for work fetch and EDF trigger are for work fetch and for EDF for rr_sim.

If we track the longest duration (over the past N months) from the first time that a task reports as 100% complete till report is complete pre project, then:

The minimum required work buffer is the smallest of these across all projects able to fetch work.  Eg.  Project A has a 1 week value, project B has a 1 hour value, the minimum work buffer would be 1 hour.

For each project, any task that exceeds report deadline for the task - the longest durataion from 100% to report complete needs to be marked as requiring EDF.

It would also be useful if the projects could have a tag that could be set to indicate they expected to be offline for N seconds (probably entered as days and converted to seconds).  The maximum of this and the largest duration already recorded would be used for this.

For example, SETI would normally have this set to 0.4 days to indicate the weekly outage.&lt;/pre&gt;</description>
    <dc:creator>McLeod, John</dc:creator>
    <dc:date>2013-05-01T13:31:39</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6459">
    <title>rr_sim and work fetch</title>
    <link>http://comments.gmane.org/gmane.comp.distributed.boinc.devel/6459</link>
    <description>&lt;pre&gt;I recently posted a simulation that misbehaved because of short comings in the rr_sim function.  The problem in that case was that there was a single CPU task that was running high priority (as it should), and a multi CPU task that was longer than the minimum work buffer.  The problem is that the client will not in that case download any work from anywhere to fill the CPU that is idle.

One possible solution:

Run rr_sim in multiple passes, and track high priority tasks.  Track High Priority tasks and when they will complete.  Assume that once a task is high priority, it stays that way until complete (OK, not true in all cases, but I am trying to avoid the expense of an even more accurate method).

Pseudo code.
Run rr_sim - this marks tasks as requiring EDF or not.  Set a flag indicating if any new tasks were marked as EDF by rr_sim.
Use the results to supply information to a new function that simulates EDF for the tasks that are marked as requiring EDF.  The output of this feeds back into rr_sim.  Rr_sim no&lt;/pre&gt;</description>
    <dc:creator>McLeod, John</dc:creator>
    <dc:date>2013-05-01T13:08:51</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.distributed.boinc.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.distributed.boinc.devel</link>
  </textinput>
</rdf:RDF>
