Re: [boinc_dev] An additional preference to prevent, downloading when on WiFi, to enable downloading only on when connected, to cable

[McLeod, John]

lf Of
> Robert Miles
> Sent: Sunday, April 2, 2017 1:26 AM
> To: boinc_dev@ssl.berkeley.edu
> Subject: Re: [boinc_dev] An additional preference to prevent, downloading
> when on WiFi, to enable downloading only on when connected, to cable
>
>   From what I've seen, Windows operating systems do not allow multiple
> connections to the internet to be active at once, which means that only one
> such connection can be reachable from BOINC at any one time.
>
> On 3/30/2017 8:34 AM, boinc_dev-requ...@ssl.berkeley.edu wrote:
>> Date: Thu, 30 Mar 2017 16:15:55 +0300
>> From: Vitalii Koshura <lestat.de.lion...@gmail.com>
>> Subject: Re: [boinc_dev] An additional preference to prevent
>>  downloading when on WiFi, to enable downloading only on when
> connected
>>  to cable
>>
>> Hello gyus,
>>
>> Maybe it would be preferably to let user choose the connection BOINC
>> uses for download/upload?
>> So in this case BOINC need to detect all available connections and
>> make a checkbox list where user can choose which connection should be
>> used when available?
>> Because doind automated testing of connection speed is not good for
>> these purposes.
>>
>> Thanks
>>
>> Best regards,
>> Vitalii Koshura
>>
>> 2017-03-30 16:08 GMT+03:00 McLeod, John <john.mcl...@sap.com>:
>>
>>> We have had this discussion before -- back in the days when dialup
>>> was common.  Without doing an end to end test of the connection there
>>> is no way to tell what the connection speed is.  Dialup is still the
>>> way things are in some places in the world.  Based on dialup with a
>>> router and a switch, I can have a 1Gb connection locally but only a
>>> 1.3Kb connection to the outside world, and the computer cannot know
>>> without doing an end to end test.  With ADSL links (much more common
>>> at the moment) it is possible to have a 1Gb connection locally and a 5Mb
> connection to the outside world.
>>> Running a check like this against some BOINC BOINC projects could tip
>>> them over into congestion where nothing gets through.
>>>
>>> So, it would require:
>>> A selection for what high speed meant.
>>> A checkbox to indicate if enabled.
>>> An end to end check to see what the connection speed was.
>>> Some idea of when to use it as doing an end to end connection check
>>> when there was only a few hundred bytes to transfer does not seem
> reasonable.
>>> At the time it was decided that this was not something we wanted to
>>> pursue.  Of course, this can change.
>>>
>>> Jm7
>>>
>>> -Original Message-
>>> From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf
>>> Of David Wallom
>>> Sent: Thursday, March 30, 2017 8:28 AM
>>> To: elliott...@comcast.net; 'Nicol?s Alvarez'
>>> <nicolas.alva...@gmail.com>; Andy Bowery <andy.bow...@oerc.ox.ac.uk>
>>> Cc: boinc_dev@ssl.berkeley.edu
>>> Subject: Re: [boinc_dev] An additional preference to prevent
>>> downloading when on WiFi, to enable downloading only on when
>>> connected to cable
>>>
>>> Hi Charles,
>>>
>>> With the increasing prevalence of mobile computing devices then
>>> having the system (scheduler) doing the test is not really scalable
>>> as people move their devices.
>>>
>>> It would be much easier if the clients did this. My Mac for example
>>> is able to tell me the latest network bandwidth if has for any of its
>>> interfaces.
>>>
>>> David
>>> 
>>> From: boinc_dev [boinc_dev-boun...@ssl.berkeley.edu] on behalf of
>>> Charles Elliott [elliott...@comcast.net]
>>> Sent: 30 March 2017 13:10
>>> To: 'Nicol?s Alvarez'; Andy Bowery
>>> Cc: boinc_dev@ssl.berkeley.edu
>>> Subject: Re: [boinc_dev] An additional preference to prevent
>>> downloading when on WiFi, to enable downloading only on when
>>> connected to cable
>>>
>>> Boinc could just download a test file from the Oxford website 5 times
>>> and average the times.  If the average was above a limit deemed the
>>> minimum acceptable speed, the user would be permitted to proceed.
>>> OW, the Oxford website would post a very polite, very detailed, and
>>> very well written message to Boinc/the user explaining why a high
>>> bandwidth connection is necessary for the user's progress and enjoyment
> of Oxford's project.
>>> One o

Re: [boinc_dev] An additional preference to prevent downloading when on WiFi, to enable downloading only on when connected to cable

[McLeod, John]

Wired connections often do not have an identifying name.  I have wireless 
connections that are great (1/2Mb/s) sometimes and awful (1Kb/s) at others.  
the speed of a wirelass connection also depends on distance to the antenna, 
interference, and other traffic.  So a user out on the deck may have a much 
different experience than the same user in his living room.

From: Vitalii Koshura [mailto:lestat.de.lion...@gmail.com]
Sent: Thursday, March 30, 2017 2:48 PM
To: McLeod, John <john.mcl...@sap.com>
Cc: Richard Haselgrove <r.haselgr...@btopenworld.com>; BOINC Developers Mailing 
List <boinc_dev@ssl.berkeley.edu>
Subject: RE: [boinc_dev] An additional preference to prevent downloading when 
on WiFi, to enable downloading only on when connected to cable

Ok, but why we need to do the automatic speed test? Why user can't do the same 
manually​ once and set this setting to boinc?
Best regards,
Vitalii

Sent via Android

30 марта 2017 г. 21:16 пользователь "McLeod, John" 
<john.mcl...@sap.com<mailto:john.mcl...@sap.com>> написал:
The reason for test data is that you can't tell the true speed of a connection 
to the internet by just looking at the connection from the computer to the 
first network appliance.

-Original Message-
From: boinc_dev 
[mailto:boinc_dev-boun...@ssl.berkeley.edu<mailto:boinc_dev-boun...@ssl.berkeley.edu>]
 On Behalf Of Vitalii Koshura
Sent: Thursday, March 30, 2017 10:00 AM
To: Richard Haselgrove 
<r.haselgr...@btopenworld.com<mailto:r.haselgr...@btopenworld.com>>
Cc: boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu>
Subject: Re: [boinc_dev] An additional preference to prevent downloading when 
on WiFi, to enable downloading only on when connected to cable

So if your laptop so mobile maybe there will be a better choice just to
schedule upload/download? E.g. if you know that everty evening you're at
home - then upload all done results and download new jobs for ~1 day.
But if your laptop stays at one place for days then you'll probably know
which network connections is better.
I do not understand the reasons why we need to upload/download trash data
just for testing every time.

Best regards,
Vitalii Koshura

2017-03-30 16:29 GMT+03:00 Richard Haselgrove 
<r.haselgr...@btopenworld.com<mailto:r.haselgr...@btopenworld.com>>
:

> The trouble is, there are too many networking variables to easily boil
> down to a single parameter.
> NIC to router - WiFi (802.11n) is pretty good these days.Router to
> internet - depends on locationInternet to project server - I think the
> example Charles was thinking of was GPUGrid in Barcelona, which went
> through a bad connectivity patch last year, but is communicating properly
> again now. Doesn't affect their reliance on high-performance GPUs, which is
> a different question.
> I've just run speedtest on my six year old Windows 7 laptop, and got 48.34
> Mbits download and 9.28 Mbits upload over WiFi - that's very close to my
> home broadband connection of 50.33 Mbps / 9.765 Mbps. But the results might
> be very different in my local cafe / pub / seminar room / public hotspot.
> We can't equate connection *type* with connection *speed*.
>
> On Thursday, 30 March 2017, 13:28, David Wallom <
> david.wal...@oerc.ox.ac.uk<mailto:david.wal...@oerc.ox.ac.uk>> wrote:
>
>
>  Hi Charles,
>
> With the increasing prevalence of mobile computing devices then having the
> system (scheduler) doing the test is not really scalable as people move
> their devices.
>
> It would be much easier if the clients did this. My Mac for example is
> able to tell me the latest network bandwidth if has for any of its
> interfaces.
>
> David
> 
> From: boinc_dev 
> [boinc_dev-boun...@ssl.berkeley.edu<mailto:boinc_dev-boun...@ssl.berkeley.edu>]
>  on behalf of Charles
> Elliott [elliott...@comcast.net<mailto:elliott...@comcast.net>]
> Sent: 30 March 2017 13:10
> To: 'Nicolás Alvarez'; Andy Bowery
> Cc: boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu>
> Subject: Re: [boinc_dev] An additional preference to prevent downloading
> when on WiFi, to enable downloading only on when connected to cable
>
> Boinc could just download a test file from the Oxford website 5 times and
> average the times.  If the average was above a limit deemed the minimum
> acceptable speed, the user would be permitted to proceed.  OW, the Oxford
> website would post a very polite, very detailed, and very well written
> message to Boinc/the user explaining why a high bandwidth connection is
> necessary for the user's progress and enjoyment of Oxford's project.
>
> One of the Boinc GPU projects, as I recall in Spain, does this now WRT the
> capacity of the user's GPU(s).  It is no fun for

Re: [boinc_dev] An additional preference to prevent downloading when on WiFi, to enable downloading only on when connected to cable

[McLeod, John]

The reason for test data is that you can't tell the true speed of a connection 
to the internet by just looking at the connection from the computer to the 
first network appliance.  

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Vitalii Koshura
Sent: Thursday, March 30, 2017 10:00 AM
To: Richard Haselgrove 
Cc: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] An additional preference to prevent downloading when 
on WiFi, to enable downloading only on when connected to cable

So if your laptop so mobile maybe there will be a better choice just to
schedule upload/download? E.g. if you know that everty evening you're at
home - then upload all done results and download new jobs for ~1 day.
But if your laptop stays at one place for days then you'll probably know
which network connections is better.
I do not understand the reasons why we need to upload/download trash data
just for testing every time.

Best regards,
Vitalii Koshura

2017-03-30 16:29 GMT+03:00 Richard Haselgrove 
:

> The trouble is, there are too many networking variables to easily boil
> down to a single parameter.
> NIC to router - WiFi (802.11n) is pretty good these days.Router to
> internet - depends on locationInternet to project server - I think the
> example Charles was thinking of was GPUGrid in Barcelona, which went
> through a bad connectivity patch last year, but is communicating properly
> again now. Doesn't affect their reliance on high-performance GPUs, which is
> a different question.
> I've just run speedtest on my six year old Windows 7 laptop, and got 48.34
> Mbits download and 9.28 Mbits upload over WiFi - that's very close to my
> home broadband connection of 50.33 Mbps / 9.765 Mbps. But the results might
> be very different in my local cafe / pub / seminar room / public hotspot.
> We can't equate connection *type* with connection *speed*.
>
> On Thursday, 30 March 2017, 13:28, David Wallom <
> david.wal...@oerc.ox.ac.uk> wrote:
>
>
>  Hi Charles,
>
> With the increasing prevalence of mobile computing devices then having the
> system (scheduler) doing the test is not really scalable as people move
> their devices.
>
> It would be much easier if the clients did this. My Mac for example is
> able to tell me the latest network bandwidth if has for any of its
> interfaces.
>
> David
> 
> From: boinc_dev [boinc_dev-boun...@ssl.berkeley.edu] on behalf of Charles
> Elliott [elliott...@comcast.net]
> Sent: 30 March 2017 13:10
> To: 'Nicolás Alvarez'; Andy Bowery
> Cc: boinc_dev@ssl.berkeley.edu
> Subject: Re: [boinc_dev] An additional preference to prevent downloading
> when on WiFi, to enable downloading only on when connected to cable
>
> Boinc could just download a test file from the Oxford website 5 times and
> average the times.  If the average was above a limit deemed the minimum
> acceptable speed, the user would be permitted to proceed.  OW, the Oxford
> website would post a very polite, very detailed, and very well written
> message to Boinc/the user explaining why a high bandwidth connection is
> necessary for the user's progress and enjoyment of Oxford's project.
>
> One of the Boinc GPU projects, as I recall in Spain, does this now WRT the
> capacity of the user's GPU(s).  It is no fun for, or use to, anyone if the
> user processes a work unit on an older GPU, the GPU overheats, and the WU
> fails 3/4 of the way through.  It is annoying though.
>
> Charles Elliott
>
> -Original Message-
> From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of
> Nicolás Alvarez
> Sent: Wednesday, March 29, 2017 3:40 PM
> To: Andy Bowery
> Cc: BOINC Developers Mailing List ‎[boinc_dev@ssl.berkeley.edu]‎
> Subject: Re: [boinc_dev] An additional preference to prevent downloading
> when on WiFi, to enable downloading only on when connected to cable
>
> 2017-03-29 14:45 GMT-03:00 Andy Bowery :
> > Hi,
> >
> > We would be interested in an additional BOINC preference, a tickbox on
> the 'Network' tab, with something like 'Download only when connected to a
> high bandwidth connection'. Ticking the box of this preference would
> prevent download of the application and supporting files when the machine
> (for example: a laptop) was connected only to WiFi and not connected to a
> higher bandwidth networking cable. Would it be possible for this to be
> scheduled to be added as an item to be included in a later release?
> >
> > With regards,
> >
>
> What does "high bandwidth connection" mean, how could BOINC know if it's
> connected to one?
>
> --
> Nicolás
> ___
> boinc_dev mailing list
> boinc_dev@ssl.berkeley.edu
> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
>
> 

Re: [boinc_dev] An additional preference to prevent downloading when on WiFi, to enable downloading only on when connected to cable

[McLeod, John]

We have had this discussion before -- back in the days when dialup was common.  
Without doing an end to end test of the connection there is no way to tell what 
the connection speed is.  Dialup is still the way things are in some places in 
the world.  Based on dialup with a router and a switch, I can have a 1Gb 
connection locally but only a 1.3Kb connection to the outside world, and the 
computer cannot know without doing an end to end test.  With ADSL links (much 
more common at the moment) it is possible to have a 1Gb connection locally and 
a 5Mb connection to the outside world.  Running a check like this against some 
BOINC BOINC projects could tip them over into congestion where nothing gets 
through.
 
So, it would require:
A selection for what high speed meant.
A checkbox to indicate if enabled.
An end to end check to see what the connection speed was.
Some idea of when to use it as doing an end to end connection check when there 
was only a few hundred bytes to transfer does not seem reasonable.

At the time it was decided that this was not something we wanted to pursue.  Of 
course, this can change.

Jm7

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of David 
Wallom
Sent: Thursday, March 30, 2017 8:28 AM
To: elliott...@comcast.net; 'Nicolás Alvarez' ; Andy 
Bowery 
Cc: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] An additional preference to prevent downloading when 
on WiFi, to enable downloading only on when connected to cable

Hi Charles,

With the increasing prevalence of mobile computing devices then having the 
system (scheduler) doing the test is not really scalable as people move their 
devices.

It would be much easier if the clients did this. My Mac for example is able to 
tell me the latest network bandwidth if has for any of its interfaces.

David

From: boinc_dev [boinc_dev-boun...@ssl.berkeley.edu] on behalf of Charles 
Elliott [elliott...@comcast.net]
Sent: 30 March 2017 13:10
To: 'Nicolás Alvarez'; Andy Bowery
Cc: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] An additional preference to prevent downloading when 
on WiFi, to enable downloading only on when connected to cable

Boinc could just download a test file from the Oxford website 5 times and 
average the times.  If the average was above a limit deemed the minimum 
acceptable speed, the user would be permitted to proceed.  OW, the Oxford 
website would post a very polite, very detailed, and very well written message 
to Boinc/the user explaining why a high bandwidth connection is necessary for 
the user's progress and enjoyment of Oxford's project.

One of the Boinc GPU projects, as I recall in Spain, does this now WRT the 
capacity of the user's GPU(s).  It is no fun for, or use to, anyone if the user 
processes a work unit on an older GPU, the GPU overheats, and the WU fails 3/4 
of the way through.  It is annoying though.

Charles Elliott

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Nicolás Alvarez
Sent: Wednesday, March 29, 2017 3:40 PM
To: Andy Bowery
Cc: BOINC Developers Mailing List ‎[boinc_dev@ssl.berkeley.edu]‎
Subject: Re: [boinc_dev] An additional preference to prevent downloading when 
on WiFi, to enable downloading only on when connected to cable

2017-03-29 14:45 GMT-03:00 Andy Bowery :
> Hi,
>
> We would be interested in an additional BOINC preference, a tickbox on the 
> 'Network' tab, with something like 'Download only when connected to a high 
> bandwidth connection'. Ticking the box of this preference would prevent 
> download of the application and supporting files when the machine (for 
> example: a laptop) was connected only to WiFi and not connected to a higher 
> bandwidth networking cable. Would it be possible for this to be scheduled to 
> be added as an item to be included in a later release?
>
> With regards,
>

What does "high bandwidth connection" mean, how could BOINC know if it's 
connected to one?

--
Nicolás
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu

Re: [boinc_dev] BOINC Account Manager & Password Keys

[McLeod, John]

A BOPINC account manager is specifically for cross site account management.  
There are 2 of them so far, BOINC Stats BAM and Grid Republic.  Why do you 
believe you need to implement this code?

JM7 
-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Brian
Sent: Thursday, March 16, 2017 1:07 PM
To: boinc_dev@ssl.berkeley.edu
Subject: [boinc_dev] BOINC Account Manager & Password Keys

Hi,

I am working on a research pool for Gridcoin. Part of this development 
involves an account management piece to the site. During the development 
of the account manager, I noticed when BOINC client makes an account 
manager request to my server, it passes all projects that are attached 
to it into the account manager regardless of what attached it. This data 
includes the password keys to the projects which are not currently 
attached to my account manager. It appears I could take these account 
keys to gain access to individuals accounts for those projects.

Just mostly an observation, not sure if this has been discussed or not...

Thanks for your time,

Brian Burkhardt...

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] boinc_dev Digest, Vol 153, Issue 3

[McLeod, John]

Or if some other task needs high priority.

From: Jord van der Elst [mailto:els...@gmail.com]
Sent: Tuesday, March 7, 2017 3:40 PM
To: McLeod, John <john.mcl...@sap.com>
Cc: Robert Miles <robertmi...@bellsouth.net>; boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] boinc_dev Digest, Vol 153, Issue 3

What John is looking for is called "Leave Non-GPU tasks in memory when 
suspended", used to be "Leave applications in memory".
With this switched on, tasks that suspend keep their whole state in memory. 
With it switched off tasks that don't checkpoint start from the beginning, 
tasks that checkpoint start from the last checkpoint. But tasks that don't 
checkpoint usually don't switch out of memory until they're done. They can only 
switch out of memory when the user forces the task to do so (suspend), or by 
quitting BOINC.


-- Jord van der Elst.

On Tue, Mar 7, 2017 at 3:09 PM, McLeod, John 
<john.mcl...@sap.com<mailto:john.mcl...@sap.com>> wrote:
It depends.  If you suspend a task and return all the memory, then you lose any 
forward progress since the last check point.  There is a setting that allows 
the removal from memory (or at least there used to be), but I don't remember 
what it is.  A suspended task's memory can go to swap with no problem as it 
will not be touched until the next time that the task is resumed.

-Original Message-
From: boinc_dev 
[mailto:boinc_dev-boun...@ssl.berkeley.edu<mailto:boinc_dev-boun...@ssl.berkeley.edu>]
 On Behalf Of Robert Miles
Sent: Tuesday, March 7, 2017 8:22 AM
To: boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu>
Subject: Re: [boinc_dev] boinc_dev Digest, Vol 153, Issue 3

 From what I've seen, when BOINC suspends workunits, this DOES NOT free the
memory they are using.

It looks like BOINC should not be allowed to start a workunit without
checking
whether enough memory is still free, and it should then be required to
repeat
this check before starting the next one.
> Date: Mon, 6 Mar 2017 21:27:47 +0100
> From: yoyo <y...@mailueberfall.de<mailto:y...@mailueberfall.de>>
> To: BOINC Developers Mailing List 
> <boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu>>,   BOINC
>   Projects 
> <boinc_proje...@ssl.berkeley.edu<mailto:boinc_proje...@ssl.berkeley.edu>>
> Subject: [boinc_dev] Boinc handling of workunits with much RAM
>   requirements
>
> Hello,
>
> I'd like to understand what Boinc does with workunits which require a
> large amount of RAM.
>
> I have workunits which require 10 GB RAM.
> My understandig is, that only hosts which have at least 10 GB free RAM
> are downloading them and only if 10 GB RAM are free they are started?
>
> It is not clear for me what happens when the workunits are running and
> if and how often Boinc checks their RAM consumption and what Boinc does
> if they consume too much RAM.
>
> A user blames, that he has a system with 8 cores and 16 GB RAM. This
> systems has more than 10GB free RAM. So such workunits are downloaded
> and started, 8 of them in parallel at the same time. After some seconds
> all 8 workunits consuming 10 GB RAM each and the system is havily
> swaping and nearly unresponsive.
> Shouldn't Boinc find out, that too much RAM is consumed and suspend some
> of the workunits?
>
> Kind regards,
> yoyo

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@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.

___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] boinc_dev Digest, Vol 153, Issue 3

[McLeod, John]

It depends.  If you suspend a task and return all the memory, then you lose any 
forward progress since the last check point.  There is a setting that allows 
the removal from memory (or at least there used to be), but I don't remember 
what it is.  A suspended task's memory can go to swap with no problem as it 
will not be touched until the next time that the task is resumed.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Robert 
Miles
Sent: Tuesday, March 7, 2017 8:22 AM
To: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] boinc_dev Digest, Vol 153, Issue 3

 From what I've seen, when BOINC suspends workunits, this DOES NOT free the
memory they are using.

It looks like BOINC should not be allowed to start a workunit without 
checking
whether enough memory is still free, and it should then be required to 
repeat
this check before starting the next one.
> Date: Mon, 6 Mar 2017 21:27:47 +0100
> From: yoyo 
> To: BOINC Developers Mailing List ,   BOINC
>   Projects 
> Subject: [boinc_dev] Boinc handling of workunits with much RAM
>   requirements
>
> Hello,
>
> I'd like to understand what Boinc does with workunits which require a
> large amount of RAM.
>
> I have workunits which require 10 GB RAM.
> My understandig is, that only hosts which have at least 10 GB free RAM
> are downloading them and only if 10 GB RAM are free they are started?
>
> It is not clear for me what happens when the workunits are running and
> if and how often Boinc checks their RAM consumption and what Boinc does
> if they consume too much RAM.
>
> A user blames, that he has a system with 8 cores and 16 GB RAM. This
> systems has more than 10GB free RAM. So such workunits are downloaded
> and started, 8 of them in parallel at the same time. After some seconds
> all 8 workunits consuming 10 GB RAM each and the system is havily
> swaping and nearly unresponsive.
> Shouldn't Boinc find out, that too much RAM is consumed and suspend some
> of the workunits?
>
> Kind regards,
> yoyo

___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] [BOINC/boinc] 341001: lib: remove safe_copy(); not used, generated compi...

[McLeod, John]

The second would be far better.  It would tend to stop memory leaks from 
occurring.

-Original Message-
From: Christian Beer [mailto:christian.b...@aei.mpg.de] 
Sent: Tuesday, January 3, 2017 10:13 AM
To: McLeod, John <john.mcl...@sap.com>; boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] [BOINC/boinc] 341001: lib: remove safe_copy(); not 
used, generated compi...

On 03.01.2017 15:29, McLeod, John wrote:
> What about the std::string function c_str?  It returns a non-modifiable 
> pointer to the null terminated data in the string?

This function (std::string::c_str) provides a non-modifiable pointer and
the pointer is only valid as long as the string exists. So you can't use
the pointer outside of the context of the string. So the safe_copy()
function serves two purposes. It copies a string into a new char array
to make it modifiable and usable outside of the string context.

Another solution would be to only use strings and use c_str() locally
when it is needed and not pass around pointers to char arrays.

Regards
Christian

___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] [BOINC/boinc] 341001: lib: remove safe_copy(); not used, generated compi...

[McLeod, John]

What about the std::string function c_str?  It returns a non-modifiable pointer 
to the null terminated data in the string?

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Christian Beer
Sent: Tuesday, December 20, 2016 7:22 AM
To: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] [BOINC/boinc] 341001: lib: remove safe_copy(); not 
used, generated compi...

I don't care about the function. I'll just put it back in when I need it
again. What I'm more offended by is the reason that is stated in the
commit message. In my opinion that is not a valid reason to remove
contributed code without discussion or the chance for the contributor to
explain purpose or rectify errors.

- This function represents a nice way to convert std::string to char*
and may become handy in the future. I put it in BOINC because it is not
project-specific and may be something projects find helpful to be in the
BOINC library.
- Indicating implementation details in function names is not useful in
this context in my opinion. From the name alone I wouldn't think that I
need to free the memory myself. Such kind of post conditions are usually
expressed in a descriptive comment above the function. Usually in a
format that can be understood by a documentation tool like doxygen where
the post condition would then be part of the developer documentation
(the place where I would look for such post conditions).
- With a proper post condition that states "You are the owner of the
allocated memory of this function, clean this up after you used it" it
should be clear who the owner is.

Regards
Christian

On 19.12.2016 22:02, David Anderson wrote:
> I'll put it back if you feel that strongly.
> I removed it because:
> - it's not used anywhere (if needed for project-specific code, can
> define it there)
> - the name should be something like safe_copy_alloc() to indicate that
> it allocates memory
> - I try to avoid memory allocation in BOINC because pointer ownership
> is gnarly.
> .
> - David
>
> On 12/19/2016 5:18 AM, Christian Beer wrote:
>> Hi,
>>
>> am I the only one who has a problem with this commit?
>>
>> The BOINC Governance document states that actions of Committers are
>> reviewed after they committed something. Here we are. I want to complain
>> about this commit by a Committer of the BOJNC project.
>>
>> I added this function for a reason and yes it was intended to be used in
>> the server which means Linux only. So if it produces compile errors on
>> Windows we do have better options than removing it from the library. The
>> fact that it is currently not used in the BOINC code should not be the
>> sole reason to throw it away. hat if a project uses this function in
>> project specific daemons?
>>
>> Regards
>> Christian
>>
>> On 19.12.2016 10:17, GitHub wrote:
>>> Branch: refs/heads/master
>>>Home:   https://github.com/BOINC/boinc
>>>Commit: 3410015b00f13f53e8284e668b503b31c20814e4
>>>   
>>> https://github.com/BOINC/boinc/commit/3410015b00f13f53e8284e668b503b31c20814e4
>>>Author: David Anderson 
>>>Date:   2016-12-19 (Mon, 19 Dec 2016)
>>>
>>>Changed paths:
>>>  M lib/str_util.cpp
>>>  M lib/str_util.h
>>>
>>>Log Message:
>>>---
>>>lib: remove safe_copy(); not used, generated compile warnings on Win
>>
>> ___
>> boinc_dev mailing list
>> boinc_dev@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.
>
> ___
> boinc_dev mailing list
> boinc_dev@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.


___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] 4th Gen BOINC credit system

[McLeod, John]

There is a problem with credit inflation.  If we change the long term resource 
share to be based on granted credit, then the credit granted will tend to 
normalize.  There are a few open questions on exactly how to do this, but it 
should be possible.  

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of David 
Anderson
Sent: Tuesday, August 16, 2016 3:02 PM
To: Christian Beer ; Jason Groothuis 
; boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] 4th Gen BOINC credit system

The credit calculation is encapsulated in a single function, 
assign_credit_set().
You can change policy by changing or replacing this function.

Maintaining runtime statistics (the host_app_version table) is used for
job runtime estimation as well as the credit system.
It needs to stay even if you change credit.

-- David

On 8/16/2016 7:40 AM, Christian Beer wrote:
> I've tried to modularize the runtime estimation and credit calculation
> system (RECCS) in a local branch so we could more easily switch between
> implementations of different credit systems (on a per app level). But
> because CreditNew is very deeply involved in several key components I
> find it hard to establish an interface that is generic enough to
> decouple the RECCS system from the rest of BOINC.
>
> Such a modularization would also help in building a simulator that can
> use different strategies (credit/runtime systems) just as they are used
> in the scheduler.
>
> I've halted this for now because of lack of time but I would be willing
> to share what I have and write a Design document on how to modularize it
> further.
>
> Regards
> Christian
>
> On 15.08.2016 08:18, Jason Groothuis wrote:
>> I concur with these statements after having studied the mechanism from an 
>> engineering perspective over the last couple of years.  Steady state and new 
>> host/app were observed, on seti/seti-beta, along with fresh app launch on 
>> single appversion regimen with the kind help of Albert@home staff (before me 
>> running out of resources to take the study further).
>>
>>
>>   The fundamental design concepts weren't found to be problematic, though 
>> some of the implementation assumptions and choices were.  Outcomes were that 
>> the dominant instabilities were (engineering) control systems related, and 
>> that characterisation of the existing system (via matching such a simulation 
>> to real-world)  would aid communication of the problems and potential 
>> solutions.
>>
>>
>> What is a relatively simple engineering task of estimate localisation, is 
>> quickly conflated with passions when Credit is mentioned.  That quickly 
>> mires the genuinely solvable issues in Inertia.
>>
>>
>> So In my view, progress could be made by:
>>
>> - simulate the existing mechanism, under original CPU-FPUonly state, 
>> CPU-SIMD enabled state, GPU only state, and para-metrically mixed state
>>
>> - Use that (refined) simulation as reference comparison to real-world, and 
>> to formalise potential practical solutions.
>>
>> - Change the name from CreditNew to 'estimator'; or somesuch
>>
>>
>>
>>
>>
>>
>>
>> --
>> Jason Richard Groothuis
>> --
>>
>>
>> 
>> From: boinc_dev  on behalf of David 
>> Anderson 
>> Sent: 15 August 2016 08:14
>> To: boinc_dev@ssl.berkeley.edu
>> Subject: Re: [boinc_dev] 4th Gen BOINC credit system
>>
>> My thoughts:
>>
>> 1) The basic ideas behind the current credit system are sound,
>> but there seem to be some problems with the details,
>> in particular what happens when new app versions are added.
>>
>> 2) We need a simulator that models credit calculations for various scenarios
>> (synthetic, or based on trace data from a project).
>> Such a simulator would help identify the problems with the current system,
>> or would demonstrate that a new scheme works better.
>> I don't think we should consider a new system without simulator-based 
>> validation of it.
>>
>> -- David
>>
>>
>> On 8/14/2016 9:06 AM, CM wrote:
>>> Hey,
>>>
>>> A '4th gen BOINC credit system' thread was created over at the official 
>>> BOINC
>>> forums: https://boinc.berkeley.edu/dev/forum_thread.php?id=10953
>> [Discussion] 4th Generation BOINC credit 
>> system
>> boinc.berkeley.edu
>> I originally started a discussion over at cryptocointalk about this: 
>> https://cryptocointalk.com/topic/46130-discussion-3rd-generation-boinc-credit-system/
>>
>>
>>
>>> There's been about 77 posts to the thread, the general consensus was that a 
>>> new
>>> BOINC credit system is a good idea but thus far the definition/specs of 
>>> such a
>>> next gen 

Re: [boinc_dev] 4th Gen BOINC credit system

[McLeod, John]

A few notes.
1)  The resource share for what to run next needs to be responsive to what is 
happening on the local computer, and so would have to be based on resource 
usage.
2)  The long term resource share would have to be calculated well after the 
task is completed - after the credit is granted.  This will be anywhere from 
seconds to weeks after the work is done.
3)  How do we handle failed / late / invalid tasks?  Ones that have used 
resources, but are not going to generate credit?  Projects with a large % of 
failed / late / invalid tasks on this compute?

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Eric 
Korpela
Sent: Monday, August 15, 2016 2:37 PM
To: CM 
Cc: BOINC Developers Mailing List 
Subject: Re: [boinc_dev] 4th Gen BOINC credit system

There are a few major issues with the current credit system (credit_new).

The first is that nobody uses it.  Most projects (possibly all but SETI@home,
if what I'm told is correct) stayed with the old system.

The second is that there is still no consistency between projects, and that
wouldn't be fixed even if everyone used credit_new.

Which gets us to the third issue.  There is no longer any significant cross
project relationship between credit and work done.  The relationship was
tenuous a decade ago when SETI@home was the only project that actually
calculated how many FLOPs were being done, now it's nearly entirely gone.
The people who volunteer only to boost their RAC will happily migrate to
the project with the highest credit grants and the FLOPs shown at stats
sites are likely to have no relationship to reality.

There are ways that the system could be stabilized.  One way would be to
tie resource shares to RAC rather than wall time.  (I was involved in a
project with a 4% resource share.  It would typically supply 50% of my
total RAC, because its credit grants were in now way tied to actual work
done.)

If resource share was time to RAC, a project with 4% resourcre share would
create 4% of the RAC. If a project wanted to increase the number of
participant, it could increase the credit it offered, but that would reduce
the net resource share from people who participate in multiple projects.
Currently there is no penalty for increasing the credit offered.




On Sun, Aug 14, 2016 at 9:06 AM, CM  wrote:

> Hey,
>
> A '4th gen BOINC credit system' thread was created over at the official
> BOINC forums: https://boinc.berkeley.edu/dev/forum_thread.php?id=10953
>
> There's been about 77 posts to the thread, the general consensus was that
> a new BOINC credit system is a good idea but thus far the definition/specs
> of such a next gen system has not been agreed upon.
>
> What are the BOINC dev's thoughts on this topic? I'd love to continue this
> discussion & work towards a next-gen BOINC system.
>
> Cheers guys :)
>
> ___
> boinc_dev mailing list
> boinc_dev@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.
>



-- 
Eric Korpela
korp...@ssl.berkeley.edu
AST:7731^29u18e3
___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] providing BOINC through the Apple App Store

[McLeod, John]

For which subset of projects?  There are over 50.

Jm7

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Vitalii Koshura
Sent: Monday, May 23, 2016 4:17 AM
To: David Anderson 
Cc: BOINC Developers Mailing List ; 
pola...@comcast.net; boinc_proje...@ssl.berkeley.edu
Subject: Re: [boinc_dev] providing BOINC through the Apple App Store

Hello David,

I suggest to make a BOINC  application which will consist project binaries.
In this case only tasks would be downloaded. Of course if some project
application will be updated then BOINC application should also be updated
with the new project binaries. I understand that this way is very
complicated and very bad but I think that it is the only way to do this. I
do not believe that Apple guys will make an exception for BOINC project.

Thanks

Best Regards,
Vitalii Koshura

Sent via Android
23.05.2016 11:01 пользователь "David Anderson" 
написал:

> It would be great to have BOINC in the App Store.
> However, there are items in Apple's "Review Guidelines"
> that would seem to preclude BOINC:
>
> 2.15 Apps must be self-contained, single application installation bundles,
> and cannot install code or resources in shared locations
> 2.16 Apps that download or install additional code or resources to add
> functionality or change their primary purpose will be rejected
> 2.17 Apps that download other standalone Apps will be rejected
>
> See
> https://developer.apple.com/app-store/review/guidelines/mac/#functionality
>
> It's possible that Apple would relax these rules in our case.
> If anyone wants to initiate a dialog with them, please go ahead.
>
> -- David
>
> On 5/23/2016 12:46 AM, pola...@comcast.net wrote:
>
>> hello,
>> thank you for your wonderful software. I want to ask if it is possible to
>> provide this software through the Apple App store? The reason that I ask is
>> because OS X provides an option for security to download software only
>> through the App Store to prevent malware from being installed into the OS X
>> operating system. I have read that some opensource software has been
>> compromised by malware such as the Transmission bittorrent client. I
>> presume that Apple does some additional security checks before releasing
>> apps through the App Store. Are there copyright or patent issues or
>> financial reasons that prevent you from doing this? thanks for your time
>> and your efforts developing this software.
>> joe
>> The attachment to this e-mail as well as the content of the email itself
>> may be privileged, proprietary or confidential. Do not open it. It is
>> intended only for the e-mail recipient noted above. If you are not the
>> intended recipient or a person responsible for delivering this
>> transmission to the intended recipient, you may not disclose, copy or
>> distribute this transmission or take any action in reliance on it.
>>
>
> ___
> boinc_dev mailing list
> boinc_dev@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.
>
___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] automatic filename extension in windows wrapper

[McLeod, John]

For Windows, % is not a good choice.  Windows will try to interpret them as 
either System Variables %VarName% or batch file parameters %1.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Bernd 
Machenschalk
Sent: Friday, February 26, 2016 1:00 AM
To: Christian Beer ; BOINC Developers Mailing List 

Subject: Re: [boinc_dev] automatic filename extension in windows wrapper

Speaking about wrapper: would it hurt anyone if the "macros" (NTHREADS, 
GPU_DEVICE and in particular PROJECT_DIR) would be replaced in the 
complete command-line passed to the worker _after_ the arguments to the 
wrapper have been added ()? This way one could 
pass "resolved" file names to the "worker application". One possibly 
needs to circumvent the shell interpretation of '$', e.g. by using '%' 
('"%PROJECT_DIR") on the command-line.

Bernd

Christian Beer wrote on 25.02.16 21:09:
> Hi,
>
> we have a use case where we want to use the wrapper to deploy a legacy
> application. The application is bundled in a zip archive that is
> extracted by the wrapper into the slot directory. This application is
> called "LegacyApp" and "LegacyApp.exe" on Linux and Windows
> respectively. Now comes the problem. We want t include the job.xml file
> as part of the workunit not the appversion. This way we can only set one
> name "LegacyApp" which causes problems because for an unknown reason
> Windows 7 will not start a file without the .exe extension.
>
> I looked through the code and found a place
> (https://github.com/BOINC/boinc/blob/master/samples/wrapper/wrapper.cpp#L633)
> where we could add some more logic to detect such a case and add the
> ".exe" extension. Something like: if on windows and app_path does not
> exist try app_path+".exe"
>
> Another possibility would be to also add the .exe extension to the linux
> executable but who want's to do that? And remember it later when we
> wonder why we fixed a Windows Problem on Linux.
>
> Any thoughts on that?
>
> Regards
> Christian

___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] Fwd: Boinc doesn't work with the latest version of fire OS

[McLeod, John]

I did not think that Kindle fire was Android. I thou g t Fire was is own OS.

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-Original Message-
From: David Anderson [da...@ssl.berkeley.edu]
Received: Wednesday, 24 Feb 2016, 12:15AM
To: BOINC Developers Mailing List [boinc_dev@ssl.berkeley.edu]
Subject: [boinc_dev] Fwd: Boinc doesn't work with the latest version of fire OS

Our Android versions seem to be gradually failing.
Wouldn't someone like to learn Android development and fix things?
-- David


 Forwarded Message 
Subject: Boinc doesn't work with the latest version of fire OS
Date:Tue, 23 Feb 2016 21:53:40 -0500
From:Sander 
To:  da...@ssl.berkeley.edu 



Hi Dave

My kindle fire hdx tablet computer has been running boinc with no problem, but 
today it was upgraded to the latest version of fire OS. Now boinc no longer 
works, and it is not available in the amazon app store. Since I can only 
download apps from the amazon app store, I cannot run boinc.

Would it be possible to add boinc to the amazon app store? I have contacted 
amazon about this and they said that you need to add boinc to their app store.

Sanders Olson



___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] client in master is broken

[McLeod, John]

The _s functions do a better job of avoiding buffer overruns.  IIRC, they force 
the programmer to tell the function the size of the target buffer.  

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Richard Haselgrove
Sent: Tuesday, February 16, 2016 8:18 AM
To: Richard Haselgrove ; Rom Walton 
; boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] client in master is broken

And the resulting client failed with "A buffer overrun has occurred in 
boinc.exe which has corrupted the program's internal state. Press Break to 
debug the program or Continue to terminate the program."

Pressing Break dropped me into the source at 


>   boinc.exe!__raise_securityfailure(_EXCEPTION_POINTERS * 
> ExceptionPointers) Line 85  C 
boinc.exe!__report_gsfailure(unsigned __int64 StackCookie) Line 241 C 
boinc.exe!__GSHandlerCheck(_EXCEPTION_RECORD * ExceptionRecord, void * 
EstablisherFrame, _CONTEXT * ContextRecord, _DISPATCHER_CONTEXT * 
DispatcherContext) Line 91 C 
ntdll.dll!775b8bbd()Unknown 
ntdll.dll!775a875f()Unknown 
ntdll.dll!775dd348()Unknown 
msvcr120.dll!07fef313c3f9() Unknown 
()  Unknown 
0080()  Unknown 
boinc.exe!strlcat(char * dst, const char * src, unsigned __int64 size) Line 78  
C++ 
boinc.exe!get_processor_features(char * vendor, char * features, int 
features_size) Line 1198   C++ 
boinc.exe!get_processor_info(char * p_vendor, int p_vendor_size, char * 
p_model, int p_model_size, char * p_features, int p_features_size, double & 
p_cache, int & p_ncpus) Line 1305   C++ 


On Tuesday, 16 February 2016, 12:59, Richard Haselgrove 
 wrote:



Rom,

The fix you made last night solved the build problem in VS2013 - thanks.

But your overnight work on the 'low hanging fruit' has triggered a huge number 
of VS2013 warnings - 469 when building boinccmd, which includes the client 
build as part of the solution.

All seem to be C4996 - sample below. In each case, the 'consider using' 
suggestion seems to be to replace the function (several different functions are 
named) with function_s

e.g.

Warning 469 warning C4996: 'ctime': This function or variable may be unsafe. 
Consider using ctime_s instead. To disable deprecation, use 
_CRT_SECURE_NO_WARNINGS. See online help for details.

D:\Sources_build\boinc_head\lib\gui_rpc_client_print.cpp 238 1 boinccmd


On Monday, 15 February 2016, 20:29, Rom Walton  wrote:



Should be fixed now.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Richard Haselgrove
Sent: Monday, February 15, 2016 3:09 PM
To: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] client in master is broken

I also found that the Windows VS2013 solution failed to build the client from 
tags 7.6.24, 7.6.25, and head.
Managed to fix it by adding references to '..\lib\project_init.cpp' and 
'..\lib\project_init.h' to the  lists in both 
boinc_cli_vs2013.vcxproj and libboinc_staticcrt_vs2013.vcxproj

With that adjustment, head (debug) seems to be running. 

  

On Tuesday, 9 February 2016, 13:31, Oliver Bock  wrote:


On 09/02/16 14:10 , Rom Walton wrote:
> Should be fixed now.

Please, please, please. It's been about three years since we migrated to git. 
BOINC moved to GitHub just recently and tries to adopt a community governance 
model. It should really be possible by now that devs start using feature 
branches for development and save everyone else from periodic headaches. It's 
not hard by any means and it comes with huge incentives for everyone involved.

So please, use feature branches for development; merge to master when you're 
done with testing; don't break master; be happy; make everyone else happy...

THANKS!


___
boinc_dev mailing list
boinc_dev@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.


  
___
boinc_dev mailing list
boinc_dev@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.

___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu

Re: [boinc_dev] Excessive BOINC operating temperature

[McLeod, John]

When was the last time you chased the dust bunnies out of the computer?  

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of P. K. 
Carlisle
Sent: Sunday, October 25, 2015 11:55 PM
To: BOINC Devel List 
Subject: [boinc_dev] Excessive BOINC operating temperature

FYI --

Temporarily had to disable BOINC/@Home projects.

Running CentOS 6.7 64 bit, I noted that temperatures are *quite a bit*
higher than normal. Temps which ranged in the mid 70s C for the past ~2
years I have been running BOINC were in the 90s C for the past couple of
weeks.  Having time to tshoot a bit, I determined that the issue was
BOINC. Disabling ALL BOINC operations returns temperature to expected
levels.

I have BOINC usage levels set to medium range (having maxed BOINC once
before long ago and burned out a power supply, I am cognizant of this
setting). I changed no usage settings previous to this sudden
temperature increase.

After I determined that the issue was BOINC I went in and checked:. The
BOINC usage settings I have online at the @Home projects were where as I
had set them. I lowered them still more, but I know that the
--update-prefs flag takes some time to trickle through (a quick reboot
doesn't seem to really do it). I could disable one @Home project at a
time, wait for --update-prefs to really update and check them one at a
time (I may end up doing just that).

In 24 hours or so I will enable BOINC again and see if the new usage
level settings are recognized and result in lower operating temperature,
but for now a heads up: that without any user change in usage resource
percentage permissions, BOINC appears to be using more resources *to the
degree that the result is :significantly: higher system operating temps*.

Processor features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni
dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm xsave lahf_lm dts
tpr_shadow vnmi flexpriority Processor: 2 GenuineIntel Pentium(R)
Dual-Core CPU E6300 @ 2.80GHz [Family 6 Model 23 Stepping 10]

If anyone wants more system specs, let me know, I can provide, but my
schedule's a bit strange these days, so be patient if I take a day or
two to reply.
-- 

Web: www.pkcarlisle.com
Twitter: @pkcarlislellc
Voicemail: +12026815171
PGP: 0x35FC1FD4BF3CB150

--
___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] Fwd: New Defects reported by Coverity Scan for BOINC/boinc

[McLeod, John]

Coverity is a tool that uncovers security problems. You should investigate each 
one, and most of them will need a fix.

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-Original Message-
From: David Anderson [da...@ssl.berkeley.edu]
Received: Tuesday, 13 Oct 2015, 6:49PM
To: Rom Walton [rwal...@ssl.berkeley.edu]; Charlie Fenton 
[charl...@ssl.berkeley.edu]; BOINC Developers Mailing List 
[boinc_dev@ssl.berkeley.edu]
Subject: [boinc_dev] Fwd: New Defects reported by Coverity Scan for BOINC/boinc

FYI.  I'm not sure how to fix these, or if they matter.
-- David


 Forwarded Message 
Subject: New Defects reported by Coverity Scan for BOINC/boinc
Date:Tue, 13 Oct 2015 13:45:52 -0700
From:scan-ad...@coverity.com
To:  da...@ssl.berkeley.edu



Hi,

Please find the latest report on new defect(s) introduced to BOINC/boinc found 
with Coverity Scan.

13 new defect(s) introduced to BOINC/boinc found with Coverity Scan.
14 defect(s), reported by Coverity Scan earlier, were marked fixed in the 
recent build analyzed by Coverity Scan.

New defect(s) Reported-by: Coverity Scan
Showing 13 of 13 defect(s)


** CID 117641:  Uninitialized members  (UNINIT_CTOR)
/clientgui/DlgAdvPreferences.cpp: 105 in 
CDlgAdvPreferences::CDlgAdvPreferences(wxWindow *)()



*** CID 117641:  Uninitialized members  (UNINIT_CTOR)
/clientgui/DlgAdvPreferences.cpp: 105 in 
CDlgAdvPreferences::CDlgAdvPreferences(wxWindow *)()
99 SetSpecialTooltips();
100 //setting the validators for correct input handling
101 SetValidators();
102 //read in settings and initialize controls
103 ReadPreferenceSettings();
104
>>> CID 117641:  Uninitialized members  (UNINIT_CTOR)
>>> Non-static class member "lastErrorCtrl" is not initialized in this 
>>> constructor nor in any functions that it calls.
105 if (! m_bOKToShow) return;
106
107 // Get default preference values
108 defaultPrefs.enabled_defaults();
109 //
110 RestoreState();

** CID 117640:  Uninitialized members  (UNINIT_CTOR)
/clientgui/DlgEventLogListCtrl.cpp: 42 in 
MyEvtLogEvtHandler::MyEvtLogEvtHandler()()



*** CID 117640:  Uninitialized members  (UNINIT_CTOR)
/clientgui/DlgEventLogListCtrl.cpp: 42 in 
MyEvtLogEvtHandler::MyEvtLogEvtHandler()()
36 IMPLEMENT_DYNAMIC_CLASS(MyEvtLogEvtHandler, wxEvtHandler)
37
38 BEGIN_EVENT_TABLE(MyEvtLogEvtHandler, wxEvtHandler)
39 EVT_PAINT(MyEvtLogEvtHandler::OnPaint)
40 END_EVENT_TABLE()
41
>>> CID 117640:  Uninitialized members  (UNINIT_CTOR)
>>> Non-static class member "m_view_startX" is not initialized in this 
>>> constructor nor in any functions that it calls.
42 MyEvtLogEvtHandler::MyEvtLogEvtHandler() {}
43
44 MyEvtLogEvtHandler::MyEvtLogEvtHandler(wxGenericListCtrl 
*theListControl) {
45 m_listCtrl = theListControl;
46 m_view_startX = 0;
47 }

** CID 117639:  Uninitialized members  (UNINIT_CTOR)
/clientgui/DlgEventLogListCtrl.cpp: 97 in 
CDlgEventLogListCtrl::CDlgEventLogListCtrl(CDlgEventLog *, int, int)()



*** CID 117639:  Uninitialized members  (UNINIT_CTOR)
/clientgui/DlgEventLogListCtrl.cpp: 97 in 
CDlgEventLogListCtrl::CDlgEventLogListCtrl(CDlgEventLog *, int, int)()
91
92 #ifdef __WXMAC__
93 m_fauxHeaderView = NULL;
94 m_fauxBodyView = NULL;
95 SetupMacAccessibilitySupport();
96 #endif
>>> CID 117639:  Uninitialized members  (UNINIT_CTOR)
>>> Non-static class member "savedHandler" is not initialized in this 
>>> constructor nor in any functions that it calls.
97 }
98
99
100 #ifdef __WXMAC__
101 CDlgEventLogListCtrl::~CDlgEventLogListCtrl()
102 {

** CID 117638:  Uninitialized members  (UNINIT_CTOR)
/clientgui/sg_CustomControls.cpp: 142 in 
CTransparentHyperlinkCtrl::CTransparentHyperlinkCtrl()()



*** CID 117638:  Uninitialized members  (UNINIT_CTOR)
/clientgui/sg_CustomControls.cpp: 142 in 
CTransparentHyperlinkCtrl::CTransparentHyperlinkCtrl()()
136 BEGIN_EVENT_TABLE(CTransparentHyperlinkCtrl, wxHyperlinkCtrl)
137 EVT_ERASE_BACKGROUND(CTransparentHyperlinkCtrl::OnEraseBackground)
138 EVT_PAINT(CTransparentHyperlinkCtrl::OnPaint)
139 END_EVENT_TABLE()
140 #endif
141
>>> CID 117638:  Uninitialized members  (UNINIT_CTOR)
>>> Non-static class member "m_pParentsBgBmp" is not initialized in this 
>>> constructor nor in any functions that it calls.
142 CTransparentHyperlinkCtrl::CTransparentHyperlinkCtrl() {}
143
144 

Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

[McLeod, John]

Even using IPV6 addresses as identification of an individual machine is not a 
good idea.  The default for some OSs is to use privacy addresses that change 
every 15 minutes or so.  However, it is much more likely that the first 64 bits 
will identify a household as the current crop of Consumer firewalls only work 
with one /64.  

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Rom 
Walton
Sent: Monday, September 28, 2015 11:56 AM
To: Filip Rydlo 
Cc: BOINC-dev email list 
Subject: Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

One IP address can represent many machines if they are behind a NAT device.  
Now that North America has run out of IP addresses to be assigned, I expect 
carrier grade NATs will be used by more ISPs than in the past.

IP addresses as a means of identification is a bad idea.

- Rom

From: Filip Rydlo [mailto:filip.ry...@gmail.com]
Sent: Monday, September 28, 2015 3:49 AM
To: Rom Walton 
Cc: BOINC-dev email list 
Subject: Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

Yes, Rom.
   It really seems like a monster on the client side. This is neither 
easy nor  error-proof.

So, ... :
  Why not to save the unique "GUID" (generated by the server) + all 
this info  (with perfectly encrypted password)  in a dedicated (MySQL) DATABASE 
 on the main BOINC web-server? (it could be easily "cron"-ned to be cleaned 
from old entries and Vacuum-analyzed  every 4 hours or so)

It would be browser-independent.  IT would be easily implemented as 
temporary  and as valid only for the given I.P. address  - which is the same 
(during a short interval like 1 hour)  across all browsers on the PC / VM  , as 
far as I know.
Namaste
Filip



2015-09-28 2:44 GMT+02:00 Rom Walton 
>:
GUID would be more appropriate.

I foresee a few problems with this approach though:

1.   The ‘default’ browser wxWidgets detects may not be the browser the 
volunteer downloaded BOINC with.

2.   The manager would have to wait on the association to complete which 
means it has to know how to deal with whatever browser to launched.
(Basically the manager would have to know how each browser works. (window 
names, window class names, window titles, what events each window responds too))
(This is actually a more complicated problem than dealing with cookies.)

3.   We may never be able to find out if the association was successful 
from the manager perspective.

4.   Some browser plugins redirect errors and monkey with the error pages. 
(Norton 360, Google Toolbar, Yahoo Toolbar, etc.)

5.   There is a remote possibility that two machines can generate the same 
GUID, without being able to check against the master list ahead of time it 
could happen.

This solution might look okay from a server perspective, but it is a monster 
from a client implementation perspective.

- Rom


From: hugh.w...@gmail.com 
[mailto:hugh.w...@gmail.com] On Behalf Of Hugh 
Wormington
Sent: Sunday, September 27, 2015 5:22 PM
To: Rom Walton >
Cc: Matthew Blumberg >; 
Hugh Wormington >; Rytis 
Slatkevičius >; BOINC 
Developers Mailing List 
>
Subject: Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

> Where is the nonce generated?
By the installer.

> If it is generated by the installer and passed to the account manager, how to 
> we know who it came from?
The installer loads a browser on the url passing the "nonce" as a url 
parameter. The receiving page is then able to associate it with a logged-in 
user, after which the association is known.

A little side issue for avoidance of lexical confusion I'm a little unsure 
if this is really a "nonce" :

  *   Nonce: is an arbitrary number that may only be used once in secure 
communication exchange (See diagram on this wikipedia 
page) It doesn't carry any 
information itself.
  *   GUID: A globally unique identifier (GUID, /ˈɡuːɪd/) is a unique reference 
number used as an identifier in computer software. The term "GUID" typically 
refers to various implementations of the universally unique 
identifier (UUID) 
standard (Wikipedia)

I think we're talking about a GUID which the installer generates at install 
time and uses to identify itself to two different processes 1) the front end 
web application 2) the account manager server.
(A CPID 

Re: [boinc_dev] High priority status message removed.

[McLeod, John]

BOINC should be able to handle half to two day deadlines with no real problems. 
Dr. Anderson's goal at one point was to have the ability to respond to 
deadlines well under an hour.

In anycase, the deadlines being discussed are 2 day, not 1/2 day.

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-Original Message-
From: Eric J Korpela [korp...@ssl.berkeley.edu]
Received: Monday, 06 Oct 2014, 1:11PM
To: Richard Haselgrove [r.haselgr...@btopenworld.com]
CC: Charles Elliott [elliott...@comcast.net]; McLeod, John 
[john.mcl...@sap.com]; jacob_w_kl...@msn.com [jacob_w_kl...@msn.com]; 
boinc_dev@ssl.berkeley.edu [boinc_dev@ssl.berkeley.edu]
Subject: Re: [boinc_dev] High priority status message removed.

If a project really needs half day deadlines, the BOINC architecture may not be 
the right choice.  If it doesn't really need half day deadlines, it shouldn't 
have half day deadlines.

Not that the client scheduler isn't broken in a number of ways.

On Sat, Oct 4, 2014 at 5:48 AM, Richard Haselgrove 
r.haselgr...@btopenworld.commailto:r.haselgr...@btopenworld.com wrote:
Just observe. I'm currently running two SIMAP tasks which were issued with a 
two-day deadline (additional replications required for validation - they must 
be using

reliable_reduced_delay_boundX/reliable_reduced_delay_bound
When a need-reliable result is sent to a reliable host, multiply the delay 
bound by reliable_reduced_delay_bound (typically 0.5 or so).

Set a two day queue, and BOINC panics.

Don't judge every BOINC operation by the relaxed timings used at SETI.



 From: Charles Elliott elliott...@comcast.netmailto:elliott...@comcast.net
To: 'McLeod, John' john.mcl...@sap.commailto:john.mcl...@sap.com; 
jacob_w_kl...@msn.commailto:jacob_w_kl...@msn.com; 
r.haselgr...@btopenworld.commailto:r.haselgr...@btopenworld.com; 
boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
Sent: Saturday, October 4, 2014 1:37 PM
Subject: Re: [boinc_dev] High priority status message removed.


 You can still easily get into deadline trouble with either large queues,
or multiple projects and an occasional tight deadline



Proof?



From: McLeod, John [mailto:john.mcl...@sap.commailto:john.mcl...@sap.com]
Sent: Friday, October 3, 2014 10:54 PM
To: jacob_w_kl...@msn.commailto:jacob_w_kl...@msn.com; 
r.haselgr...@btopenworld.commailto:r.haselgr...@btopenworld.com;
boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu; 
elliott...@comcast.netmailto:elliott...@comcast.net
Subject: RE: [boinc_dev] High priority status message removed.



You can still easily get into deadline trouble with either large queues, or
multiple projects and an occasional tight deadline.

Sent from my Android phone using TouchDown 
(www.nitrodesk.comhttp://www.nitrodesk.com)

-Original Message-
From: Charles Elliott [elliott...@comcast.netmailto:elliott...@comcast.net]
Received: Friday, 03 Oct 2014, 10:10PM
To: 'Jacob Klein' [jacob_w_kl...@msn.commailto:jacob_w_kl...@msn.com]; 
'Richard Haselgrove'
[r.haselgr...@btopenworld.commailto:r.haselgr...@btopenworld.com]; McLeod, 
John [john.mcl...@sap.commailto:john.mcl...@sap.com];
boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu 
[boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu]
Subject: RE: [boinc_dev] High priority status message removed.

On my computer, which is allocated about 300 AP WUs at a time, in late
September Boinc was running AP WUs due in late October.  Then when October
1 came it seemingly panicked and stopped doing anything but processing AP
WUs
due October 17.  That behavior was useful when we could download thousands
of WUs, but I think it should be questioned now.

Charles Elliott

 -Original Message-
 From: boinc_dev 
 [mailto:boinc_dev-boun...@ssl.berkeley.edumailto:boinc_dev-boun...@ssl.berkeley.edu]
  On Behalf
 Of Jacob Klein
 Sent: Friday, October 3, 2014 9:24 AM
 To: Richard Haselgrove; McLeod, John; 
 boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
 Subject: Re: [boinc_dev] High priority status message removed.

 I'd like to see Prioritized to meet deadline in the UI, next to
 Running.

 
 From: Richard 
 Haselgrovemailto:r.haselgr...@btopenworld.commailto:r.haselgr...@btopenworld.com
 Sent: ‎10/‎3/‎2014 9:19 AM
 To: McLeod, Johnmailto:john.mcl...@sap.commailto:john.mcl...@sap.com;
 boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
mailto:boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu%3cmailto:boinc_dev@ssl.berkeley.edumailto:3cmailto%3aboinc_...@ssl.berkeley.edu
mailto:boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
 Subject: Re: [boinc_dev] High priority status message removed.

 The removal followed a question and answer session at the BOINC
 workshop in Budapest earlier this week. The OS scheduler mis-
 interpretation was one that I highlighted, but there was also a problem
 with users thinking that High Priority

Re: [boinc_dev] High priority status message removed.

[McLeod, John]

Still, a day or two should be workable for always connected machines.

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-Original Message-
From: Eric J Korpela [korp...@ssl.berkeley.edu]
Received: Monday, 06 Oct 2014, 1:56PM
To: McLeod, John [john.mcl...@sap.com]
CC: r.haselgr...@btopenworld.com [r.haselgr...@btopenworld.com]; 
elliott...@comcast.net [elliott...@comcast.net]; jacob_w_kl...@msn.com 
[jacob_w_kl...@msn.com]; boinc_dev@ssl.berkeley.edu [boinc_dev@ssl.berkeley.edu]
Subject: Re: [boinc_dev] High priority status message removed.



That may be the goal.  The client machines may have other plans.

On Mon, Oct 6, 2014 at 10:16 AM, McLeod, John 
john.mcl...@sap.commailto:john.mcl...@sap.com wrote:
BOINC should be able to handle half to two day deadlines with no real problems. 
Dr. Anderson's goal at one point was to have the ability to respond to 
deadlines well under an hour.

In anycase, the deadlines being discussed are 2 day, not 1/2 day.

Sent from my Android phone using TouchDown 
(www.nitrodesk.comhttp://www.nitrodesk.com)

-Original Message-
From: Eric J Korpela [korp...@ssl.berkeley.edumailto:korp...@ssl.berkeley.edu]
Received: Monday, 06 Oct 2014, 1:11PM
To: Richard Haselgrove 
[r.haselgr...@btopenworld.commailto:r.haselgr...@btopenworld.com]
CC: Charles Elliott [elliott...@comcast.netmailto:elliott...@comcast.net]; 
McLeod, John [john.mcl...@sap.commailto:john.mcl...@sap.com]; 
jacob_w_kl...@msn.commailto:jacob_w_kl...@msn.com 
[jacob_w_kl...@msn.commailto:jacob_w_kl...@msn.com]; 
boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu 
[boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu]
Subject: Re: [boinc_dev] High priority status message removed.

If a project really needs half day deadlines, the BOINC architecture may not be 
the right choice.  If it doesn't really need half day deadlines, it shouldn't 
have half day deadlines.

Not that the client scheduler isn't broken in a number of ways.

On Sat, Oct 4, 2014 at 5:48 AM, Richard Haselgrove 
r.haselgr...@btopenworld.commailto:r.haselgr...@btopenworld.com wrote:
Just observe. I'm currently running two SIMAP tasks which were issued with a 
two-day deadline (additional replications required for validation - they must 
be using

reliable_reduced_delay_boundX/reliable_reduced_delay_bound
When a need-reliable result is sent to a reliable host, multiply the delay 
bound by reliable_reduced_delay_bound (typically 0.5 or so).

Set a two day queue, and BOINC panics.

Don't judge every BOINC operation by the relaxed timings used at SETI.



 From: Charles Elliott elliott...@comcast.netmailto:elliott...@comcast.net
To: 'McLeod, John' john.mcl...@sap.commailto:john.mcl...@sap.com; 
jacob_w_kl...@msn.commailto:jacob_w_kl...@msn.com; 
r.haselgr...@btopenworld.commailto:r.haselgr...@btopenworld.com; 
boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
Sent: Saturday, October 4, 2014 1:37 PM
Subject: Re: [boinc_dev] High priority status message removed.


 You can still easily get into deadline trouble with either large queues,
or multiple projects and an occasional tight deadline



Proof?



From: McLeod, John [mailto:john.mcl...@sap.commailto:john.mcl...@sap.com]
Sent: Friday, October 3, 2014 10:54 PM
To: jacob_w_kl...@msn.commailto:jacob_w_kl...@msn.com; 
r.haselgr...@btopenworld.commailto:r.haselgr...@btopenworld.com;
boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu; 
elliott...@comcast.netmailto:elliott...@comcast.net
Subject: RE: [boinc_dev] High priority status message removed.



You can still easily get into deadline trouble with either large queues, or
multiple projects and an occasional tight deadline.

Sent from my Android phone using TouchDown 
(www.nitrodesk.comhttp://www.nitrodesk.com)

-Original Message-
From: Charles Elliott [elliott...@comcast.netmailto:elliott...@comcast.net]
Received: Friday, 03 Oct 2014, 10:10PM
To: 'Jacob Klein' [jacob_w_kl...@msn.commailto:jacob_w_kl...@msn.com]; 
'Richard Haselgrove'
[r.haselgr...@btopenworld.commailto:r.haselgr...@btopenworld.com]; McLeod, 
John [john.mcl...@sap.commailto:john.mcl...@sap.com];
boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu 
[boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu]
Subject: RE: [boinc_dev] High priority status message removed.

On my computer, which is allocated about 300 AP WUs at a time, in late
September Boinc was running AP WUs due in late October.  Then when October
1 came it seemingly panicked and stopped doing anything but processing AP
WUs
due October 17.  That behavior was useful when we could download thousands
of WUs, but I think it should be questioned now.

Charles Elliott

 -Original Message-
 From: boinc_dev 
 [mailto:boinc_dev-boun...@ssl.berkeley.edumailto:boinc_dev-boun...@ssl.berkeley.edu]
  On Behalf
 Of Jacob Klein
 Sent: Friday, October 3, 2014 9:24 AM
 To: Richard Haselgrove; McLeod, John; 
 boinc_dev

Re: [boinc_dev] High priority status message removed.

[McLeod, John]

However, there are projects that have deadlines that short.

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-Original Message-
From: Raistmer the Sorcerer [raist...@mail.ru]
Received: Monday, 06 Oct 2014, 3:10PM
To: McLeod, John [john.mcl...@sap.com]
CC: boinc_dev@ssl.berkeley.edu [boinc_dev@ssl.berkeley.edu]; 
r.haselgr...@btopenworld.com [r.haselgr...@btopenworld.com]; 
korp...@ssl.berkeley.edu [korp...@ssl.berkeley.edu]
Subject: Re[2]: [boinc_dev] High priority status message removed.

If user wouldn't participate in his favorite game tournament exactly in that 
weekend leaving BOINC stopped or in exclusive application run mode.
One should not forget, BOINC is not the main app on average participant's 
host ;) day or two deadline for BOINC architecture is too short, by 
definition of piggyback computations.


Mon, 6 Oct 2014 18:16:16 + от McLeod, John john.mcl...@sap.com:
Still, a day or two should be workable for always connected machines.

Sent from my Android phone using TouchDown 
(www.nitrodesk.comhttp://www.nitrodesk.com)

-Original Message-
From: Eric J Korpela [korp...@ssl.berkeley.edu]
Received: Monday, 06 Oct 2014, 1:56PM
To: McLeod, John [john.mcl...@sap.com]
CC: r.haselgr...@btopenworld.com/compose?To=r.haselgr...@btopenworld.com 
[r.haselgr...@btopenworld.com]; 
elliott...@comcast.net/compose?To=elliott...@comcast.net 
[elliott...@comcast.net]; 
jacob_w_kl...@msn.com/compose?To=jacob_w_kl...@msn.com 
[jacob_w_kl...@msn.com]; 
boinc_dev@ssl.berkeley.edu/compose?To=boinc_dev@ssl.berkeley.edu 
[boinc_dev@ssl.berkeley.edu]
Subject: Re: [boinc_dev] High priority status message removed.



That may be the goal. The client machines may have other plans.

On Mon, Oct 6, 2014 at 10:16 AM, McLeod, John 
john.mcl...@sap.commailto:john.mcl...@sap.com/compose?To=john.mcl...@sap.com
 wrote:
BOINC should be able to handle half to two day deadlines with no real problems. 
Dr. Anderson's goal at one point was to have the ability to respond to 
deadlines well under an hour.

In anycase, the deadlines being discussed are 2 day, not 1/2 day.

Sent from my Android phone using TouchDown 
(www.nitrodesk.comhttp://www.nitrodesk.comhttp://www.nitrodesk.com)

-Original Message-
From: Eric J Korpela 
[korp...@ssl.berkeley.edumailto:korp...@ssl.berkeley.edu/compose?To=korp...@ssl.berkeley.edu]
Received: Monday, 06 Oct 2014, 1:11PM
To: Richard Haselgrove 
[r.haselgr...@btopenworld.commailto:r.haselgr...@btopenworld.com/compose?To=r.haselgr...@btopenworld.com]
CC: Charles Elliott 
[elliott...@comcast.netmailto:elliott...@comcast.net/compose?To=elliott...@comcast.net];
 McLeod, John 
[john.mcl...@sap.commailto:john.mcl...@sap.com/compose?To=john.mcl...@sap.com];
 
jacob_w_kl...@msn.commailto:jacob_w_kl...@msn.com/compose?To=jacob_w_kl...@msn.com
 
[jacob_w_kl...@msn.commailto:jacob_w_kl...@msn.com/compose?To=jacob_w_kl...@msn.com];
 
boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu/compose?To=boinc_dev@ssl.berkeley.edu
 
[boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu/compose?To=boinc_dev@ssl.berkeley.edu]
Subject: Re: [boinc_dev] High priority status message removed.

If a project really needs half day deadlines, the BOINC architecture may not be 
the right choice. If it doesn't really need half day deadlines, it shouldn't 
have half day deadlines.

Not that the client scheduler isn't broken in a number of ways.

On Sat, Oct 4, 2014 at 5:48 AM, Richard Haselgrove 
r.haselgr...@btopenworld.commailto:r.haselgr...@btopenworld.com/compose?To=r.haselgr...@btopenworld.com
 wrote:
Just observe. I'm currently running two SIMAP tasks which were issued with a 
two-day deadline (additional replications required for validation - they must 
be using

reliable_reduced_delay_boundX/reliable_reduced_delay_bound
When a need-reliable result is sent to a reliable host, multiply the delay 
bound by reliable_reduced_delay_bound (typically 0.5 or so).

Set a two day queue, and BOINC panics.

Don't judge every BOINC operation by the relaxed timings used at SETI.



 From: Charles Elliott 
 elliott...@comcast.netmailto:elliott...@comcast.net/compose?To=elliott...@comcast.net
To: 'McLeod, John' 
john.mcl...@sap.commailto:john.mcl...@sap.com/compose?To=john.mcl...@sap.com;
 
jacob_w_kl...@msn.commailto:jacob_w_kl...@msn.com/compose?To=jacob_w_kl...@msn.com;
 
r.haselgr...@btopenworld.commailto:r.haselgr...@btopenworld.com/compose?To=r.haselgr...@btopenworld.com;
 
boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu/compose?To=boinc_dev@ssl.berkeley.edu
Sent: Saturday, October 4, 2014 1:37 PM
Subject: Re: [boinc_dev] High priority status message removed.


 You can still easily get into deadline trouble with either large queues,
or multiple projects and an occasional tight deadline



Proof?



From: McLeod, John 
[mailto:john.mcl...@sap.commailto:john.mcl...@sap.com/compose?To=john.mcl...@sap.com]
Sent: Friday, October 3, 2014 10:54 PM

Re: [boinc_dev] High priority status message removed.

[McLeod, John]

That is one I had forgotten about. BOINC is probably correct in running these 
in EDF as there is likely to be a bit more than 2 days of work on that machine, 
and if they waited their turn, they would be returned late.

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-Original Message-
From: Richard Haselgrove [r.haselgr...@btopenworld.com]
Received: Saturday, 04 Oct 2014, 8:49AM
To: Charles Elliott [elliott...@comcast.net]; McLeod, John 
[john.mcl...@sap.com]; jacob_w_kl...@msn.com [jacob_w_kl...@msn.com]; 
boinc_dev@ssl.berkeley.edu [boinc_dev@ssl.berkeley.edu]
Subject: Re: [boinc_dev] High priority status message removed.

Just observe. I'm currently running two SIMAP tasks which were issued with a 
two-day deadline (additional replications required for validation - they must 
be using

reliable_reduced_delay_boundX/reliable_reduced_delay_bound
When a need-reliable result is sent to a reliable host, multiply the delay 
bound by reliable_reduced_delay_bound (typically 0.5 or so).

Set a two day queue, and BOINC panics.

Don't judge every BOINC operation by the relaxed timings used at SETI.

From: Charles Elliott elliott...@comcast.net
To: 'McLeod, John' john.mcl...@sap.com; jacob_w_kl...@msn.com; 
r.haselgr...@btopenworld.com; boinc_dev@ssl.berkeley.edu
Sent: Saturday, October 4, 2014 1:37 PM
Subject: Re: [boinc_dev] High priority status message removed.

 You can still easily get into deadline trouble with either large queues,
or multiple projects and an occasional tight deadline



Proof?



From: McLeod, John [mailto:john.mcl...@sap.commailto:john.mcl...@sap.com]
Sent: Friday, October 3, 2014 10:54 PM
To: jacob_w_kl...@msn.commailto:jacob_w_kl...@msn.com; 
r.haselgr...@btopenworld.commailto:r.haselgr...@btopenworld.com;
boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu; 
elliott...@comcast.netmailto:elliott...@comcast.net
Subject: RE: [boinc_dev] High priority status message removed.



You can still easily get into deadline trouble with either large queues, or
multiple projects and an occasional tight deadline.

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-Original Message-
From: Charles Elliott [elliott...@comcast.netmailto:elliott...@comcast.net]
Received: Friday, 03 Oct 2014, 10:10PM
To: 'Jacob Klein' [jacob_w_kl...@msn.commailto:jacob_w_kl...@msn.com]; 
'Richard Haselgrove'
[r.haselgr...@btopenworld.commailto:r.haselgr...@btopenworld.com]; McLeod, 
John [john.mcl...@sap.commailto:john.mcl...@sap.com];
boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu 
[boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu]
Subject: RE: [boinc_dev] High priority status message removed.

On my computer, which is allocated about 300 AP WUs at a time, in late
September Boinc was running AP WUs due in late October.  Then when October
1 came it seemingly panicked and stopped doing anything but processing AP
WUs
due October 17.  That behavior was useful when we could download thousands
of WUs, but I think it should be questioned now.

Charles Elliott

 -Original Message-
 From: boinc_dev 
 [mailto:boinc_dev-boun...@ssl.berkeley.edumailto:boinc_dev-boun...@ssl.berkeley.edu]
  On Behalf
 Of Jacob Klein
 Sent: Friday, October 3, 2014 9:24 AM
 To: Richard Haselgrove; McLeod, John; 
 boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
 Subject: Re: [boinc_dev] High priority status message removed.

 I'd like to see Prioritized to meet deadline in the UI, next to
 Running.

 
 From: Richard 
 Haselgrovemailto:r.haselgr...@btopenworld.commailto:r.haselgr...@btopenworld.com
 Sent: ‎10/‎3/‎2014 9:19 AM
 To: McLeod, Johnmailto:john.mcl...@sap.commailto:john.mcl...@sap.com;
 boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
mailto:boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu%3cmailto:boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
mailto:boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
 Subject: Re: [boinc_dev] High priority status message removed.

 The removal followed a question and answer session at the BOINC
 workshop in Budapest earlier this week. The OS scheduler mis-
 interpretation was one that I highlighted, but there was also a problem
 with users thinking that High Priority was a project-chosen queue-
 jumping facility. I think we're much better off without those
 confusions over terminology, but I agree with John that it would be
 good if the reason for non-FIFO running could be marked in some way -
 if we can find a less-frightening word.



 
  From: McLeod, John john.mcl...@sap.commailto:john.mcl...@sap.com
 To: boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu 
 boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
 Sent: Friday, October 3, 2014 2:01 PM
 Subject: [boinc_dev] High priority status message removed.
 
 
 OK, High Priority made it sound like

Re: [boinc_dev] High priority status message removed.

[McLeod, John]

Panic is a word that we really do not want to use. When you panic, you stop 
thinking...

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-Original Message-
From: Erik Veit [zombi...@mac.com]
Received: Saturday, 04 Oct 2014, 10:26AM
To: boinc_dev@ssl.berkeley.edu [boinc_dev@ssl.berkeley.edu]
Subject: Re: [boinc_dev] High priority status message removed.

 Set a two day queue, and BOINC panics.

Use the words that the users are already using.

“Panic Mode”.  It’s concise, easily understandable, no confusion with system 
priority, and is the term BOINC users have been using for years to describe it 
on all the forums.




 On Oct 4, 2014, at 5:48 AM, Richard Haselgrove r.haselgr...@btopenworld.com 
 wrote:

 Just observe. I'm currently running two SIMAP tasks which were issued with a 
 two-day deadline (additional replications required for validation - they must 
 be using

 reliable_reduced_delay_boundX/reliable_reduced_delay_bound
 When a need-reliable result is sent to a reliable host, multiply the delay 
 bound by reliable_reduced_delay_bound (typically 0.5 or so).

 Set a two day queue, and BOINC panics.

 Don't judge every BOINC operation by the relaxed timings used at SETI.


 
 From: Charles Elliott elliott...@comcast.net
 To: 'McLeod, John' john.mcl...@sap.com; jacob_w_kl...@msn.com; 
 r.haselgr...@btopenworld.com; boinc_dev@ssl.berkeley.edu
 Sent: Saturday, October 4, 2014 1:37 PM
 Subject: Re: [boinc_dev] High priority status message removed.


 You can still easily get into deadline trouble with either large queues,
 or multiple projects and an occasional tight deadline



 Proof?



 From: McLeod, John [mailto:john.mcl...@sap.com]
 Sent: Friday, October 3, 2014 10:54 PM
 To: jacob_w_kl...@msn.com; r.haselgr...@btopenworld.com;
 boinc_dev@ssl.berkeley.edu; elliott...@comcast.net
 Subject: RE: [boinc_dev] High priority status message removed.



 You can still easily get into deadline trouble with either large queues, or
 multiple projects and an occasional tight deadline.

 Sent from my Android phone using TouchDown 
 (www.nitrodesk.comhttp://www.nitrodesk.com)

 -Original Message-
 From: Charles Elliott [elliott...@comcast.net]
 Received: Friday, 03 Oct 2014, 10:10PM
 To: 'Jacob Klein' [jacob_w_kl...@msn.com]; 'Richard Haselgrove'
 [r.haselgr...@btopenworld.com]; McLeod, John [john.mcl...@sap.com];
 boinc_dev@ssl.berkeley.edu [boinc_dev@ssl.berkeley.edu]
 Subject: RE: [boinc_dev] High priority status message removed.

 On my computer, which is allocated about 300 AP WUs at a time, in late
 September Boinc was running AP WUs due in late October.  Then when October
 1 came it seemingly panicked and stopped doing anything but processing AP
 WUs
 due October 17.  That behavior was useful when we could download thousands
 of WUs, but I think it should be questioned now.

 Charles Elliott

 -Original Message-
 From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf
 Of Jacob Klein
 Sent: Friday, October 3, 2014 9:24 AM
 To: Richard Haselgrove; McLeod, John; boinc_dev@ssl.berkeley.edu
 Subject: Re: [boinc_dev] High priority status message removed.

 I'd like to see Prioritized to meet deadline in the UI, next to
 Running.

 
 From: Richard Haselgrovemailto:r.haselgr...@btopenworld.com
 Sent: ‎10/‎3/‎2014 9:19 AM
 To: McLeod, Johnmailto:john.mcl...@sap.com;
 boinc_dev@ssl.berkeley.edu
 mailto:boinc_dev@ssl.berkeley.edu%3cmailto:boinc_dev@ssl.berkeley.edu
 mailto:boinc_dev@ssl.berkeley.edu
 Subject: Re: [boinc_dev] High priority status message removed.

 The removal followed a question and answer session at the BOINC
 workshop in Budapest earlier this week. The OS scheduler mis-
 interpretation was one that I highlighted, but there was also a problem
 with users thinking that High Priority was a project-chosen queue-
 jumping facility. I think we're much better off without those
 confusions over terminology, but I agree with John that it would be
 good if the reason for non-FIFO running could be marked in some way -
 if we can find a less-frightening word.



 
 From: McLeod, John john.mcl...@sap.com
 To: boinc_dev@ssl.berkeley.edu boinc_dev@ssl.berkeley.edu
 Sent: Friday, October 3, 2014 2:01 PM
 Subject: [boinc_dev] High priority status message removed.


 OK, High Priority made it sound like it was running at High OS
 Scheduler Priority, but some tag that it is not in the normal RR
 schedule might be good for helping diagnose problems.
 ___
 boinc_dev mailing list
 boinc_dev@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.



 ___
 boinc_dev mailing list
 boinc_dev@ssl.berkeley.edu
 http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev

Re: [boinc_dev] High priority status message removed.

[McLeod, John]

The debug messages tend to be a bit cryptoc, and most users never turn them on.

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-Original Message-
From: David Anderson [da...@ssl.berkeley.edu]
Received: Saturday, 04 Oct 2014, 11:02AM
To: Jacob Klein [jacob_w_kl...@msn.com]; McLeod, John [john.mcl...@sap.com]; 
elliott...@comcast.net [elliott...@comcast.net]; BOINC Development 
[boinc_dev@ssl.berkeley.edu]; Richard Haselgrove [r.haselgr...@btopenworld.com]
Subject: Re: [boinc_dev] High priority status message removed.

There are actually 2 exceptions to round-robin:
- jobs that would miss their deadline in round-robin
- jobs that haven't checkpointed

The question is whether we should show this info in the GUI.
My inclination is to show it in the event log rather than the GUI.
However we express it in the GUI, it's going to confuse most users.

Actually it's already in the event log, conditioned on cpu_sched_debug
(MD = missed deadline, UTS = unfinished time slice).
I need to improve the clarity of the messages.

-- David
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] High priority status message removed.

[McLeod, John]

Also remember that missed deadlines may mean that the work does not count.

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-Original Message-
From: Erik Veit [zombi...@mac.com]
Received: Saturday, 04 Oct 2014, 11:38AM
To: McLeod, John [john.mcl...@sap.com]
CC: boinc_dev@ssl.berkeley.edu [boinc_dev@ssl.berkeley.edu]
Subject: Re: [boinc_dev] High priority status message removed.

But that’s exactly what BOINC *is* doing.  It’s stopped thinking, and is no 
longer considering all the normal scheduling rules.  It’s scheduling on pure 
fear (panic) of a missed deadline.


 On Oct 4, 2014, at 8:04 AM, McLeod, John john.mcl...@sap.com wrote:

 Panic is a word that we really do not want to use. When you panic, you stop 
 thinking...

 Sent from my Android phone using TouchDown 
 (www.nitrodesk.comhttp://www.nitrodesk.com)

 -Original Message-
 From: Erik Veit [zombi...@mac.com]
 Received: Saturday, 04 Oct 2014, 10:26AM
 To: boinc_dev@ssl.berkeley.edu [boinc_dev@ssl.berkeley.edu]
 Subject: Re: [boinc_dev] High priority status message removed.

 Set a two day queue, and BOINC panics.

 Use the words that the users are already using.

 “Panic Mode”.  It’s concise, easily understandable, no confusion with system 
 priority, and is the term BOINC users have been using for years to describe 
 it on all the forums.




 On Oct 4, 2014, at 5:48 AM, Richard Haselgrove 
 r.haselgr...@btopenworld.com wrote:

 Just observe. I'm currently running two SIMAP tasks which were issued with a 
 two-day deadline (additional replications required for validation - they 
 must be using

 reliable_reduced_delay_boundX/reliable_reduced_delay_bound
 When a need-reliable result is sent to a reliable host, multiply the delay 
 bound by reliable_reduced_delay_bound (typically 0.5 or so).

 Set a two day queue, and BOINC panics.

 Don't judge every BOINC operation by the relaxed timings used at SETI.


 
 From: Charles Elliott elliott...@comcast.net
 To: 'McLeod, John' john.mcl...@sap.com; jacob_w_kl...@msn.com; 
 r.haselgr...@btopenworld.com; boinc_dev@ssl.berkeley.edu
 Sent: Saturday, October 4, 2014 1:37 PM
 Subject: Re: [boinc_dev] High priority status message removed.


 You can still easily get into deadline trouble with either large queues,
 or multiple projects and an occasional tight deadline



 Proof?



 From: McLeod, John [mailto:john.mcl...@sap.com]
 Sent: Friday, October 3, 2014 10:54 PM
 To: jacob_w_kl...@msn.com; r.haselgr...@btopenworld.com;
 boinc_dev@ssl.berkeley.edu; elliott...@comcast.net
 Subject: RE: [boinc_dev] High priority status message removed.



 You can still easily get into deadline trouble with either large queues, or
 multiple projects and an occasional tight deadline.

 Sent from my Android phone using TouchDown 
 (www.nitrodesk.comhttp://www.nitrodesk.comhttp://www.nitrodesk.comhttp://www.nitrodesk.com)

 -Original Message-
 From: Charles Elliott [elliott...@comcast.net]
 Received: Friday, 03 Oct 2014, 10:10PM
 To: 'Jacob Klein' [jacob_w_kl...@msn.com]; 'Richard Haselgrove'
 [r.haselgr...@btopenworld.com]; McLeod, John [john.mcl...@sap.com];
 boinc_dev@ssl.berkeley.edu [boinc_dev@ssl.berkeley.edu]
 Subject: RE: [boinc_dev] High priority status message removed.

 On my computer, which is allocated about 300 AP WUs at a time, in late
 September Boinc was running AP WUs due in late October.  Then when October
 1 came it seemingly panicked and stopped doing anything but processing AP
 WUs
 due October 17.  That behavior was useful when we could download thousands
 of WUs, but I think it should be questioned now.

 Charles Elliott

 -Original Message-
 From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf
 Of Jacob Klein
 Sent: Friday, October 3, 2014 9:24 AM
 To: Richard Haselgrove; McLeod, John; boinc_dev@ssl.berkeley.edu
 Subject: Re: [boinc_dev] High priority status message removed.

 I'd like to see Prioritized to meet deadline in the UI, next to
 Running.

 
 From: Richard Haselgrovemailto:r.haselgr...@btopenworld.com
 Sent: ‎10/‎3/‎2014 9:19 AM
 To: McLeod, Johnmailto:john.mcl...@sap.com;
 boinc_dev@ssl.berkeley.edu
 mailto:boinc_dev@ssl.berkeley.edu%3cmailto:boinc_dev@ssl.berkeley.edu
 mailto:boinc_dev@ssl.berkeley.edu
 Subject: Re: [boinc_dev] High priority status message removed.

 The removal followed a question and answer session at the BOINC
 workshop in Budapest earlier this week. The OS scheduler mis-
 interpretation was one that I highlighted, but there was also a problem
 with users thinking that High Priority was a project-chosen queue-
 jumping facility. I think we're much better off without those
 confusions over terminology, but I agree with John that it would be
 good if the reason for non-FIFO running could be marked in some way -
 if we can find a less-frightening word.



 
 From: McLeod, John john.mcl...@sap.com
 To: boinc_dev

Re: [boinc_dev] High priority status message removed.

[McLeod, John]

No. After conidrrstion, BOINC has decided that particles task needs to get some 
extra time now to avoid missing a deadline later.

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-Original Message-
From: Erik Veit [zombi...@mac.com]
Received: Saturday, 04 Oct 2014, 11:38AM
To: McLeod, John [john.mcl...@sap.com]
CC: boinc_dev@ssl.berkeley.edu [boinc_dev@ssl.berkeley.edu]
Subject: Re: [boinc_dev] High priority status message removed.

But that’s exactly what BOINC *is* doing.  It’s stopped thinking, and is no 
longer considering all the normal scheduling rules.  It’s scheduling on pure 
fear (panic) of a missed deadline.


 On Oct 4, 2014, at 8:04 AM, McLeod, John john.mcl...@sap.com wrote:

 Panic is a word that we really do not want to use. When you panic, you stop 
 thinking...

 Sent from my Android phone using TouchDown 
 (www.nitrodesk.comhttp://www.nitrodesk.com)

 -Original Message-
 From: Erik Veit [zombi...@mac.com]
 Received: Saturday, 04 Oct 2014, 10:26AM
 To: boinc_dev@ssl.berkeley.edu [boinc_dev@ssl.berkeley.edu]
 Subject: Re: [boinc_dev] High priority status message removed.

 Set a two day queue, and BOINC panics.

 Use the words that the users are already using.

 “Panic Mode”.  It’s concise, easily understandable, no confusion with system 
 priority, and is the term BOINC users have been using for years to describe 
 it on all the forums.




 On Oct 4, 2014, at 5:48 AM, Richard Haselgrove 
 r.haselgr...@btopenworld.com wrote:

 Just observe. I'm currently running two SIMAP tasks which were issued with a 
 two-day deadline (additional replications required for validation - they 
 must be using

 reliable_reduced_delay_boundX/reliable_reduced_delay_bound
 When a need-reliable result is sent to a reliable host, multiply the delay 
 bound by reliable_reduced_delay_bound (typically 0.5 or so).

 Set a two day queue, and BOINC panics.

 Don't judge every BOINC operation by the relaxed timings used at SETI.


 
 From: Charles Elliott elliott...@comcast.net
 To: 'McLeod, John' john.mcl...@sap.com; jacob_w_kl...@msn.com; 
 r.haselgr...@btopenworld.com; boinc_dev@ssl.berkeley.edu
 Sent: Saturday, October 4, 2014 1:37 PM
 Subject: Re: [boinc_dev] High priority status message removed.


 You can still easily get into deadline trouble with either large queues,
 or multiple projects and an occasional tight deadline



 Proof?



 From: McLeod, John [mailto:john.mcl...@sap.com]
 Sent: Friday, October 3, 2014 10:54 PM
 To: jacob_w_kl...@msn.com; r.haselgr...@btopenworld.com;
 boinc_dev@ssl.berkeley.edu; elliott...@comcast.net
 Subject: RE: [boinc_dev] High priority status message removed.



 You can still easily get into deadline trouble with either large queues, or
 multiple projects and an occasional tight deadline.

 Sent from my Android phone using TouchDown 
 (www.nitrodesk.comhttp://www.nitrodesk.comhttp://www.nitrodesk.comhttp://www.nitrodesk.com)

 -Original Message-
 From: Charles Elliott [elliott...@comcast.net]
 Received: Friday, 03 Oct 2014, 10:10PM
 To: 'Jacob Klein' [jacob_w_kl...@msn.com]; 'Richard Haselgrove'
 [r.haselgr...@btopenworld.com]; McLeod, John [john.mcl...@sap.com];
 boinc_dev@ssl.berkeley.edu [boinc_dev@ssl.berkeley.edu]
 Subject: RE: [boinc_dev] High priority status message removed.

 On my computer, which is allocated about 300 AP WUs at a time, in late
 September Boinc was running AP WUs due in late October.  Then when October
 1 came it seemingly panicked and stopped doing anything but processing AP
 WUs
 due October 17.  That behavior was useful when we could download thousands
 of WUs, but I think it should be questioned now.

 Charles Elliott

 -Original Message-
 From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf
 Of Jacob Klein
 Sent: Friday, October 3, 2014 9:24 AM
 To: Richard Haselgrove; McLeod, John; boinc_dev@ssl.berkeley.edu
 Subject: Re: [boinc_dev] High priority status message removed.

 I'd like to see Prioritized to meet deadline in the UI, next to
 Running.

 
 From: Richard Haselgrovemailto:r.haselgr...@btopenworld.com
 Sent: ‎10/‎3/‎2014 9:19 AM
 To: McLeod, Johnmailto:john.mcl...@sap.com;
 boinc_dev@ssl.berkeley.edu
 mailto:boinc_dev@ssl.berkeley.edu%3cmailto:boinc_dev@ssl.berkeley.edu
 mailto:boinc_dev@ssl.berkeley.edu
 Subject: Re: [boinc_dev] High priority status message removed.

 The removal followed a question and answer session at the BOINC
 workshop in Budapest earlier this week. The OS scheduler mis-
 interpretation was one that I highlighted, but there was also a problem
 with users thinking that High Priority was a project-chosen queue-
 jumping facility. I think we're much better off without those
 confusions over terminology, but I agree with John that it would be
 good if the reason for non-FIFO running could be marked in some way -
 if we can find a less-frightening word

Re: [boinc_dev] High priority status message removed.

[McLeod, John]

BOINC may be running tasks out of round robin order, but it is not panicking. 
Panic has the connotation of inconsidered fright. That is not what BOINC is 
doing. BOINC is considering the situa t ion and making a decision based on the 
best available knowledge. This is not panicking.

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-Original Message-
From: Erik Veit [zombi...@mac.com]
Received: Saturday, 04 Oct 2014, 11:38AM
To: McLeod, John [john.mcl...@sap.com]
CC: boinc_dev@ssl.berkeley.edu [boinc_dev@ssl.berkeley.edu]
Subject: Re: [boinc_dev] High priority status message removed.

But that’s exactly what BOINC *is* doing.  It’s stopped thinking, and is no 
longer considering all the normal scheduling rules.  It’s scheduling on pure 
fear (panic) of a missed deadline.


 On Oct 4, 2014, at 8:04 AM, McLeod, John john.mcl...@sap.com wrote:

 Panic is a word that we really do not want to use. When you panic, you stop 
 thinking...

 Sent from my Android phone using TouchDown 
 (www.nitrodesk.comhttp://www.nitrodesk.com)

 -Original Message-
 From: Erik Veit [zombi...@mac.com]
 Received: Saturday, 04 Oct 2014, 10:26AM
 To: boinc_dev@ssl.berkeley.edu [boinc_dev@ssl.berkeley.edu]
 Subject: Re: [boinc_dev] High priority status message removed.

 Set a two day queue, and BOINC panics.

 Use the words that the users are already using.

 “Panic Mode”.  It’s concise, easily understandable, no confusion with system 
 priority, and is the term BOINC users have been using for years to describe 
 it on all the forums.




 On Oct 4, 2014, at 5:48 AM, Richard Haselgrove 
 r.haselgr...@btopenworld.com wrote:

 Just observe. I'm currently running two SIMAP tasks which were issued with a 
 two-day deadline (additional replications required for validation - they 
 must be using

 reliable_reduced_delay_boundX/reliable_reduced_delay_bound
 When a need-reliable result is sent to a reliable host, multiply the delay 
 bound by reliable_reduced_delay_bound (typically 0.5 or so).

 Set a two day queue, and BOINC panics.

 Don't judge every BOINC operation by the relaxed timings used at SETI.


 
 From: Charles Elliott elliott...@comcast.net
 To: 'McLeod, John' john.mcl...@sap.com; jacob_w_kl...@msn.com; 
 r.haselgr...@btopenworld.com; boinc_dev@ssl.berkeley.edu
 Sent: Saturday, October 4, 2014 1:37 PM
 Subject: Re: [boinc_dev] High priority status message removed.


 You can still easily get into deadline trouble with either large queues,
 or multiple projects and an occasional tight deadline



 Proof?



 From: McLeod, John [mailto:john.mcl...@sap.com]
 Sent: Friday, October 3, 2014 10:54 PM
 To: jacob_w_kl...@msn.com; r.haselgr...@btopenworld.com;
 boinc_dev@ssl.berkeley.edu; elliott...@comcast.net
 Subject: RE: [boinc_dev] High priority status message removed.



 You can still easily get into deadline trouble with either large queues, or
 multiple projects and an occasional tight deadline.

 Sent from my Android phone using TouchDown 
 (www.nitrodesk.comhttp://www.nitrodesk.comhttp://www.nitrodesk.comhttp://www.nitrodesk.com)

 -Original Message-
 From: Charles Elliott [elliott...@comcast.net]
 Received: Friday, 03 Oct 2014, 10:10PM
 To: 'Jacob Klein' [jacob_w_kl...@msn.com]; 'Richard Haselgrove'
 [r.haselgr...@btopenworld.com]; McLeod, John [john.mcl...@sap.com];
 boinc_dev@ssl.berkeley.edu [boinc_dev@ssl.berkeley.edu]
 Subject: RE: [boinc_dev] High priority status message removed.

 On my computer, which is allocated about 300 AP WUs at a time, in late
 September Boinc was running AP WUs due in late October.  Then when October
 1 came it seemingly panicked and stopped doing anything but processing AP
 WUs
 due October 17.  That behavior was useful when we could download thousands
 of WUs, but I think it should be questioned now.

 Charles Elliott

 -Original Message-
 From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf
 Of Jacob Klein
 Sent: Friday, October 3, 2014 9:24 AM
 To: Richard Haselgrove; McLeod, John; boinc_dev@ssl.berkeley.edu
 Subject: Re: [boinc_dev] High priority status message removed.

 I'd like to see Prioritized to meet deadline in the UI, next to
 Running.

 
 From: Richard Haselgrovemailto:r.haselgr...@btopenworld.com
 Sent: ‎10/‎3/‎2014 9:19 AM
 To: McLeod, Johnmailto:john.mcl...@sap.com;
 boinc_dev@ssl.berkeley.edu
 mailto:boinc_dev@ssl.berkeley.edu%3cmailto:boinc_dev@ssl.berkeley.edu
 mailto:boinc_dev@ssl.berkeley.edu
 Subject: Re: [boinc_dev] High priority status message removed.

 The removal followed a question and answer session at the BOINC
 workshop in Budapest earlier this week. The OS scheduler mis-
 interpretation was one that I highlighted, but there was also a problem
 with users thinking that High Priority was a project-chosen queue-
 jumping facility. I think we're much better off without those
 confusions over terminology, but I agree with John

[boinc_dev] High priority status message removed.

[McLeod, John]

OK, High Priority made it sound like it was running at High OS Scheduler 
Priority, but some tag that it is not in the normal RR schedule might be good 
for helping diagnose problems.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] High priority status message removed.

[McLeod, John]

This sounds good.  To the point and lets the user know why it is running out of 
order.

From: Jacob Klein [mailto:jacob_w_kl...@msn.com]
Sent: Friday, October 03, 2014 9:24 AM
To: Richard Haselgrove; McLeod, John; boinc_dev@ssl.berkeley.edu
Subject: RE: [boinc_dev] High priority status message removed.

I'd like to see Prioritized to meet deadline in the UI, next to Running.

From: Richard Haselgrovemailto:r.haselgr...@btopenworld.com
Sent: ‎10/‎3/‎2014 9:19 AM
To: McLeod, Johnmailto:john.mcl...@sap.com; 
boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] High priority status message removed.
The removal followed a question and answer session at the BOINC workshop in 
Budapest earlier this week. The OS scheduler mis-interpretation was one that I 
highlighted, but there was also a problem with users thinking that High 
Priority was a project-chosen queue-jumping facility. I think we're much better 
off without those confusions over terminology, but I agree with John that it 
would be good if the reason for non-FIFO running could be marked in some way - 
if we can find a less-frightening word.




 From: McLeod, John john.mcl...@sap.commailto:john.mcl...@sap.com
To: boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu 
boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
Sent: Friday, October 3, 2014 2:01 PM
Subject: [boinc_dev] High priority status message removed.


OK, High Priority made it sound like it was running at High OS Scheduler 
Priority, but some tag that it is not in the normal RR schedule might be good 
for helping diagnose problems.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edumailto:boinc_dev@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.



___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edumailto:boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] High priority status message removed.

[McLeod, John]

Neither preference nor precedence has the quite right meaning in English though.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Jord 
van der Elst
Sent: Friday, October 03, 2014 11:53 AM
To: David Anderson
Cc: BOINC Dev Mailing List
Subject: Re: [boinc_dev] High priority status message removed.

Task xx_yy_zz running as preference, trying to meet the deadline.
Task xx_yy_zz running in precedence, trying to meet the deadline.

Seeing how we do want to tell that it's a status in order of
importance or urgency, we may want to go for the second one.

-- Jord van der Elst.


On Fri, Oct 3, 2014 at 4:44 PM, David Anderson da...@ssl.berkeley.edu wrote:
 I think anything containing priority will create confusion
 with OS priority.

 The other problem with showing this info is that it creates the
 erroneous impression that the job's project will get more than
 its fair share of computing.
 Several projects report that when they use short job deadlines
 (which create high priority jobs) they get lots of user complaints.

 So I'm in favor of not showing this in the GUI;
 maybe we can show it in the event log in some better way.

 -- D

 On 03-Oct-2014 3:24 PM, Jacob Klein wrote:

 I'd like to see Prioritized to meet deadline in the UI, next to
 Running.

 
 From: Richard Haselgrovemailto:r.haselgr...@btopenworld.com
 Sent: ‎10/‎3/‎2014 9:19 AM
 To: McLeod, Johnmailto:john.mcl...@sap.com;
 boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
 Subject: Re: [boinc_dev] High priority status message removed.

 The removal followed a question and answer session at the BOINC workshop
 in Budapest earlier this week. The OS scheduler mis-interpretation was one
 that I highlighted, but there was also a problem with users thinking that
 High Priority was a project-chosen queue-jumping facility. I think we're
 much better off without those confusions over terminology, but I agree with
 John that it would be good if the reason for non-FIFO running could be
 marked in some way - if we can find a less-frightening word.



 
 From: McLeod, John john.mcl...@sap.com
 To: boinc_dev@ssl.berkeley.edu boinc_dev@ssl.berkeley.edu
 Sent: Friday, October 3, 2014 2:01 PM
 Subject: [boinc_dev] High priority status message removed.


 OK, High Priority made it sound like it was running at High OS Scheduler
 Priority, but some tag that it is not in the normal RR schedule might be
 good for helping diagnose problems.
 ___
 boinc_dev mailing list
 boinc_dev@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.



 ___
 boinc_dev mailing list
 boinc_dev@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.
 ___
 boinc_dev mailing list
 boinc_dev@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.

 ___
 boinc_dev mailing list
 boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] High priority status message removed.

[McLeod, John]

I know the dictionary meanings.  Precedence tends to carry a connotation of 
permanent.  Preference t (in computers at least) tends to mean settable by the 
user.

-Original Message-
From: Jord van der Elst [mailto:els...@gmail.com] 
Sent: Friday, October 03, 2014 12:10 PM
To: McLeod, John
Cc: David Anderson; BOINC Dev Mailing List
Subject: Re: [boinc_dev] High priority status message removed.

Priority: a thing that is regarded as more important than another.
or: the fact or condition of being regarded or treated as more important.
or: the right to take precedence or to proceed before others. ** ---

Precedence: the condition of being considered more important than
someone or something else; priority in importance, order, or rank.
I'd say it's second to (high) priority.

Preference: a greater liking for one alternative over another or others.
or: a prior right or precedence, especially in connection with the
payment of debts.

We want to step away from priority, but do we still want it to have
the same meaning? As then you look at synonyms, which is what I did:
http://www.thesaurus.com/browse/priority

-- Jord van der Elst.


On Fri, Oct 3, 2014 at 6:03 PM, McLeod, John john.mcl...@sap.com wrote:
 Neither preference nor precedence has the quite right meaning in English 
 though.

 -Original Message-
 From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Jord 
 van der Elst
 Sent: Friday, October 03, 2014 11:53 AM
 To: David Anderson
 Cc: BOINC Dev Mailing List
 Subject: Re: [boinc_dev] High priority status message removed.

 Task xx_yy_zz running as preference, trying to meet the deadline.
 Task xx_yy_zz running in precedence, trying to meet the deadline.

 Seeing how we do want to tell that it's a status in order of
 importance or urgency, we may want to go for the second one.

 -- Jord van der Elst.


 On Fri, Oct 3, 2014 at 4:44 PM, David Anderson da...@ssl.berkeley.edu wrote:
 I think anything containing priority will create confusion
 with OS priority.

 The other problem with showing this info is that it creates the
 erroneous impression that the job's project will get more than
 its fair share of computing.
 Several projects report that when they use short job deadlines
 (which create high priority jobs) they get lots of user complaints.

 So I'm in favor of not showing this in the GUI;
 maybe we can show it in the event log in some better way.

 -- D

 On 03-Oct-2014 3:24 PM, Jacob Klein wrote:

 I'd like to see Prioritized to meet deadline in the UI, next to
 Running.

 
 From: Richard Haselgrovemailto:r.haselgr...@btopenworld.com
 Sent: ‎10/‎3/‎2014 9:19 AM
 To: McLeod, Johnmailto:john.mcl...@sap.com;
 boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
 Subject: Re: [boinc_dev] High priority status message removed.

 The removal followed a question and answer session at the BOINC workshop
 in Budapest earlier this week. The OS scheduler mis-interpretation was one
 that I highlighted, but there was also a problem with users thinking that
 High Priority was a project-chosen queue-jumping facility. I think we're
 much better off without those confusions over terminology, but I agree with
 John that it would be good if the reason for non-FIFO running could be
 marked in some way - if we can find a less-frightening word.



 
 From: McLeod, John john.mcl...@sap.com
 To: boinc_dev@ssl.berkeley.edu boinc_dev@ssl.berkeley.edu
 Sent: Friday, October 3, 2014 2:01 PM
 Subject: [boinc_dev] High priority status message removed.


 OK, High Priority made it sound like it was running at High OS Scheduler
 Priority, but some tag that it is not in the normal RR schedule might be
 good for helping diagnose problems.
 ___
 boinc_dev mailing list
 boinc_dev@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.



 ___
 boinc_dev mailing list
 boinc_dev@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.
 ___
 boinc_dev mailing list
 boinc_dev@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.

 ___
 boinc_dev mailing list
 boinc_dev@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.
 ___
 boinc_dev mailing list
 boinc_dev@ssl.berkeley.edu
 http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
 To unsubscribe, visit the above URL and
 (near bottom

Re: [boinc_dev] High priority status message removed.

[McLeod, John]

That misses the detail that the time is borrowed, and will be paid back.

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-Original Message-
From: Juha [juha.sointus...@gmail.com]
Received: Friday, 03 Oct 2014, 2:22PM
To: BOINC Development [boinc_dev@ssl.berkeley.edu]
Subject: Re: [boinc_dev] High priority status message removed.

Skipping queue to meet deadline ?

-Juha


On 3 October 2014 19:15, Jacob Klein jacob_w_kl...@msn.com wrote:

 I still would like to see Prioritized to meet deadline in the UI, next
 to Running, despite David's logic against it.

 The user's interpretations are not something we can control.
 Providing the feedback, using as meaningful description as possible, is
 something we can control.
 And I haven't heard anything that beats my proposal, hence why I'd still
 like to see it.
 :)



  From: john.mcl...@sap.com
  To: els...@gmail.com
  Date: Fri, 3 Oct 2014 16:13:11 +
  CC: boinc_dev@ssl.berkeley.edu
  Subject: Re: [boinc_dev] High priority status message removed.
 
  I know the dictionary meanings.  Precedence tends to carry a connotation
 of permanent.  Preference t (in computers at least) tends to mean settable
 by the user.
 
  -Original Message-
  From: Jord van der Elst [mailto:els...@gmail.com]
  Sent: Friday, October 03, 2014 12:10 PM
  To: McLeod, John
  Cc: David Anderson; BOINC Dev Mailing List
  Subject: Re: [boinc_dev] High priority status message removed.
 
  Priority: a thing that is regarded as more important than another.
  or: the fact or condition of being regarded or treated as more important.
  or: the right to take precedence or to proceed before others. ** ---
 
  Precedence: the condition of being considered more important than
  someone or something else; priority in importance, order, or rank.
  I'd say it's second to (high) priority.
 
  Preference: a greater liking for one alternative over another or others.
  or: a prior right or precedence, especially in connection with the
  payment of debts.
 
  We want to step away from priority, but do we still want it to have
  the same meaning? As then you look at synonyms, which is what I did:
  http://www.thesaurus.com/browse/priority
 
  -- Jord van der Elst.
 
 
  On Fri, Oct 3, 2014 at 6:03 PM, McLeod, John john.mcl...@sap.com
 wrote:
   Neither preference nor precedence has the quite right meaning in
 English though.
  
   -Original Message-
   From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf
 Of Jord van der Elst
   Sent: Friday, October 03, 2014 11:53 AM
   To: David Anderson
   Cc: BOINC Dev Mailing List
   Subject: Re: [boinc_dev] High priority status message removed.
  
   Task xx_yy_zz running as preference, trying to meet the deadline.
   Task xx_yy_zz running in precedence, trying to meet the deadline.
  
   Seeing how we do want to tell that it's a status in order of
   importance or urgency, we may want to go for the second one.
  
   -- Jord van der Elst.
  
  
   On Fri, Oct 3, 2014 at 4:44 PM, David Anderson da...@ssl.berkeley.edu
 wrote:
   I think anything containing priority will create confusion
   with OS priority.
  
   The other problem with showing this info is that it creates the
   erroneous impression that the job's project will get more than
   its fair share of computing.
   Several projects report that when they use short job deadlines
   (which create high priority jobs) they get lots of user complaints.
  
   So I'm in favor of not showing this in the GUI;
   maybe we can show it in the event log in some better way.
  
   -- D
  
   On 03-Oct-2014 3:24 PM, Jacob Klein wrote:
  
   I'd like to see Prioritized to meet deadline in the UI, next to
   Running.
  
   
   From: Richard Haselgrovemailto:r.haselgr...@btopenworld.com
   Sent: ‎10/‎3/‎2014 9:19 AM
   To: McLeod, Johnmailto:john.mcl...@sap.com;
   boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
   Subject: Re: [boinc_dev] High priority status message removed.
  
   The removal followed a question and answer session at the BOINC
 workshop
   in Budapest earlier this week. The OS scheduler mis-interpretation
 was one
   that I highlighted, but there was also a problem with users thinking
 that
   High Priority was a project-chosen queue-jumping facility. I think
 we're
   much better off without those confusions over terminology, but I
 agree with
   John that it would be good if the reason for non-FIFO running could
 be
   marked in some way - if we can find a less-frightening word.
  
  
  
   
   From: McLeod, John john.mcl...@sap.com
   To: boinc_dev@ssl.berkeley.edu boinc_dev@ssl.berkeley.edu
   Sent: Friday, October 3, 2014 2:01 PM
   Subject: [boinc_dev] High priority status message removed.
  
  
   OK, High Priority made it sound like it was running at High OS
 Scheduler
   Priority, but some tag that it is not in the normal RR schedule
 might be
   good for helping diagnose

Re: [boinc_dev] High priority status message removed.

[McLeod, John]

You can still easily get into deadline trouble with either large queues, or 
multiple projects and an occasional tight deadline.

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-Original Message-
From: Charles Elliott [elliott...@comcast.net]
Received: Friday, 03 Oct 2014, 10:10PM
To: 'Jacob Klein' [jacob_w_kl...@msn.com]; 'Richard Haselgrove' 
[r.haselgr...@btopenworld.com]; McLeod, John [john.mcl...@sap.com]; 
boinc_dev@ssl.berkeley.edu [boinc_dev@ssl.berkeley.edu]
Subject: RE: [boinc_dev] High priority status message removed.

On my computer, which is allocated about 300 AP WUs at a time, in late
September Boinc was running AP WUs due in late October.  Then when October
1 came it seemingly panicked and stopped doing anything but processing AP WUs
due October 17.  That behavior was useful when we could download thousands
of WUs, but I think it should be questioned now.

Charles Elliott

 -Original Message-
 From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf
 Of Jacob Klein
 Sent: Friday, October 3, 2014 9:24 AM
 To: Richard Haselgrove; McLeod, John; boinc_dev@ssl.berkeley.edu
 Subject: Re: [boinc_dev] High priority status message removed.

 I'd like to see Prioritized to meet deadline in the UI, next to
 Running.

 
 From: Richard Haselgrovemailto:r.haselgr...@btopenworld.com
 Sent: ‎10/‎3/‎2014 9:19 AM
 To: McLeod, Johnmailto:john.mcl...@sap.com;
 boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
 Subject: Re: [boinc_dev] High priority status message removed.

 The removal followed a question and answer session at the BOINC
 workshop in Budapest earlier this week. The OS scheduler mis-
 interpretation was one that I highlighted, but there was also a problem
 with users thinking that High Priority was a project-chosen queue-
 jumping facility. I think we're much better off without those
 confusions over terminology, but I agree with John that it would be
 good if the reason for non-FIFO running could be marked in some way -
 if we can find a less-frightening word.



 
  From: McLeod, John john.mcl...@sap.com
 To: boinc_dev@ssl.berkeley.edu boinc_dev@ssl.berkeley.edu
 Sent: Friday, October 3, 2014 2:01 PM
 Subject: [boinc_dev] High priority status message removed.
 
 
 OK, High Priority made it sound like it was running at High OS
 Scheduler Priority, but some tag that it is not in the normal RR
 schedule might be good for helping diagnose problems.
 ___
 boinc_dev mailing list
 boinc_dev@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.
 
 
 
 ___
 boinc_dev mailing list
 boinc_dev@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.
 ___
 boinc_dev mailing list
 boinc_dev@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.

___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] BOINCscheduling plan class possible issue

[McLeod, John]

Would that then prevent BOINC from running tasks on some of the GPS for any 
tasks?

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-Original Message-
From: David Anderson [da...@ssl.berkeley.edu]
Received: Thursday, 02 Oct 2014, 10:58AM
To: boinc_dev@ssl.berkeley.edu [boinc_dev@ssl.berkeley.edu]
Subject: Re: [boinc_dev] BOINCscheduling  plan class possible issue

I assume these are cases where the user has set use_all_gpus.
If that flag is removed the problem should go away.
-- David

On 02-Oct-2014 4:28 PM, Raistmer the Sorcerer wrote:
 It was discovered that OpenCL AstroPulse application in SETI can't properly 
 work
 under 340.52 nVidia driver on pre-FERMI hardware (single pulses missing, issue
 reported and reproduced by NV already). To avoid wrong computations Eric 
 created
 2 plan classes that should avoid work sending on pre-FERMI GPUs running under
 that faulty driver.

 But it was discovered (look here:
 http://setiweb.ssl.berkeley.edu/beta/forum_thread.php?id=2182postid=52632  )
 that multi-GPU hosts containing both FERMI and pre-FERMI GPUs are able to 
 recive
 tasks under another common plan class for FERMI devices and execute those 
 recived
 tasks on pre-FERMI devices. That is, though server obey plan class and ignore
 pre-FERMI devices on 340.52 driver, BOINC client doesn't obey plan class and
 schedule to run tasks for FERMI devices on pre-FERMI ones (when both present 
 in
 host).

 Could someone confirm this issue? And how one should act to exclude pre-FERMI
 devices on 340.52 driver in such case of mixed NV devices in host?



___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] BOINCscheduling plan class possible issue

[McLeod, John]

Is there some way to use both GPUS and get the correct app running on the 
correct device?

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-Original Message-
From: David Anderson [da...@ssl.berkeley.edu]
Received: Thursday, 02 Oct 2014, 11:06AM
To: McLeod, John [john.mcl...@sap.com]; boinc_dev@ssl.berkeley.edu 
[boinc_dev@ssl.berkeley.edu]
Subject: Re: [boinc_dev] BOINCscheduling  plan class possible issue

Yes.
You can also use exclude_gpu to be more specific
about which GPU to use for which project.

On 02-Oct-2014 4:59 PM, McLeod, John wrote:
 Would that then prevent BOINC from running tasks on some of the GPS for any 
 tasks?

 Sent from my Android phone using TouchDown 
 (www.nitrodesk.comhttp://www.nitrodesk.com)

 -Original Message-
 *From:* David Anderson [da...@ssl.berkeley.edu]
 *Received:* Thursday, 02 Oct 2014, 10:58AM
 *To:* boinc_dev@ssl.berkeley.edu [boinc_dev@ssl.berkeley.edu]
 *Subject:* Re: [boinc_dev] BOINCscheduling  plan class possible issue

 I assume these are cases where the user has set use_all_gpus.
 If that flag is removed the problem should go away.
 -- David

 On 02-Oct-2014 4:28 PM, Raistmer the Sorcerer wrote:
 It was discovered that OpenCL AstroPulse application in SETI can't properly 
 work
 under 340.52 nVidia driver on pre-FERMI hardware (single pulses missing, 
 issue
 reported and reproduced by NV already). To avoid wrong computations Eric 
 created
 2 plan classes that should avoid work sending on pre-FERMI GPUs running under
 that faulty driver.

 But it was discovered (look here:
http://setiweb.ssl.berkeley.edu/beta/forum_thread.php?id=2182postid=52632  )
 that multi-GPU hosts containing both FERMI and pre-FERMI GPUs are able to 
 recive
 tasks under another common plan class for FERMI devices and execute those 
 recived
 tasks on pre-FERMI devices. That is, though server obey plan class and ignore
 pre-FERMI devices on 340.52 driver, BOINC client doesn't obey plan class and
 schedule to run tasks for FERMI devices on pre-FERMI ones (when both present 
 in
 host).

 Could someone confirm this issue? And how one should act to exclude pre-FERMI
 devices on 340.52 driver in such case of mixed NV devices in host?



 ___
 boinc_dev mailing list
 boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] BOINCscheduling plan class possible issue

[McLeod, John]

Can the project send work that will run on the least capable device and have it 
run on both?

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-Original Message-
From: Raistmer the Sorcerer [raist...@mail.ru]
Received: Thursday, 02 Oct 2014, 11:47AM
To: boinc_dev@ssl.berkeley.edu [boinc_dev@ssl.berkeley.edu]
Subject: Re: [boinc_dev] BOINCscheduling  plan class possible issue

This solution requires user intervention. The question is how to avoid this 
server-side. User can be not aware that his host generates invalid result and 
project can't prevent it now.


Thu, 02 Oct 2014 17:06:05 +0200 от David Anderson da...@ssl.berkeley.edu:
Yes.
You can also use exclude_gpu to be more specific
about which GPU to use for which project.

On 02-Oct-2014 4:59 PM, McLeod, John wrote:
 Would that then prevent BOINC from running tasks on some of the GPS for any 
 tasks?

 Sent from my Android phone using TouchDown ( 
 www.nitrodesk.comhttp://www.nitrodesk.com )

 -Original Message-
 *From:* David Anderson [da...@ssl.berkeley.edu]
 *Received:* Thursday, 02 Oct 2014, 10:58AM
 *To:*  boinc_dev@ssl.berkeley.edu [boinc_dev@ssl.berkeley.edu]
 *Subject:* Re: [boinc_dev] BOINCscheduling  plan class possible issue

 I assume these are cases where the user has set use_all_gpus.
 If that flag is removed the problem should go away.
 -- David

 On 02-Oct-2014 4:28 PM, Raistmer the Sorcerer wrote:
 It was discovered that OpenCL AstroPulse application in SETI can't properly 
 work
 under 340.52 nVidia driver on pre-FERMI hardware (single pulses missing, 
 issue
 reported and reproduced by NV already). To avoid wrong computations Eric 
 created
 2 plan classes that should avoid work sending on pre-FERMI GPUs running 
 under
 that faulty driver.

 But it was discovered (look here:
 http://setiweb.ssl.berkeley.edu/beta/forum_thread.php?id=2182postid=52632 )
 that multi-GPU hosts containing both FERMI and pre-FERMI GPUs are able to 
 recive
 tasks under another common plan class for FERMI devices and execute those 
 recived
 tasks on pre-FERMI devices. That is, though server obey plan class and 
 ignore
 pre-FERMI devices on 340.52 driver, BOINC client doesn't obey plan class and
 schedule to run tasks for FERMI devices on pre-FERMI ones (when both 
 present in
 host).

 Could someone confirm this issue? And how one should act to exclude 
 pre-FERMI
 devices on 340.52 driver in such case of mixed NV devices in host?



 ___
 boinc_dev mailing list
  boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] BOINCscheduling plan class possible issue

[McLeod, John]

That is unfortunate.

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-Original Message-
From: Eric J Korpela [korp...@ssl.berkeley.edu]
Received: Thursday, 02 Oct 2014, 12:04PM
To: McLeod, John [john.mcl...@sap.com]
CC: boinc_dev@ssl.berkeley.edu [boinc_dev@ssl.berkeley.edu]; raist...@mail.ru 
[raist...@mail.ru]
Subject: Re: [boinc_dev] BOINCscheduling  plan class possible issue

The project is only informed about the most capable devices and the total 
number of GPUs.

On Thu, Oct 2, 2014 at 8:59 AM, McLeod, John 
john.mcl...@sap.commailto:john.mcl...@sap.com wrote:
Can the project send work that will run on the least capable device and have it 
run on both?

Sent from my Android phone using TouchDown 
(www.nitrodesk.comhttp://www.nitrodesk.com)

-Original Message-
From: Raistmer the Sorcerer [raist...@mail.rumailto:raist...@mail.ru]
Received: Thursday, 02 Oct 2014, 11:47AM
To: boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu 
[boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu]
Subject: Re: [boinc_dev] BOINCscheduling  plan class possible issue

This solution requires user intervention. The question is how to avoid this 
server-side. User can be not aware that his host generates invalid result and 
project can't prevent it now.


Thu, 02 Oct 2014 17:06:05 +0200 от David Anderson 
da...@ssl.berkeley.edumailto:da...@ssl.berkeley.edu:
Yes.
You can also use exclude_gpu to be more specific
about which GPU to use for which project.

On 02-Oct-2014 4:59 PM, McLeod, John wrote:
 Would that then prevent BOINC from running tasks on some of the GPS for any 
 tasks?

 Sent from my Android phone using TouchDown ( 
 www.nitrodesk.comhttp://www.nitrodesk.comhttp://www.nitrodesk.com )

 -Original Message-
 *From:* David Anderson 
 [da...@ssl.berkeley.edumailto:da...@ssl.berkeley.edu]
 *Received:* Thursday, 02 Oct 2014, 10:58AM
 *To:*  boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu 
 [boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu]
 *Subject:* Re: [boinc_dev] BOINCscheduling  plan class possible issue

 I assume these are cases where the user has set use_all_gpus.
 If that flag is removed the problem should go away.
 -- David

 On 02-Oct-2014 4:28 PM, Raistmer the Sorcerer wrote:
 It was discovered that OpenCL AstroPulse application in SETI can't properly 
 work
 under 340.52 nVidia driver on pre-FERMI hardware (single pulses missing, 
 issue
 reported and reproduced by NV already). To avoid wrong computations Eric 
 created
 2 plan classes that should avoid work sending on pre-FERMI GPUs running 
 under
 that faulty driver.

 But it was discovered (look here:
 http://setiweb.ssl.berkeley.edu/beta/forum_thread.php?id=2182postid=52632 )
 that multi-GPU hosts containing both FERMI and pre-FERMI GPUs are able to 
 recive
 tasks under another common plan class for FERMI devices and execute those 
 recived
 tasks on pre-FERMI devices. That is, though server obey plan class and 
 ignore
 pre-FERMI devices on 340.52 driver, BOINC client doesn't obey plan class and
 schedule to run tasks for FERMI devices on pre-FERMI ones (when both 
 present in
 host).

 Could someone confirm this issue? And how one should act to exclude 
 pre-FERMI
 devices on 340.52 driver in such case of mixed NV devices in host?



 ___
 boinc_dev mailing list
  boinc_dev@ssl.berkeley.edumailto:boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edumailto:boinc_dev@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.

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edumailto:boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edumailto:boinc_dev@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.


___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] Common faulty reasoning problem in Computer Science : Confusing Binary Math Ops with Int Ops or Float Ops ...

[McLeod, John]

I am not at all certain I understand your distinction between Binary Math and 
Integer Math.  By Binary Math do you mean control logic?  If not, what do you 
mean?

Almost all integer math can be done in machine registers now since the narrow 
machines are 32 bits (+/- 2*10^9) and wide machines are 64 bits (+/- 9*10^18).  
There are only a few kinds of calculations that have intermediate or final 
results larger than that.  It is not that hard to produce a math class that can 
do arithmetic to 128 bits - which should be sufficient for just about 
everything other than encryption.  

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Max 
Power
Sent: Tuesday, August 12, 2014 4:03 AM
To: BOINC Developers Mailing l...@berkeley.edu
Subject: [boinc_dev] Common faulty reasoning problem in Computer Science : 
Confusing Binary Math Ops with Int Ops or Float Ops ...


Common faulty reasoning problem in Computer Science : Confusing Binary Math Ops 
with Int Ops or Float Ops ...

It’s a layer cake

-- “allows the creation of”

[Binary Math Ops] – [Integer Math Ops]
-- if your CPU only understands INTs
-- Floating Point can be emulated with Int Math and Binary Ops

[Binary Math Ops] 
– [Integer Math Ops] 
-- [Floating Point Math Ops] 

-- ^ ^ If the CPU does native Floating Point ^ ^ 

-- If all integer control logic is removed, Binary Math Ops go at true clock 
speed 
-- Int and Float math will never really reach true clock speed, as there is an 
inherent overhead as both are based on Binary Math Ops (and Microcode based 
CPUs are worse for speed for this reason)


This is why ASICs do binary hashes so fast, yet Cray XPs struggle in massive 
parallelism to perform Floating Point at anything like real clock speed. 


Moral : 
When in doubt go to the fundamental underlying framework to help solve a 
problem, if no other solution is working. 


MP DSN @ Home


PS :

I have designed a CPU, but C is for Climate ...
http://www.scribd.com/doc/209133631/Climate-Prediction-Coprocessor






My feeling about this is that computing credit should be measure 
general-purpose FLOPs, i.e. FLOPs that are usable by most science applications. 
FFT FLOPs are not general-purpose. So the right thing would be for SETI@home to 
grant both computing credit and project-defined credit. CPU and GPU jobs would 
be granted both; jobs done by ASICs or FPGAs would be granted only 
project-defined credit.

Similarly, BU could grant computing credit for mining jobs done by CPU or GPU; 
but for ASIC jobs it would grant only project-defined credit.

Of course this is all subjective and fuzzy; you might argue that GPU FLOPs are 
not general-purpose because some apps don't map well to GPUs. But we need to 
draw a line somewhere, and I think that, with the advent of OpenCL, GPUs can be 
considered general-purpose.








___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] astropulse robustness / abandonned tasks

[McLeod, John]

BOINC has a checkpointing mechanism built in, but it requires that the project 
developers write checkpoint code.  Some projects can checkpoint almost any 
time, and others can checkpoint only every few minutes, and some cannot 
checkpoint at all.  SETI can checkpoint frequently (and instigated the 
mechanism to NOT do every possible checkpoint, but only once every X minutes).  
CPDN always checkpoints every time it can (typically this is several minutes).  
I cannot remember an example of one that cannot checkpoint at all, but they 
exist.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Richard Haselgrove
Sent: Friday, August 08, 2014 4:48 AM
To: Luc A. Germain; boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] astropulse robustness / abandonned tasks

The abandoning of tasks happens when the BOINC server 'thinks' that it has 
'evidence' that the client has detached from the project and then re-attached 
again. This has affected a number of users in the past, but has proved 
extremely tricky to diagnose and resolve: not least, because most of the 
evidence resides in the server logs.

We did investigate one suspected case at Albert during credit testing, but that 
turned out to be a genuine 'detach' caused by hard disk failure - it is 
distinguished from reports like this one because no running tasks were left on 
the host computer (they were on the drive that failed...) to waste time and 
electricity.

I would certainly welcome it if we could pair up a developer and a project 
administrator with access to server logs to investigate this problem and cure 
it at source.

The checkpointing question is a matter for the project developers, and I'll 
leave it to them to respond via this list.




 From: Luc A. Germain l...@lucg.net
To: boinc_dev@ssl.berkeley.edu 
Sent: Friday, 8 August 2014, 9:41
Subject: [boinc_dev] astropulse robustness / abandonned tasks
 

Hi,
Two things:
1) A suggestion here for you develloppers ;-) As atropulse tasks take some 
time to complete they are more prone to power failure as we have in the third 
world. When it happens most of the time the task restarts computing from start 
(this is even more frustrating when the task reaches near completion). Could 
it be possible to introduce regular checkpoints by saving intermediate data, 
or work files, where the task computing could restart from, saving so a lot of 
computing time ? Maybe this could be an option in the user profile as I guess 
not everyone needs this.

2) Two days ago I sent a message about abandonned tasks. Since, all my 
computing goes to the garbage bin as they are not taken into account. Which 
procedure should/could I try to solve this problem ? Could 
uninstalling/reinstalling the application from my computers be a solution? 
Should I wait till the problem solves by itself (and would this not take ages) 
?

An answer would be highly appreciated.

Best regards and thanks for your work,
Luc
___
boinc_dev mailing list
boinc_dev@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.



___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] astropulse robustness / abandonned tasks

[McLeod, John]

One technique used to create a new host that is attached to everything that an 
old host is attached to is to copy the entire data directory from old to new 
and install BOINC on the new host.  This would tend to preserve the sequence 
number.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Eric J 
Korpela
Sent: Friday, August 08, 2014 1:44 PM
To: Richard Haselgrove
Cc: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] astropulse robustness / abandonned tasks

The other possibility is the sender doesn't think the prior RPC completed
and didn't update the sequence number (although I haven't looked at the
code to see if this is possible).  With a mismatch of one out of 59643
seems like the server is reaching exactly the wrong conclusion (this is a
new host) rather than the right one (there was a communications problem on
the prior contact).  If it were a new host, shouldn't the sequence number
be near 0?


On Fri, Aug 8, 2014 at 10:19 AM, Richard Haselgrove 
r.haselgr...@btopenworld.com wrote:

 In probably the fullest message board description on the last circuit
 round this merry-go-round,

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

 we observed a number of occasions where client message logs contained
 lines like

 22.05.2013 13:45:56 | SETI@home | Not sending work - last request too
 recent: 76 sec

 at times not unadjacent to the times when abandonments were recorded for
 user tasks. That led us into 'clutching at straws' mode: was another
 computer sending out-of-sequence RPC requests with duplicate credentials?
 (the users swore not). Were entire RPC requests being delayed in a transit
 queue and arriving out of sequence? Unlikely. Was the server receiving the
 RPCs in a timely fashion, but processing them out of order - perhaps
 delaying one because of incomplete packets?

 And so on. Most of this was happening before the server move to CoLo, when
 the SETI data line was heavily congested - we thought the problem might
 diminish with the higher-quality internet service at the bottom of the
 hill, and so it seems to have transpired. But doesn't help our friends
 outwith the continental USA.

 Incidentally, I reported seeing one 'last request too recent' in my own
 logs, and traced it back to an internet time update changing the computer
 clock. But I didn't suffer any abandoned tasks in that event.

   --
  *From:* Eric J Korpela korp...@ssl.berkeley.edu
 *To:* Richard Haselgrove r.haselgr...@btopenworld.com
 *Cc:* boinc_dev@ssl.berkeley.edu boinc_dev@ssl.berkeley.edu
 *Sent:* Friday, 8 August 2014, 17:47

 *Subject:* Re: [boinc_dev] astropulse robustness / abandonned tasks

 His host seems to be losing track of RPC sequence numbers.  Loss of cached
 writes on restart?

 2014-08-08 07:13:53.1883 [PID=28339]  [HOST#6960982] [USER#8522684] RPC
 seqno 59642 less than expected 59643; creating new host
 2014-08-08 07:13:53.1896 [PID=28339]  [HOST#6960982] [USER#8522684] Found
 similar existing host for this user - assigned.
 2014-08-08 07:13:53.1932 [PID=28339] [CRITICAL]  [HOST#6960982]
 [RESULT#3670788988] [WU#1562416658] changed CPID: marking in-progress
 result 03se08ad.16169.8252.438086664200.12.220_0 as client error!
 2014-08-08 07:13:53.1932 [PID=28339]  Request: [USER#8522684]
 [HOST#6960982] [IP 41.79.224.134] client 7.2.42



 On Fri, Aug 8, 2014 at 9:17 AM, Richard Haselgrove 
 r.haselgr...@btopenworld.com wrote:

  The same user appears to have suffered another 'abandon' event today:
 
  http://setiathome.berkeley.edu/results.php?hostid=6960982state=6
 
  The reasons mentioned by Eric are all valid, but there appears to be an
  irreducible core of sporadic events which cannot be ascribed to user
  malfeasance. In earlier reports like this, many (but not all) of the
 cases
  appeared to be associated with long-distance and/or poor quality internet
  connections - again, like this one.
 
   --
   *From:* Eric J Korpela korp...@ssl.berkeley.edu
  *To:* McLeod, John john.mcl...@sap.com
  *Cc:* boinc_dev@ssl.berkeley.edu boinc_dev@ssl.berkeley.edu; Richard
  Haselgrove r.haselgr...@btopenworld.com
  *Sent:* Friday, 8 August 2014, 16:56
 
  *Subject:* Re: [boinc_dev] astropulse robustness / abandonned tasks

 
  Astropulse does checkpoint quite frequently, and restarts without problem
  most of the time.  Abandoned is definitely a server side decision that
  indicates a client detach or a reset or some sort of confusion as to the
  identity of a host and whether it was working on those results.  (Other
  possibilities include multiple hosts using a copied or shared BOINC
  directory, multiple copies of BOINC on one host using the same BOINC
 client
  directory, deletion or corruption or bad permissions on files in the
 BOINC
  client directory, any of which could confuse client or server).
 
 
  Which client version and OS are you using?
 
 
  On Fri, Aug 8, 2014 at 5:55 AM

Re: [boinc_dev] astropulse robustness / abandonned tasks

[McLeod, John]

Yes, but, it is a reason that checking for a sequence number near 0 vs near the 
current sequence number does not work reliably.

Would resetting the sequence number to 0 if the CPU or OS changed work?  These 
are changes that would tend to indicate a new computer.

From: Richard Haselgrove [mailto:r.haselgr...@btopenworld.com]
Sent: Friday, August 08, 2014 1:54 PM
To: McLeod, John; Eric J Korpela
Cc: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] astropulse robustness / abandonned tasks

That is certainly true, but in the cases that I investigated - which started 
with posts in various degrees of indignation on the message boards - the users 
were adamant that copying of data directories had *not* taken place.


From: McLeod, John john.mcl...@sap.commailto:john.mcl...@sap.com
To: Eric J Korpela korp...@ssl.berkeley.edumailto:korp...@ssl.berkeley.edu; 
Richard Haselgrove 
r.haselgr...@btopenworld.commailto:r.haselgr...@btopenworld.com
Cc: boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu 
boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
Sent: Friday, 8 August 2014, 18:47
Subject: RE: [boinc_dev] astropulse robustness / abandonned tasks

One technique used to create a new host that is attached to everything that an 
old host is attached to is to copy the entire data directory from old to new 
and install BOINC on the new host.  This would tend to preserve the sequence 
number.

-Original Message-
From: boinc_dev 
[mailto:boinc_dev-boun...@ssl.berkeley.edumailto:boinc_dev-boun...@ssl.berkeley.edu]
 On Behalf Of Eric J Korpela
Sent: Friday, August 08, 2014 1:44 PM
To: Richard Haselgrove
Cc: boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] astropulse robustness / abandonned tasks

The other possibility is the sender doesn't think the prior RPC completed
and didn't update the sequence number (although I haven't looked at the
code to see if this is possible).  With a mismatch of one out of 59643
seems like the server is reaching exactly the wrong conclusion (this is a
new host) rather than the right one (there was a communications problem on
the prior contact).  If it were a new host, shouldn't the sequence number
be near 0?


On Fri, Aug 8, 2014 at 10:19 AM, Richard Haselgrove 
r.haselgr...@btopenworld.commailto:r.haselgr...@btopenworld.com wrote:

 In probably the fullest message board description on the last circuit
 round this merry-go-round,

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

 we observed a number of occasions where client message logs contained
 lines like

 22.05.2013 13:45:56 | SETI@homemailto:SETI@home | Not sending work - last 
 request too
 recent: 76 sec

 at times not unadjacent to the times when abandonments were recorded for
 user tasks. That led us into 'clutching at straws' mode: was another
 computer sending out-of-sequence RPC requests with duplicate credentials?
 (the users swore not). Were entire RPC requests being delayed in a transit
 queue and arriving out of sequence? Unlikely. Was the server receiving the
 RPCs in a timely fashion, but processing them out of order - perhaps
 delaying one because of incomplete packets?

 And so on. Most of this was happening before the server move to CoLo, when
 the SETI data line was heavily congested - we thought the problem might
 diminish with the higher-quality internet service at the bottom of the
 hill, and so it seems to have transpired. But doesn't help our friends
 outwith the continental USA.

 Incidentally, I reported seeing one 'last request too recent' in my own
 logs, and traced it back to an internet time update changing the computer
 clock. But I didn't suffer any abandoned tasks in that event.

  --
  *From:* Eric J Korpela 
 korp...@ssl.berkeley.edumailto:korp...@ssl.berkeley.edu
 *To:* Richard Haselgrove 
 r.haselgr...@btopenworld.commailto:r.haselgr...@btopenworld.com
 *Cc:* boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu 
 boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
 *Sent:* Friday, 8 August 2014, 17:47

 *Subject:* Re: [boinc_dev] astropulse robustness / abandonned tasks

 His host seems to be losing track of RPC sequence numbers.  Loss of cached
 writes on restart?

 2014-08-08 07:13:53.1883 [PID=28339]  [HOST#6960982] [USER#8522684] RPC
 seqno 59642 less than expected 59643; creating new host
 2014-08-08 07:13:53.1896 [PID=28339]  [HOST#6960982] [USER#8522684] Found
 similar existing host for this user - assigned.
 2014-08-08 07:13:53.1932 [PID=28339] [CRITICAL]  [HOST#6960982]
 [RESULT#3670788988] [WU#1562416658] changed CPID: marking in-progress
 result 03se08ad.16169.8252.438086664200.12.220_0 as client error!
 2014-08-08 07:13:53.1932 [PID=28339]  Request: [USER#8522684]
 [HOST#6960982] [IP 41.79.224.134] client 7.2.42



 On Fri, Aug 8, 2014 at 9:17 AM, Richard Haselgrove 
 r.haselgr...@btopenworld.commailto:r.haselgr...@btopenworld.com wrote

Re: [boinc_dev] astropulse robustness / abandonned tasks

[McLeod, John]

New CPID is supposed to mean a new installation.  Running a task on a device it 
was not assigned to is not allowed (this was used as a way to cheat the system 
in SETI Classis).

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Christian Beer
Sent: Friday, August 08, 2014 2:05 PM
To: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] astropulse robustness / abandonned tasks

I'll start from here and say that we have a similar problem with
abandoned tasks at RNA World. It happens from time to time and
it's difficult to diagnose.

What I see on the server side is this:

 2014-07-30 07:47:51.6412 [PID=12018] [CRITICAL]  [HOST#29863] 
 [RESULT#14926926] [WU#6331554] changed CPID: marking in-progress result 
 cms_GA... as client error!
 2014-07-30 08:48:28.8226 [PID=19897] [CRITICAL]   [HOST#29863] 
 [RESULT#14926926] [WU#6331554] already got result, at 30-Jul-2014 07:47:51 

I still have no explanation why the result is marked as client error if
the CPID changes. From the second messsage it seems that the result was
still running.

Regards
Christian

Am 08.08.2014 10:41, schrieb Luc A. Germain:
 Hi,
 Two things:
 1) A suggestion here for you develloppers ;-) As atropulse tasks take
 some time to complete they are more prone to power failure as we have
 in the third world. When it happens most of the time the task restarts
 computing from start (this is even more frustrating when the task
 reaches near completion). Could it be possible to introduce regular
 checkpoints by saving intermediate data, or work files, where the task
 computing could restart from, saving so a lot of computing time ? Maybe
 this could be an option in the user profile as I guess not everyone
 needs this.
 
 2) Two days ago I sent a message about abandonned tasks. Since, all my
 computing goes to the garbage bin as they are not taken into account.
 Which procedure should/could I try to solve this problem ? Could
 uninstalling/reinstalling the application from my computers be a
 solution? Should I wait till the problem solves by itself (and would
 this not take ages) ?
 
 An answer would be highly appreciated.
 
 Best regards and thanks for your work,
 Luc
 ___
 boinc_dev mailing list
 boinc_dev@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.

___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] [boinc_projects] max_concurrent at a project scope

[McLeod, John]

Isn't each section either GPU or CPU?

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Stephen Maclagan
Sent: Saturday, July 26, 2014 5:30 AM
To: David Anderson; BOINC Developers Mailing List; Valter Cavecchia
Subject: Re: [boinc_dev] [boinc_projects] max_concurrent at a project scope

Very good, but it doesn't go far enough, you can't limit what just the CPU 
runs, ie the app level, app_version level or overall,
 
you can limit overall the tasks an app name can run,  ie four, and have two run 
on the GPU and two on the CPU,
once the GPU tasks of that app name run out, you end up running more tasks on 
the CPU than you intended.
 
Claggy
 
 Date: Fri, 25 Jul 2014 16:09:02 -0700
 From: da...@ssl.berkeley.edu
 To: boinc_dev@ssl.berkeley.edu; val...@science.unitn.it
 Subject: Re: [boinc_dev] [boinc_projects] max_concurrent at a project scope
 
 I added this feature; see
 http://boinc.berkeley.edu/wiki/Client_configuration#Application_configuration
 
 This will be available in the 7.6 client release.
 
 -- David
 
 On 24-Jul-2014 7:46 AM, Valter Cavecchia wrote:
  Dear all,
 
  I think that a max_concurrent tag at a project scope (not just for apps) 
  could be
  a useful thing to implement, useful for projects with a lot of 
  'subprojects'. As an
  example, I have the following situation in Primegrid: I have a Haswell I7 
  with
  hyper-threading enabled (4 cores, 8 threads) and want to run LLR 
  applications (there
  are many of them) which use AVX, so the optimal setup will be either 
  disable HT or
  force a maximum of four applications of that kind running at the same time, 
  but I
  also need some extra cpu threads for helping gpus. However there isn't yet 
  an easy
  way to tell Boinc just to do this, ie: run a maximum of 4 primegrid 
  applications.
 
  Any comments about?
  Thanks anyone in advance,
 valter
 
 
  ___
  boinc_projects mailing list
  boinc_proje...@ssl.berkeley.edu
  http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_projects
  To unsubscribe, visit the above URL and
  (near bottom of page) enter your email address.
 ___
 boinc_dev mailing list
 boinc_dev@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.
  
___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

[boinc_dev] delete spammers

[McLeod, John]

New users that are having a difficult time getting started will not have any 
tasks assigned, and will have posts in the help area.  This will last for 
anywhere from a few hours to a few weeks depending on the nature of the problem 
and the time available for trouble shooting.  I hope that these users will not 
be swept up in a cull of spammer users as it might turn them off from BOINC.

I am trying to remember the moderator UI, so this may not be a good idea, but 
anyway:  How about a recommend delete button available to the moderators that 
would send a message to the project administrator(s) that do have the ability 
to actually delete posts.  The only way to allow the moderators to delete posts 
would be to have a voting mechanism and have it be unanimous after x days (or 
all current moderators have cast a delete vote).
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] Creditnew for mt apps

[McLeod, John]

Yes, it is intentional.  They should be using more cores, but for 
proportionally less time.  (8 CPU cores for 1/8th of the time that a single CPU 
core can do the task.)

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of yoyo
Sent: Monday, June 30, 2014 2:11 PM
To: BOINC Developers Mailing List; BOINC Projects
Subject: [boinc_dev] Creditnew for mt apps

Hello,

there is a discussion in YAFU
(http://yafu.myfirewall.org/yafu/forum_thread.php?id=160) where users
complains, that computer which uses more cores to finish a work unit
gets the same credits as computer which are using less cores.
Is this the intention of creditnew or a bug?

YAFU runs the stock Boinc server- and wrapper code together with the
sample_bitwise_validator, sample_assimilator and quorum=1.

kind regards,
yoyo
___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] Creditnew for mt apps

[McLeod, John]

For 2 tasks from the same WU, two computers should be getting the same credit 
whether they are running 1 core or 8 cores.  The single core computer will just 
take longer to get it done.

If both computers have 8 cores, and one is running 1 8 core task at a time, and 
one is running 8 1 core task at a time, and they are otherwise similar, I would 
expect that the credit per hour is similar.

-Original Message-
From: yoyo [mailto:y...@mailueberfall.de] 
Sent: Monday, June 30, 2014 2:33 PM
To: McLeod, John; BOINC Developers Mailing List; BOINC Projects
Subject: Re: [boinc_dev] Creditnew for mt apps

But the users claims, that the systems gets the same credits per hour
even if they use different amount of cores.
 
McLeod, John schrieb:
 Yes, it is intentional.  They should be using more cores, but for 
 proportionally less time.  (8 CPU cores for 1/8th of the time that a single 
 CPU core can do the task.)

 -Original Message-
 From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of yoyo
 Sent: Monday, June 30, 2014 2:11 PM
 To: BOINC Developers Mailing List; BOINC Projects
 Subject: [boinc_dev] Creditnew for mt apps

 Hello,

 there is a discussion in YAFU
 (http://yafu.myfirewall.org/yafu/forum_thread.php?id=160) where users
 complains, that computer which uses more cores to finish a work unit
 gets the same credits as computer which are using less cores.
 Is this the intention of creditnew or a bug?

 YAFU runs the stock Boinc server- and wrapper code together with the
 sample_bitwise_validator, sample_assimilator and quorum=1.

 kind regards,
 yoyo
 ___
 boinc_dev mailing list
 boinc_dev@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.


___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] Boinc and shared dynamic libraries

[McLeod, John]

End of support means no more patches for any reason -- including security 
patches.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Jon 
Sonntag
Sent: Wednesday, June 18, 2014 5:07 PM
To: Jussi Lahtinen
Cc: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] Boinc and shared dynamic libraries

It is hardly fair to combine all the Linux versions and compare that to
each individual Windows version. If you want to use the combined total and
call it Linux then you really need to add all the windows versions
together and just have Windows. XP is no longer supported by Microsoft,
but I can't think of anyone I know who ever called Microsoft for support
for XP.


On Wed, Jun 18, 2014 at 3:16 PM, Jussi Lahtinen jussi.lahti...@gmail.com
wrote:

   1) There is Windows world (and, BTW, it outnumbers Linux ones both by
  number of hosts and by credit earned in BOINC
  http://boincstats.com/en/stats/-1/host/breakdown/os/  ) to be
 considered.
 

 Take Windows XP (and other dead operating systems) from the list and linux
 is pretty much number one.


 Jussi
 ___
 boinc_dev mailing list
 boinc_dev@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.

___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] EXIT_TIME_LIMIT_EXCEEDED (sorry, yes me again, but please read)

[McLeod, John]

The reason RAC was not used was because of the delay in granting credit.  
However, if we remember that RAC is long term, then it makes more sense.  If we 
use RAC as the estimate, then we should also have the client attempt to contact 
each of the servers for an update of RAC occasionally, but it would not have to 
be very often - once a week or so would probably suffice.  If it had been more 
than a week since the last connection, it would be time to try again.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Richard Haselgrove
Sent: Wednesday, June 11, 2014 4:23 PM
To: Eric J Korpela; David Anderson
Cc: boinc_dev@ssl.berkeley.edu; Josef W. Segur
Subject: Re: [boinc_dev] EXIT_TIME_LIMIT_EXCEEDED (sorry, yes me again, but 
please read)

That one made it as far as the planning document, but no further:

http://boinc.berkeley.edu/trac/wiki/ClientSchedOctTen#Proposal:credit-drivenscheduling


The surrogate, REC, is essentially speed * time, or back to square one.




 From: Eric J Korpela korp...@ssl.berkeley.edu
To: David Anderson da...@ssl.berkeley.edu 
Cc: Richard Haselgrove r.haselgr...@btopenworld.com; Josef W. Segur 
jse...@westelcom.com; boinc_dev@ssl.berkeley.edu 
boinc_dev@ssl.berkeley.edu 
Sent: Wednesday, 11 June 2014, 21:03
Subject: Re: [boinc_dev] EXIT_TIME_LIMIT_EXCEEDED (sorry, yes me again, but 
please read)
 


Another possibility that came to me years ago would be to use RAC rather than 
estimated duration to compute the resource allocation on the client side.  
That way on a machine running two projects with equal resource share would end 
up spending more time running the one with lower granted credit per unit work. 
 That would encourage projects not to over grant (they would lose resources) 
or under grant (they would lose volunteers).




On Tue, Jun 10, 2014 at 1:03 PM, Eric J Korpela korp...@ssl.berkeley.edu 
wrote:


I haven't thought about it in a while.   I had come up with a stable system 
that would but it wasn't simple and it also required projects to voluntarily 
participate.  Therefore it wouldn't have worked.

The only thought I've had recently is to have a calibration plan class that 
has a non-SIMD non-threaded unoptimized CPU-only app_version that gets sent 
out once out of every N (~100,000) results. This (as the least efficient 
app_version) could set the pfc_scale.  Again, it would require project 
participation, so it wouldn't work.

So I spend most of my time trying not to think about it.





On Tue, Jun 10, 2014 at 12:12 PM, David Anderson da...@ssl.berkeley.edu 
wrote:

Are you saying we're taking the wrong approach?
Any other suggestions?


On 10-Jun-2014 11:51 AM, Eric J Korpela wrote:

 For credit purposes, the standard is peak FLOPS,
 i.e. we give credit for what the device could do,
 rather than what it actually did.
 Among other things, this encourages projects to develop more efficient 
apps.

It does the opposite because many projects care more about attracting 
volunteers
than they do about efficient computation.

First: Per second of run time,  a host gets the same credit for a 
non-optimized
stock app as it does for an optimized stock app.  There's no benefit to the
volunteer to go to a project with optimized apps.  In fact there's a 
benefit for
users to compile an optimized app for use at a non-optimized project where 
their
credit will be higher.  Every time we optimize SETI@home we get bombarded 
by users
of non-stock optimized apps get angry because their RAC goes down.  That 
makes it a
disincentive to optimize.

Second:  This method encourages projects to create separate apps for GPUs 
rather
than separate app_versions.  Because GPUs obtain nowhere near their 
advertised rates
for real code, a separate GPU app can earn 20 to 100x the credit of a GPU
app_version of an app that also has CPU app_versions.

Third: It encourages projects to not use the BOINC credit granting 
mechanisms.  To
compete with projects that have GPU only apps, some projects grant 
outrageous credit
for everything.





On Tue, Jun 10, 2014 at 11:34 AM, David Anderson da...@ssl.berkeley.edu

mailto:da...@ssl.berkeley.edu wrote:

    For credit purposes, the standard is peak FLOPS,
    i.e. we give credit for what the device could do,
    rather than what it actually did.
    Among other things, this encourages projects to develop more efficient 
apps.

    Currently we're not measuring this well for x86 CPUs,
    since our Whetstone benchmark isn't optimized.
    Ideally the BOINC client should include variants for the most common
    CPU features, as we do for ARM.

    -- D


    On 10-Jun-2014 2:09 AM, Richard Haselgrove wrote:

        Before anybody leaps into making any changes on the basis of that 
observation, I
        think we ought to pause and consider why we have a benchmark, and 
what we
        use it for.

        I'd suggest that in an ideal world, we would be measuring the 

Re: [boinc_dev] EXIT_TIME_LIMIT_EXCEEDED (sorry, yes me again, but please read)

[McLeod, John]

The attempt is to count time * speed

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
William Stilte
Sent: Thursday, June 12, 2014 1:08 PM
To: David Anderson
Cc: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] EXIT_TIME_LIMIT_EXCEEDED (sorry, yes me again, but 
please read)

Considering that we do not count flops but time...

Retreating to semantics?

And I've got a few cents to add on using RAC but I've run out of time to
share that particular balloon popper.


2014-06-12 18:45 GMT+02:00 David Anderson da...@ssl.berkeley.edu:

 To reiterate (from discussions several years ago):

 - Resource shares apply to a host's total FLOPS, not time on particular
 devices.
   This is the appropriate semantics.

 - We chose not to use RAC as a basis for scheduling because
   a) there can be long and unpredictable delays in granting credit,
  because of replication
   b) jobs may not be granted credit for a variety of reasons,
  in which case the client would (undesirably)
  keep running jobs for that project.

 -- D

 ___
 boinc_dev mailing list
 boinc_dev@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.

___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] EXIT_TIME_LIMIT_EXCEEDED (sorry, yes me again, but please read)

[McLeod, John]

It is psychological, and both sides have a point.

I have a few million credits that I have earned over a decade.  If suddenly, it 
is a thousand times easier to earn credits, then I will be annoyed because the 
newcomers will be able to appear to match the work I have done in the past 
substantially more easily that it was for me to accumulate them in the first 
place.

The other side is that I have been using an optimized application, and now that 
the base application is optimized, I am suddenly earning less.


-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Raistmer the Sorcerer
Sent: Wednesday, June 11, 2014 11:53 AM
To: Charles Elliott
Cc: boinc_dev@ssl.berkeley.edu; 'Richard Haselgrove'; 'Josef W. Segur'
Subject: Re: [boinc_dev] EXIT_TIME_LIMIT_EXCEEDED (sorry, yes me again, but 
please read)

 Instead of real money these credits cost absolutely nothing. They can't cost 
less then. But if one gives less number of points no matter that those 
points cost nothing in the human nature to experience dissatisfaction feeling.
It's not economics, it's psychology.


Wed, 11 Jun 2014 09:57:09 -0400 от Charles Elliott elliott...@comcast.net:
Wasn't the fundamental problem being attacked the constant credit inflation 
due to architectural improvements in CPUs and GPUs?  It is like inflation; the 
value of credits in the bank, i.e., in the database become worth less due 
factors people cannot control.  I don't know of any way of doing this except 
by reducing the credit allocated per FLOP.

Charles Elliott

 -Original Message-
 From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf
 Of Raistmer the Sorcerer
 Sent: Tuesday, June 10, 2014 3:52 PM
 To: David Anderson
 Cc: boinc_dev@ssl.berkeley.edu; Richard Haselgrove; Josef W. Segur
 Subject: Re: [boinc_dev] EXIT_TIME_LIMIT_EXCEEDED (sorry, yes me again,
 but please read)
 
  Current approach to credit accounting is definitely wrong. Whole SETI
 forums discuss how much it's wrong many months already. It's almost
 impossible to avoid this topic if one ever come there.
 
 Some suggestions could be:
 To recall why those credits are needed for BOINC at all. Correct answer
 is to ATTRACT participanst exploiting HUMAN competitive nature. Not to
 measure anything, it's social engineering first of all!
 
 From this approach some conclusions could be done.
 It's in human nature to get angry being less paid. Hence - NEVER
 deflate credits ! Inflation - no probs, peoples like to get more, but
 NEVER decrease amount of granting by any reason.
 
 And that's exactly whit we get with current system.
 We working hard to optimize SETI code. Then we release app. All users
 who installed it are happy - it works faster, they get MORE credits
 with the SAME hardware.
 Then, being interesting in project we trying to incorporate found
 optimizations in project stock app. Finally new stockj app released...
 And whole mess begins. Users of stock app notice nothing - their credit
 remains the same. But THE MOST active users, that going into troubles
 to install opt apps, to go to anonymous platform and so on (let say
 biggest project fans) instantly get pissed off. Their RAC starts to
 drop ! WHY?! Because some idiots decided to improve stock app??! And
 flame wars on forums begins.
 All this thing absolutely not about how scientifically correct you guys
 account for FLOPS being done, it's about keeping PARTICIPANTS who
 donate resources HAPPY. And current CreditScrew gives absolutely
 diametral feelings both to participants AND developers.
 One would say quite impressive outcome...
 
 What could be suggested for further discussion: try to calibrate not on
 stock app but on fastest app (usually this will mean anonymous platform
 app, btw) correctly computing app in the project.
 That they even if some credits will be decreased (though additional
 considerations should be done to avoid ANY drop in RAC because of any
 software replacement in stock) they would be decreased for stock users.
 This would
 1) stimulate users to install fastest app.
 2) stimulate project to incorporate fastest algorithms in their stock
 app.
 
 
 
 Tue, 10 Jun 2014 12:12:24 -0700 от David Anderson
  da...@ssl.berkeley.edu :
 Are you saying we're taking the wrong approach?
 Any other suggestions?
 
 On 10-Jun-2014 11:51 AM, Eric J Korpela wrote:
   For credit purposes, the standard is peak FLOPS,
   i.e. we give credit for what the device could do,
   rather than what it actually did.
   Among other things, this encourages projects to develop more
 efficient apps.
 
  It does the opposite because many projects care more about
 attracting volunteers
  than they do about efficient computation.
 
  First: Per second of run time,  a host gets the same credit for a
 non-optimized
  stock app as it does for an optimized stock app.  There's no benefit
 to the
  volunteer to go to a project with optimized apps.  In fact there's a
 benefit for
  

Re: [boinc_dev] EXIT_TIME_LIMIT_EXCEEDED (sorry, yes me again, but please read)

[McLeod, John]

A possibility that will work itself out eventually:

If a machine has exceeded its computation bound for an application version / 
plan class for all tasks so far, then the next task for that application 
version / plan class gets its computation bound multiplied by 2 for the next 
task for that application version / plan class - until it succeeds in actually 
completing one.  That one would be used as the baseline average computation 
length for that application version / plan class.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Josef 
W. Segur
Sent: Wednesday, June 11, 2014 11:38 AM
To: David Anderson
Cc: boinc_dev@ssl.berkeley.edu; Richard Haselgrove
Subject: Re: [boinc_dev] EXIT_TIME_LIMIT_EXCEEDED (sorry, yes me again, but 
please read)

A couple of ideas specifically related to EXIT_TIME_LIMIT_EXCEEDED:

1. The BOINC x86 benchmark based on the Whetstone test has typically yielded a 
value which is roughly 90% of the CPU clock rate. In terms of a conservative 
estimate to be used prior to having usable statistics about how the CPU 
performs on a specific app version, it may be sensible to use clock rate rather 
than p_fpops. That would not take into account the possibility that hardware or 
OS may change the clock rate, but neither does the benchmark.

2. When the scheduler assigns a task to a host, it could multiply the 
rsc_fpops_bound by 5 or 10 if the host does not yet have sufficient results for 
the app version.
-- 
  Joe



On Tue, 10 Jun 2014 14:34:57 -0400, David Anderson da...@ssl.berkeley.edu 
wrote:

 For credit purposes, the standard is peak FLOPS,
 i.e. we give credit for what the device could do,
 rather than what it actually did.
 Among other things, this encourages projects to develop more efficient apps.

 Currently we're not measuring this well for x86 CPUs,
 since our Whetstone benchmark isn't optimized.
 Ideally the BOINC client should include variants for the most common
 CPU features, as we do for ARM.

 -- D

 On 10-Jun-2014 2:09 AM, Richard Haselgrove wrote:
 Before anybody leaps into making any changes on the basis of that 
 observation, I
 think we ought to pause and consider why we have a benchmark, and what we 
 use it for.

 I'd suggest that in an ideal world, we would be measuring the actual running 
 speed
 of (each project's) science applications on that particular host, 
 optimisations and
 all. We gradually do this through the runtime averages anyway, but it's hard 
 to
 gather a priori data on a new host.

 Instead of (initially) measuring science application performance, we measure
 hardware performance as a surrogate. We now have (at least) three ways of 
 doing that:

 x86: minimum, most conservative, estimate, no optimisations allowed for.
 Android: allows for optimised hardware pathways with vfp or neon, but 
 doesn't relate
 back to science app capability.
 GPU: maximum theoretical 'peak flops', calculated from card parameters, then 
 scaled
 back by rule of thumb.

 Maybe we should standardise on just one standard?

 
 
 *From:* Richard Haselgrove r.haselgr...@btopenworld.com
 *To:* Josef W. Segur jse...@westelcom.com; David Anderson
 da...@ssl.berkeley.edu
 *Cc:* boinc_dev@ssl.berkeley.edu boinc_dev@ssl.berkeley.edu
 *Sent:* Tuesday, 10 June 2014, 9:37
 *Subject:* Re: [boinc_dev] EXIT_TIME_LIMIT_EXCEEDED (sorry, yes me 
 again, but
 please read)

 
 http://boinc.berkeley.edu/gitweb/?p=boinc-v2.git;a=commit;h=7b2ca9e787a204f2a57f390bc7249bb7f9997fea

  
   From: Josef W. Segur jse...@westelcom.com 
 mailto:jse...@westelcom.com
  To: David Anderson da...@ssl.berkeley.edu 
 mailto:da...@ssl.berkeley.edu
  Cc: boinc_dev@ssl.berkeley.edu mailto:boinc_dev@ssl.berkeley.edu
 boinc_dev@ssl.berkeley.edu mailto:boinc_dev@ssl.berkeley.edu; Eric J 
 Korpela
 korp...@ssl.berkeley.edu mailto:korp...@ssl.berkeley.edu; Richard 
 Haselgrove
 r.haselgr...@btopenworld.com mailto:r.haselgr...@btopenworld.com
  Sent: Tuesday, 10 June 2014, 2:19
  Subject: Re: [boinc_dev] EXIT_TIME_LIMIT_EXCEEDED (sorry, yes me 
 again, but
 please read)
  
  
  Consider Richard's observation:
  
   It appears that the Android Whetstone benchmark used in the 
 BOINC
 client has
   separate code paths for ARM, vfp, and NEON processors: a vfp or 
 NEON
 processor
   will report that it is significantly faster than a 
 plain-vanilla ARM.
  
  If that is so, it distinctly differs from the x86 Whetstone which 
 never uses
 SIMD, and is truly conservative as you would want for 3).
  --
 Joe
  
  
  
  On Mon, 09 Jun 2014 16:43:17 -0400, David Anderson 
 da...@ssl.berkeley.edu
 

Re: [boinc_dev] WINBUILD: Minimum supported VS is now VS 2010

[McLeod, John]

If you look at the Microsoft implementation of string, it has an explicit 
conversion to char * allowed.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Eric J 
Korpela
Sent: Thursday, May 22, 2014 11:19 AM
To: Jord van der Elst
Cc: Rom Walton; BOINC Dev Mailing List
Subject: Re: [boinc_dev] WINBUILD: Minimum supported VS is now VS 2010

Nothing quite like spending a few hundred dollars to compile free software,
is there?  It's not clear from Rom's message whether the incompatibility is
in the project files (or that it's too much work to maintain the old
project files), or whether its a newer visual C++ version that is
necessary.  If it's just the maintenence of old project files and required
libraries, a volunteer could do it.

As a means of relaxing, I've been slowly working on cross compiling with
mingw32/64 on Linux and Cygwin, but, of course, there's no clear
indications of what features are necessary in wxWidgets to compile
boincmgr.  At least I have the libraries and client compiling.  Of course,
MSVC++ happily and silently compiles things that aren't legal on gcc (like
implicit conversions from string to char *, what's that about?), so there
are a hunderd things to fix to get it working.


On Thu, May 22, 2014 at 7:54 AM, Jord van der Elst els...@gmail.com wrote:

 WINBUILD: Minimum supported VS is now VS 2010

 So then that means that someone has to retest and rewrite all and
 everything of
 http://boinc.berkeley.edu/trac/wiki/CompileClient#Windows as the
 compilers the page is written for are VS 2005 (Express) and 2008.

 And what VS, full VS or is Express also an option?
 Or is Express still not capable of compiling 64bit applications?

 Thanks,

 -- Jord van der Elst.
 ___
 boinc_dev mailing list
 boinc_dev@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.

___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] [boinc_projects] Temporarily failed download

[McLeod, John]

It is the idea of BOINC, but exactly how to split the data, exactly how to 
process the data, and exactly how to recombine or use the results is specific 
to each project.  Therefore, you have to write some custom code on the server 
side for splitting, validation, and storing results, and some custom client 
code to do the processing.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of uday 
kumar
Sent: Thursday, May 15, 2014 8:52 PM
To: Christian Beer; boinc_proje...@ssl.berkeley.edu; 
boinc_dev@ssl.berkeley.edu; Rebirther
Subject: Re: [boinc_dev] [boinc_projects] Temporarily failed download

Hi,

Now i am able to upload data from client to server after processing. But i
have a doubt. My input will be a huge file and i want it to be split up
into multiple parts and executed by clients. And also results of these
small inputs are sent back to server. The server should assimilate all
these outputs to get output for the actual input file.

This is supposed to be the default functionality of BOINC application
right. This functionality is provided by BOINC wrapper or should we
implement in our own application?


On Thu, May 15, 2014 at 1:39 AM, Christian Beer djangof...@gmx.net wrote:

 Is the open_name in your output template the same name your app produces
 as result?

 Usually the absent output file message is due to wrong logical names or
 a bug in the application that does not create an output file. Are the
 runtimes of the tasks in a range you would expect? If they are very
 short. This could also point to an exception beeing thrown or a
 segmentation violation.

 Regards
 Christian

 Am 09.05.2014 15:42, schrieb uday kumar:
  Hi,
 
  The download is successful and client is computing for tasks,
  But i am getting computation error.
 
  When i check in BOINCmanager logs i found the following error msgs.
 
  5/9/2014 7:05:50 PM | velveth | Finished download of
  velveth_app_1399642460_0
  5/9/2014 7:05:50 PM | velveth | Starting task velveth_app_1399642460_0_0
  5/9/2014 7:05:54 PM | velveth | Computation for task
  velveth_app_1399642460_0_0 finished
  5/9/2014 7:05:54 PM | velveth | Output file velveth_app_1399642460_0_0_0
  for task velveth_app_1399642460_0_0 absent
  5/9/2014 7:05:54 PM | velveth | Output file velveth_app_1399642460_0_0_1
  for task velveth_app_1399642460_0_0 absent
  5/9/2014 7:05:54 PM | velveth | Output file velveth_app_1399642460_0_0_2
  for task velveth_app_1399642460_0_0 absent
  5/9/2014 7:07:55 PM | velveth | Computation for task
  velveth_app_1399642460_16_0 finished
  5/9/2014 7:07:55 PM | velveth | Output file
  velveth_app_1399642460_16_0_0 for task velveth_app_1399642460_16_0 absent
  5/9/2014 7:07:55 PM | velveth | Output file
  velveth_app_1399642460_16_0_1 for task velveth_app_1399642460_16_0 absent
  5/9/2014 7:07:55 PM | velveth | Output file
  velveth_app_1399642460_16_0_2 for task velveth_app_1399642460_16_0 absent
 
 
  Can you please guide me how can i debug for the exact error. This is for
  all the tasks sent by the server.
 
 
 
  On Wed, May 7, 2014 at 4:05 AM, uday kumar uday@gmail.com
  mailto:uday@gmail.com wrote:
 
  Hi,
 
  Thanks Christian and Reb,
 
  I think the download is successful. But I am unable to understand
  the current situation of my project.
  Will update you once i understand whats happening.
 
 
  On Tue, May 6, 2014 at 4:18 PM, Christian Beer djangof...@gmx.net
  mailto:djangof...@gmx.net wrote:
 
  You should really enable the file_xfer_debug, http_debug and
  http_xfer_debug logflags on the client to see where it is
  failing. The
  task is marked as download failed if one of the files for the
  task or
  the application could not be downloaded. Maybe you also have a
  problem
  with your application version.
 
  Please test every contnet of donwload_url of your
  client_state.xml in a
  browser and see if you can download it that way. If not you will
  see an
  error in your browser and know where to look next.
 
  Regards
  Christian
 
  Am 06.05.2014 07:39, schrieb uday kumar:
   I have checked in client_state.xml and delete all the old
  workunits and
   unistalled and installed client software.
   My boincmanager log shows as finshed download of the workunit,
  but task
   page shows download failed.
  
  
   On Tue, May 6, 2014 at 11:07 AM, Christian Beer
  djangof...@gmx.net mailto:djangof...@gmx.net wrote:
  
   Changes to download_url in config.xml are only effective  for
 new
   workunits. Old ones will still have the wrong url. You need
  to create
   new jobs and test again. Check the download_url in your
  client_state.xml
   because that is where the client is trying to 

Re: [boinc_dev] Client configuration

[McLeod, John]

The projects write their data into a sub directory of the data_dir_path.  You 
can't change this.

If you want to move the data path to someplace else:
1)  Stop BOINC
2)  Move the entire directory tree of data_dir_path to the new location (and 
it must NOT be a windows protected directory such as Program Files
3)  Re-install BOINC (or hand edit the config files and possibly registry, if 
you are that brave).  Make certain to point the directory to the new place.
4)  Start BOINC

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Jussi 
Lahtinen
Sent: Thursday, May 08, 2014 9:43 AM
To: boinc_dev@ssl.berkeley.edu
Subject: [boinc_dev] Client configuration

I expected this:
data_dirpath/data_dir Use the given directory as the BOINC data
directory (default: current directory).

To mean path where boinc writes project related data. Apparently no,
because I lost all configurations (I assume that is because the path is
used to find configs also).

So, how do I change where project data is written?


Jussi
___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] Client configuration

[McLeod, John]

Same general principles apply, but I do not believe that Linux has any 
directories that are as thoroughly locked down as some of the Windows 
directories.

From: Jussi Lahtinen [mailto:jussi.lahti...@gmail.com]
Sent: Thursday, May 08, 2014 9:56 AM
To: McLeod, John
Cc: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] Client configuration

Oh, sorry. I'm on Linux. But I think I got it.

Jussi

On Thu, May 8, 2014 at 4:49 PM, McLeod, John 
john.mcl...@sap.commailto:john.mcl...@sap.com wrote:
The projects write their data into a sub directory of the data_dir_path.  You 
can't change this.

If you want to move the data path to someplace else:
1)  Stop BOINC
2)  Move the entire directory tree of data_dir_path to the new location (and 
it must NOT be a windows protected directory such as Program Files
3)  Re-install BOINC (or hand edit the config files and possibly registry, if 
you are that brave).  Make certain to point the directory to the new place.
4)  Start BOINC

-Original Message-
From: boinc_dev 
[mailto:boinc_dev-boun...@ssl.berkeley.edumailto:boinc_dev-boun...@ssl.berkeley.edu]
 On Behalf Of Jussi Lahtinen
Sent: Thursday, May 08, 2014 9:43 AM
To: boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
Subject: [boinc_dev] Client configuration

I expected this:
data_dirpath/data_dir Use the given directory as the BOINC data
directory (default: current directory).

To mean path where boinc writes project related data. Apparently no,
because I lost all configurations (I assume that is because the path is
used to find configs also).

So, how do I change where project data is written?


Jussi
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edumailto:boinc_dev@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.

___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] add fraction_done_exact tinyint not null

[McLeod, John]

That looks reasonable.  TinyInt is a single bit.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Henri 
Heinonen
Sent: Monday, May 05, 2014 4:55 PM
To: BOINC Developers Mailing List
Subject: [boinc_dev] add fraction_done_exact tinyint not null

I got this message after upgrading the server:

performing update update_5_3_2014
Doing query:
alter table app
add fraction_done_exact tinyint not null

Success.
All done.
Run `bin/start' to restart the project.


Henri.
___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] Heartbleed bug with OpenSSL

[McLeod, John]

Maliciously modified in some way, yes.  Or have the port open for incoming 
traffic by mistake.

-Original Message-
From: boinc_alpha [mailto:boinc_alpha-boun...@ssl.berkeley.edu] On Behalf Of 
Rom Walton
Sent: Tuesday, April 15, 2014 11:38 AM
To: Oliver Bock; TarotApprentice
Cc: boinc_dev@ssl.berkeley.edu; boinc_alpha email list
Subject: Re: [boinc_alpha] [boinc_dev] Heartbleed bug with OpenSSL

Okay, I stand corrected.  Had to go re-read the advisory.

In order to exploit the client wouldn't a project server using SSL have
to be compromised?

- Rom

-Original Message-
From: Oliver Bock [mailto:oliver.b...@aei.mpg.de] 
Sent: Tuesday, April 15, 2014 10:57 AM
To: Rom Walton; TarotApprentice
Cc: boinc_dev@ssl.berkeley.edu; boinc_alpha email list
Subject: Re: [boinc_dev] Heartbleed bug with OpenSSL

On 15/04/14 16:38 , Rom Walton wrote:
 Since the client doesn't use SSL in a server-role it doesn't need to 
 be backported to older branches.

Not sure I understand you correctly but Heartbleed is a bi-directional
issue. So yes, client libs need to be updated to protect the client - as
you already did for Windows and OSX.

Best,
Oliver



___
boinc_alpha mailing list
boinc_al...@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_alpha
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] Heartbleed bug with OpenSSL

[McLeod, John]

If the client uses the native SSL implementation, Windows will not be a problem 
as that implementation does not have this issue.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Oliver 
Bock
Sent: Tuesday, April 15, 2014 8:21 AM
To: TarotApprentice
Cc: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] Heartbleed bug with OpenSSL

On 15/04/14 13:56 , TarotApprentice wrote:
 Apart from all the hype I presume BOINC will need to come bundled
 with a patched OpenSSL and the projects need to update to a later
 version incorporating a patched OpenSSL. Any advice from the BOINC
 developers?

Charlie already updated OpenSSL bundled with the OSX client. Updates for
the Windows and Linux clients should hopefully be in the pipeline (if
affected).

Projects need to check which OpenSSL version is installed on their
servers. Many, like Einstein@Home, should still be running 0.98 which
isn't affected. If you run any of the affected versions, update/upgrade
to 1.0.1g or equivalent (Debian for instance ships a patched version of
1.0.1f for wheezy). If you used an affected version you should get a new
SSL certificate (key) as you should consider it as being compromised.
Unfortunately, that means all previous encrypted data transfers should
also be considered compromised which in turn means your volunteers
should be notified to change their passwords, obviously after you
renewed your certificate keys.


HTH,
Oliver

___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] new GUI RPC for getting completed /reported tasks

[McLeod, John]

What are your queue settings for both Maintain enough tasks for and up to an 
additional?

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Charles Elliott
Sent: Wednesday, February 19, 2014 8:34 PM
To: 'Richard Haselgrove'; 'Nicolás Alvarez'; 'William Stilte'
Cc: 'BOINC Developers Mailing List'
Subject: Re: [boinc_dev] new GUI RPC for getting completed /reported tasks

'pushing' an unreasonable volume of work does not even begin to describe
the situation with Einnstein@Home.  SETI@Home was down on a Thursday a few
weeks ago, when Tuesdays are the usual day 
for maintenance.  At 5:00 PM EST it did not look like they were going to get
back up, and I was out of work units for the GPUs.  So I set the default
resource share for E@H at 1E-5 and no CPU work units.  
Unfortunately, and this is my mistake, the Home resource share was still
at about 5% with both
CPU and GPU WUs allowed, and my computers were set to the Home venue.  On
two computers I unsuspended E@H and allowed more work.  Almost
instantaneously, I had been allocated over 400 work units on both computers,
literally weeks of non-stop computation. That is excessive and unreasonable
by any standard.  Then, of course, by about 11:00 PM EST S@H was up and
running.  Since E@H's work units have such short deadlines -- everything was
running at high priority (no alternation between projects possible) -- E@H
work preempted S@H work, so I let it run all night and then suspended E@H.
I did complete a few E@H WUs on Tuesdays when S@H is down.

BTW, E@H's work units downloaded in about a half hour, but the application
files had single-digit transfer rates, so it was at least an hour before my
computers could begin any E@H work.

It would be nice to download a few GPU WUs from E@H on Tuesdays when S@H is
down, but with the way the server works now, it just is not possible.  Also,
it would be nice to execute more than one WU per GPU.

Charles Elliott


-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of
Richard Haselgrove
Sent: Wednesday, February 19, 2014 10:51 AM
To: Nicolás Alvarez; William Stilte
Cc: BOINC Developers Mailing List
Subject: Re: [boinc_dev] new GUI RPC for getting completed /reported tasks

I've just been reminded of another reason why this would be helpful. Not
every project's scheduler/feeder allocates tasks in monotonic order of
ResultID. Consider

http://einstein.phys.uwm.edu/results.php?hostid=4124638


From page 1 alone, I can see that tasks were allocated at

7:19:40
7:20:54
7:22:00
7:23:05
7:24:12 

and the pattern continues on subsequent pages: having the column sortable
would help to identify the pattern.

Not unnaturally, the excessive work fetch prompted a report by the user on
the project's message
board: http://einstein.phys.uwm.edu/forum_thread.php?id=10566 - in this
case, an experienced user has posted a calm and reasonable question, but in
other similar cases, there have been accusatory posts blaming the project
for pushing an unreasonable volume of work. Unfairly, IMHO. 

My preliminary assessment is that this is another manifestation of the
problem I reported on the boinc_alpha mailing list in May last year, under
the title v7.0.64 - repeated and excessive work fetch: it's the client
which initiates the work fetch, again and again and again, despite the
volume of work being downloaded being substantially in excess of the maximum
cache requested. We had a lengthy discussion about this bug, and I supplied
logs from when I observed the behaviour on my own machine, but I don't
recall any changeset declaring the problem fixed (though Jacob Klein did
send me a copy of a private reply he'd received from David, suggesting that
GPU exclusion code was being used when inappropriate).

Unfortunately, the present reporter is using an old version of BOINC
(v6.10.60), so his experience doesn't answer the question about a fix - but
the column sort on the result pages (to get back on topic) would help with
diagnosis.




 From: Nicolás Alvarez nicolas.alva...@gmail.com
To: William Stilte william.sti...@gmail.com
Cc: BOINC Developers Mailing List boinc_dev@ssl.berkeley.edu
Sent: Sunday, 16 February 2014, 22:37
Subject: Re: [boinc_dev] new GUI RPC for getting completed /reported 
tasks
 

If you want to sort by time then sort by time (once that is made 
possible), not by ID.

In my opinion the numeric IDs shouldn't even be exposed on the website 
(of course it's too late for that now).

2014-02-14 8:25 GMT-03:00 William Stilte william.sti...@gmail.com:
 For sake of completeness, I wrote the following back in Spetember:


 While sorting by task name is useful at times, if you're trying to 
 find a particular task, in general you'd want to see the tasks in 
 order of task id
 - which amount to ordering by send time/date.
 Would it be possible to get custom column sorting instead (e.g. by 
 clicking on the column 

Re: [boinc_dev] IDLE detection on Linux

[McLeod, John]

I believe that there is a setting that can delay the startup of BOINC tasks for 
X seconds.  If this is true, then we have to be storing the BOINC startup time, 
and we could piggyback off of that somehow.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Jussi 
Lahtinen
Sent: Tuesday, February 18, 2014 1:10 PM
To: boinc_dev@ssl.berkeley.edu
Subject: [boinc_dev] IDLE detection on Linux

BOINC's IDLE detection on Linux desktops seem to have been always broken
(only the ways have changed). There are various methods for BOINC to get
the IDLE time on Linux, but I have focused on trying to fix the one that
relies on Xserver. It seems that BOINC starts too soon to work properly
with X. Because if you restart BOINC after desktop is fully loaded, it will
work as expected. Correct assumption?

So I tried to prevent BOINC to touch X related code until X is really
ready. See attachment and from the end function named xss_idle. This
doesn't work for reasons I'm not aware. Anyone knows what is the problem
with this method? Or how to fix it?

Alternatively, is there function/method to make BOINC to restart itself? Or
is there method to make BOINC start later? Sleep command doesn't work here
and Upstart etc init scripts doesn't seem to provide needed features.


Jussi
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] Estimated Time Remaining, frictional reporting ...

[McLeod, John]

No, William wants linear to be the default and the old version to be Opt in.  

I would rather see if there was some way to fix this without splitting it.  If 
there isn't, then make the linear version be opt in, not the old one.  

-Original Message-
From: Oliver Bock [mailto:oliver.b...@aei.mpg.de] 
Sent: Monday, February 17, 2014 4:26 AM
To: McLeod, John; William; Jon Sonntag
Cc: BOINC Developers Mailing List @berkeley.edu
Subject: Re: [boinc_dev] Estimated Time Remaining, frictional reporting ...

* PGP - S/MIME Signed by an unverified key: 2/17/2014 at 4:25:53 AM

Hi John,

On 14/02/14 3:48 , McLeod, John wrote:
 Having the current method be opt in is no better than having a new method be 
 opt in – for exactly the same reasons.

I concur with William: if projects miss to opt for using the
linear/dynamic flag they'll only hurt themselves. This is a
self-correcting issue as projects have a strong interest in retaining
volunteers and not drive them away by using/causing sub-optimal runtime
estimates.


Best,
Oliver


 From: William [mailto:bcdecbi...@yahoo.com]
 Sent: Thursday, February 13, 2014 9:02 PM
 To: McLeod, John; Jon Sonntag
 Cc: BOINC Developers Mailing List @berkeley.edu
 Subject: Re: [boinc_dev] Estimated Time Remaining, frictional reporting ...
 
 Fixing the estimates is hard.  Worth improving, but not a reliable fix 
 strategy by itself.
 
 Improving the percent complete and estimated remaining run time calculation 
 is a lot easier - but the proposal is that this be a non-default fix, which 
 makes it also unreliable because projects cannot be relied upon to opt into 
 the fix.
 
 Duration Correction Factor - either this is a form of improved calculation or 
 else it relies on opt-in from the projects or opt-in from the user, the 
 latter being disastrous and both being unreliable.
 
 Reliable fix strategy:
 
 1) Improve the default percent complete and estimated remaining run time 
 calculations - this becomes linear.
 
 2) Provide a dynamic calculations opt-in flag for those projects wishing to 
 stay with original runtime estimates.  Gross errors (including failure to 
 opt-in) now become the fault of the project, not the BOINC client and 
 especially not the user.  Also try to improve the dynamic calculations (less 
 heavily weighted against the linear result).



* Oliver Bock oliver.b...@aei.mpg.de
* Issuer: GermanGrid - Unverified
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] Estimated Time Remaining, frictional reporting ...

[McLeod, John]

The current method works tolerably well for all projects.  Strict linear based 
on % complete will fail miserably for fairly high proportion of projects.

Please note that we had this discussion years ago when we did the original 
work.  It was determined that straight linear based on % complete would not 
work at all for some projects - therefore it was determined to be unsuitable.

From: William [mailto:bcdecbi...@yahoo.com]
Sent: Monday, February 17, 2014 11:14 AM
To: Oliver Bock; McLeod, John; Jon Sonntag
Cc: BOINC Developers Mailing List @berkeley.edu
Subject: Re: [boinc_dev] Estimated Time Remaining, frictional reporting ...

OK, to clarify:

Old method: mixing project's pre-estimate with linear estimate based on what 
the app reports as fraction done, according to a mixing curve that heavily 
favors the project's pre-estimate early in the computation.  This old method 
should become a project opt-in.

New method: linear estimate based on what the app reports as fraction done.  
This should become the new default.

Possible even better method: keep track of actual timing results for the last N 
runs and use the average of all those to either smooth (improve the accuracy 
of) or replace what the app reports as fraction done.  Another opt-in (or two), 
but these would be user opt-ins (vs. project opt-ins).  Overrides either the 
new default method or the project opt-in method (if used).

~
Rightful liberty is unobstructed action according to our will within limits 
drawn around us by the equal rights of others. I do not add 'within the limits 
of the law' because law is often but the tyrant's will, and always so when it 
violates the rights of the individual. - Thomas Jefferson

On Monday, February 17, 2014 10:55 AM, Oliver Bock 
oliver.b...@aei.mpg.demailto:oliver.b...@aei.mpg.de wrote:
On 17/02/14 15:39 , William wrote:
 This is exactly why linear should be the default.  Dynamic should
 be available only to those projects that care enough to set it up
 properly.  Linear should apply to the lazy ones unless and until
 they take the time to deliberately opt in.

And this is where I think you got the (new) terms wrong: dynamic means
not to use any static estimates but to rely completely on what the app
reports as fraction done. This is (de facto) reliable for apps with the
said linear behavior. Bottom line: the linear option isn't the
opposite/alternative of a dynamic estimate, they go hand in hand.


Cheers,

Oliver

___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] Estimated Time Remaining, frictional reporting ...

[McLeod, John]

If and only if the progress is actually linear.  There are projects where the 
first 10% of the time runs the progress bar to 90% mostly because there are 
non-determinable portions of the time.

So 
10% at 5 minutes
20% at 10 minutes
30% at 15 minutes
40% at 20 minutes
50% at 25 minutes
60% at 30 minutes
70% at 35 minutes
80% at 40 minutes
90% at 45 minutes
Done at 2 hours...

It appears to be linear until it isn't.  If everything were as nice as you say 
for all of the projects, then, yes, we could move to a strictly linear model.  
The point is that it isn't.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Jon 
Sonntag
Sent: Wednesday, February 12, 2014 5:28 PM
To: elliott...@verizon.net
Cc: BOINC Developers Mailing List @berkeley.edu
Subject: Re: [boinc_dev] Estimated Time Remaining, frictional reporting ...

If after 5 minutes, a workunit  is 10% done and after 10 minutes it is 20%
done, I don't need a domain expert.  A 4th grade student should be able to
calculate that it will take a total of 50 minutes to complete and that 40
minutes remain.

Jon Sonntag

P.S. I went to a tax professional once. They charged a lot and they got it
wrong.  The IRS corrected it and sent me a refund.



On Tue, Feb 11, 2014 at 6:18 AM, Charles Elliott elliott...@verizon.netwrote:

 Although I am a CS grad student, I urge you to reconsider choosing CS grad
 students to work on this problem and consider instead using domain experts
 in statistics and/or Operations Research or Systems, or perhaps even an
 interdisciplinary team.  Old research shows  that it is much more
 cost-effective to hire domain experts and teach them to program computers
 than it is to hire CS grads and try to teach them the domain.  Suppose your
 income tax preparation was a complex process.  Which would you want do it:
 a
 CS grad who wrote the fastest program possible, or a tax law expert who
 could save you months of work on an IRS tax audit and keep you out of jail?

 Charles Elliott

 -Original Message-
 From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of
 David Anderson
 Sent: Monday, February 10, 2014 10:58 PM
 To: boinc_dev@ssl.berkeley.edu
 Subject: Re: [boinc_dev] Estimated Time Remaining, frictional reporting ...

 In general we've put statistics-gathering into server rather than client
 because
 - it gives uniform data over the entire host population
 - it puts the data all in one place

 Currently these statistics are just the bare essentials:
 mean and standard deviation of elapsed time, turnaround time, and
 credit-related quantities.
 We maintain these per (host, app version) and per app version.
 We use them to estimate job duration and to compute credit.

 As you point out, there are many other types of info we could track, and
 many visualizations that could offered.
 This is an area were having a few CS grad students working on BOINC would
 be
 a big help.

 -- David

 On 10-Feb-2014 4:01 PM, Max Power wrote:
 
  Many types of distributed computing applications don't due uniform
  processing (and reporting on percent done) like SETI, Astropulse or
  Einstein ... and the biological science applications (and image
  rendering ones) have taken some time to discipline the reporting of
 percent done.
 
  What the BOINC Client does not do is use the hashsums of computing
  applications (as sometimes they run in pairs as in Climate Prediction)
  to form a local knowledge base of
 
  -- work unit size (average, median, standard deviation)
  -- work unit computation length  (average, median, standard deviation)
  -- completed work unit average size  (average, median, standard
  deviation)
  -- disk use  (average, median, standard deviation)
  -- these could be uplinked to the BOINC design groups and the projects
  themselves ... as you probably have to do an SQL query to find this
  stuff out
  -- THE STATS tab is almost totally devoid of usable statistics ...
  and the ones above relating to runtime are graphable and usable ...
 
 
  I am not saying this will fix the wonky estimated run time problem ...
  only regular application reporting to the BOINC client will ever do
  that. However, the averaged knowledge from these parameters could
  improve it when the daft application is not reporting.
 
 
  MP, DSN @ H
 
 
  -Original Message- From: McLeod, John
  Sent: 10 February 2014 05:48
  To: Jon Sonntag ; BOINC Developers Mailing l...@berkeley.edu
  Subject: Re: [boinc_dev] Estimated Time Remaining
 
  Not all applications report  smooth % complete.  So the calculation of
  time remaining involve the initial estimate as well.  Given the bad
  information given for both % complete and initial estimate, there is
  no method of predicting how much longer the task will take that is
  completely right.  The most reliable appears to be to combine the
  initial estimate the DCF (if in use for the project) the % complete,
  and the time spent already

Re: [boinc_dev] Estimated Time Remaining, frictional reporting ...

[McLeod, John]

High priority does not mean that the task will not complete on time.  It means 
that if the tasks run in normal Round Robin between projects and First In First 
Out within a project there is a risk that there will be tasks that will not 
complete on time.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of William
Sent: Wednesday, February 12, 2014 6:50 PM
To: Jon Sonntag; elliott...@verizon.net
Cc: BOINC Developers Mailing List @berkeley.edu
Subject: Re: [boinc_dev] Estimated Time Remaining, frictional reporting ...

The question, however, is this: is BOINC as smart as a 4th grader - can it 
avoid falsely claiming that work units won't finish on time, thus misleading 
users into aborting work units that appear to have absolutely no chance of 
making their deadline?

Signs point to NO.

 
~
Rightful liberty is unobstructed action according to our will within limits 
drawn around us by the equal rights of others. I do not add 'within the limits 
of the law' because law is often but the tyrant's will, and always so when it 
violates the rights of the individual. - Thomas Jefferson



On Wednesday, February 12, 2014 5:28 PM, Jon Sonntag j...@thesonntags.com 
wrote:
 
If after 5 minutes, a workunit  is 10% done and after 10 minutes it is 20%
done, I don't need a domain expert.  A 4th grade student should be able to
calculate that it will take a total of 50 minutes to complete and that 40
minutes remain.

Jon Sonntag

P.S. I went to a tax professional once. They charged a lot and they got it
wrong.  The IRS corrected it and sent me a refund.



On Tue, Feb 11, 2014 at 6:18 AM, Charles Elliott elliott...@verizon.netwrote:

 Although I am a CS grad student, I urge you to reconsider choosing CS grad
 students to work on this problem and consider instead using domain experts
 in statistics and/or Operations Research or Systems, or perhaps even an
 interdisciplinary team.  Old research shows  that it is much more
 cost-effective to hire domain experts and teach them to program computers
 than it is to hire CS grads and try to teach them the domain.  Suppose your
 income tax preparation was a complex process.  Which would you want do it:
 a
 CS grad who wrote the fastest program possible, or a tax law expert who
 could save you months of work on an IRS tax audit and keep you out of jail?

 Charles Elliott

 -Original Message-
 From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of
 David Anderson
 Sent: Monday, February 10, 2014 10:58 PM
 To: boinc_dev@ssl.berkeley.edu
 Subject: Re: [boinc_dev] Estimated Time Remaining, frictional reporting ...

 In general we've put statistics-gathering into server rather than client
 because
 - it gives uniform data over the entire host population
 - it puts the data all in one place

 Currently these statistics are just the bare essentials:
 mean and standard deviation of elapsed time, turnaround time, and
 credit-related quantities.
 We maintain these per (host, app version) and per app version.
 We use them to estimate job duration and to compute credit.

 As you point out, there are many other types of info we could track, and
 many visualizations that could offered.
 This is an area were having a few CS grad students working on BOINC would
 be
 a big help.

 -- David

 On 10-Feb-2014 4:01 PM, Max Power wrote:
 
  Many types of distributed computing applications don't due uniform
  processing (and reporting on percent done) like SETI, Astropulse or
  Einstein ... and the biological science applications (and image
  rendering ones) have taken some time to discipline the reporting of
 percent done.
 
  What the BOINC Client does not do is use the hashsums of computing
  applications (as sometimes they run in pairs as in Climate Prediction)
  to form a local knowledge base of
 
  -- work unit size (average, median, standard deviation)
  -- work unit computation length  (average, median, standard deviation)
  -- completed work unit average size  (average, median, standard
  deviation)
  -- disk use  (average, median, standard deviation)
  -- these could be uplinked to the BOINC design groups and the projects
  themselves ... as you probably have to do an SQL query to find this
  stuff out
  -- THE STATS tab is almost totally devoid of usable statistics ...
  and the ones above relating to runtime are graphable and usable ...
 
 
  I am not saying this will fix the wonky estimated run time problem ...
  only regular application reporting to the BOINC client will ever do
  that. However, the averaged knowledge from these parameters could
  improve it when the daft application is not reporting.
 
 
  MP, DSN @ H
 
 
  -Original Message- From: McLeod, John
  Sent: 10 February 2014 05:48
  To: Jon Sonntag ; BOINC Developers Mailing l...@berkeley.edu
  Subject: Re: [boinc_dev] Estimated Time Remaining
 
  Not all applications report  smooth % complete.  So the calculation of
  time remaining involve

Re: [boinc_dev] Estimated Time Remaining

[McLeod, John]

Not all applications report  smooth % complete.  So the calculation of time 
remaining involve the initial estimate as well.  Given the bad information 
given for both % complete and initial estimate, there is no method of 
predicting how much longer the task will take that is completely right.  The 
most reliable appears to be to combine the initial estimate the DCF (if in use 
for the project) the % complete, and the time spent already (the only really 
well known item in the list) to come up with an estimate.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Jon 
Sonntag
Sent: Saturday, February 08, 2014 2:54 PM
To: BOINC Developers Mailing List @berkeley.edu
Subject: [boinc_dev] Estimated Time Remaining

Why would 11% complete in 1.5 hours have an estimated 72 hours remaining
when it should be closer to 14 hours remaining?  Does BOINC need a math
tutor?  ;-)

I find it interesting that the estimates on a Q6600 are correct but on both
of my i7 hosts they are way too high.

All hosts have all been running the app for several weeks so any learning
curve by the smart estimate algorithm should have adjusted the numbers
already, right?  How long should it take BOINC to get the estimates
correct?  I would think less than an hour when percent complete is totally
linear.  Or is the problem the that the benchmarks do not take into account
hyper-threading which skews the estimates?

Jon Sonntag
___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] Estimated Time Remaining

[McLeod, John]

However, the % complete is often not measured well, and that is required to be 
accurate for an estimate based on time spent and % complete.

From: Richard Haselgrove [mailto:r.haselgr...@btopenworld.com]
Sent: Monday, February 10, 2014 9:32 AM
To: McLeod, John; Jon Sonntag; BOINC Developers Mailing List @berkeley.edu
Subject: Re: [boinc_dev] Estimated Time Remaining

... the time spent already (the only really well known item in the list) ...

Which is why I'd like to see greater weight given to this in the displayed 
estimate. It seems the be the wrong way round, to distort the displayed figures 
for well-behaved (in the mathematical sense) projects, just because a 
minority of projects can't predict runtime in advance.

It would be better if BOINC left project problems to the projects concerned, 
and concentrated on the things which only BOINC can get right - and the initial 
estimates for new hosts (and hence possibly new volunteers) would seem to be a 
higher priority. It's subjective, but I seem to have seen a lot of posts on 
message boards by new volunteers who come close to aborting tasks, even 
abandoning the project entirely, because there seems to be no way of completing 
the initial task(s) within deadline.

Jon's comparison of Q6600 and i7 should remind us that the Whetstone benchmark 
was originally designed to defeat compiler optimizations (Wikipedia) - and 
hence will also defeat hardware optimisations like SIMD and AVX, also not 
present on a KDF9. The initial estimate for a CPU application needs to be based 
on real-world scientific throughput in the 21st. century, and for a GPU 
application on an assessment of the speed of the GPU in question (not, as at 
present, on a multiplier of the host CPU).

From: McLeod, John john.mcl...@sap.commailto:john.mcl...@sap.com
To: Jon Sonntag j...@thesonntags.commailto:j...@thesonntags.com; BOINC 
Developers Mailing List @berkeley.edu 
boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
Sent: Monday, 10 February 2014, 13:48
Subject: Re: [boinc_dev] Estimated Time Remaining

Not all applications report  smooth % complete.  So the calculation of time 
remaining involve the initial estimate as well.  Given the bad information 
given for both % complete and initial estimate, there is no method of 
predicting how much longer the task will take that is completely right.  The 
most reliable appears to be to combine the initial estimate the DCF (if in use 
for the project) the % complete, and the time spent already (the only really 
well known item in the list) to come up with an estimate.

-Original Message-
From: boinc_dev 
[mailto:boinc_dev-boun...@ssl.berkeley.edumailto:boinc_dev-boun...@ssl.berkeley.edu]
 On Behalf Of Jon Sonntag
Sent: Saturday, February 08, 2014 2:54 PM
To: BOINC Developers Mailing List @berkeley.edu
Subject: [boinc_dev] Estimated Time Remaining

Why would 11% complete in 1.5 hours have an estimated 72 hours remaining
when it should be closer to 14 hours remaining?  Does BOINC need a math
tutor?  ;-)

I find it interesting that the estimates on a Q6600 are correct but on both
of my i7 hosts they are way too high.

All hosts have all been running the app for several weeks so any learning
curve by the smart estimate algorithm should have adjusted the numbers
already, right?  How long should it take BOINC to get the estimates
correct?  I would think less than an hour when percent complete is totally
linear.  Or is the problem the that the benchmarks do not take into account
hyper-threading which skews the estimates?

Jon Sonntag
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edumailto:boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edumailto:boinc_dev@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.

___
boinc_dev mailing list
boinc_dev@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.

[boinc_dev] MemSet and C++ Classes.

[McLeod, John]

In short, don't use memset on any structure that includes a class.  Tthe class 
constructor may intentionally set internal variables that are not 0.  The 
implementation of each class may vary from platform to platform, and may vary 
over time.  These bugs can be hard to track down.  Much better is to use 
classes and constructors / destructors for everything.  The built in default 
constructor if you don't declare one is supposed to set all values in the class 
to 0 or null.  The  built in destructor does nothing.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] MemSet and C++ Classes.

[McLeod, John]

Certainly don't write any new code that uses mem* on classes or structures.

From: korp...@gmail.com [mailto:korp...@gmail.com] On Behalf Of Eric J Korpela
Sent: Thursday, January 09, 2014 11:05 AM
To: McLeod, John
Cc: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] MemSet and C++ Classes.

I'd even extend that to Do not use mem*() on any structure or class in C++.   
Write a default constructor, a copy constructor (if appropriate), an operator 
=() (if appropriate), and a clear() method if appropriate.  Write destructors 
as necessary.

On Thu, Jan 9, 2014 at 5:50 AM, McLeod, John 
john.mcl...@sap.commailto:john.mcl...@sap.com wrote:
In short, don't use memset on any structure that includes a class.  Tthe class 
constructor may intentionally set internal variables that are not 0.  The 
implementation of each class may vary from platform to platform, and may vary 
over time.  These bugs can be hard to track down.  Much better is to use 
classes and constructors / destructors for everything.  The built in default 
constructor if you don't declare one is supposed to set all values in the class 
to 0 or null.  The  built in destructor does nothing.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edumailto:boinc_dev@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.

___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] RFC: Don't let a task be in the state Ready to report if its files were uploaded immediately before

[McLeod, John]

Changing it to one hour will essentially disable multi task reporting for most 
projects.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of David 
Anderson
Sent: Monday, December 30, 2013 1:31 PM
To: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] RFC: Don't let a task be in the state Ready to 
report if its files were uploaded immediately before

The policy for when to report tasks is in
CLIENT_STATE::find_project_with_overdue_results().
One of the clauses is that tasks are reported within 24 hours of completion.
I changed this to 1 hour.
-- David

On 27-Dec-2013 10:11 AM, Toralf Förster wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 12/27/2013 02:30 PM, Toralf Förster wrote:
 The topic was discussed kin the past - yes. And I do understand to
 objection to not overload the network resources of a BOINC server
 with tasks which could be done a day later or so.

 But today I ran (again) into a case, where a task was solved fine
 and its files were uploaded successfully to to the World Community
 Grid server around 23th of December, but the task itself stayed in
 the state Ready to report. Then the computer was s2disked.

 Today I came back - and the task is marked as Too late (the dead
 line was yesterday).

 Well, Christmas is a rare case (within a year) - but I think,
 there's place for an improvement to upload *and* report a task
 immediately instead of reporting it (at least at my system almost)
 later.



 FWIW here're the last 500 lines of /var/lib/boinc/stdoutdae.txt :
 http://bpaste.net/show/162219/

 and I do refer to this task :


   
 Workunit Status   
   
 Project Name: FightAIDS@Home - Vina
 Created:  12/16/2013 11:04:43
 Name: FAHV_x1ZTZ_prnotAS2_0621789_0533
 Minimum Quorum:   1
 Replication:  2


 - --
 MfG/Sincerely
 Toralf Förster
 pgp finger print:1A37 6F99 4A9D 026F 13E2 4DCF C4EA CDDE 0076 E94E
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.22 (GNU/Linux)
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iF4EAREIAAYFAlK9wrgACgkQxOrN3gB26U5YpwD/eBz0CbBnc2wZMjTS74tFnRFW
 yVoTLxpMhLacpIy/jcwA/j3CYUDvmjrMuCzKpFTGaJYO5vYjILvVKsEsroAKTf1X
 =uBvX
 -END PGP SIGNATURE-
 ___
 boinc_dev mailing list
 boinc_dev@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.

___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] RFC: Don't let a task be in the state Ready to report if its files were uploaded immediately before

[McLeod, John]

Instead of reporting after an hour which will have the consequence of reporting 
almost every task on its own, how about reporting no later than 48 hours prior 
to deadline (this will cope with one day vacations for most machines with some 
added slop if there is a delay turning the machine back on), and report no 
later than min_queue + 24 hours (this will avoid a reporting late because of 
turning off the machine a few minutes early because of a longer vacation).

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
McLeod, John
Sent: Monday, January 06, 2014 10:46 AM
To: David Anderson; boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] RFC: Don't let a task be in the state Ready to 
report if its files were uploaded immediately before

Changing it to one hour will essentially disable multi task reporting for most 
projects.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of David 
Anderson
Sent: Monday, December 30, 2013 1:31 PM
To: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] RFC: Don't let a task be in the state Ready to 
report if its files were uploaded immediately before

The policy for when to report tasks is in
CLIENT_STATE::find_project_with_overdue_results().
One of the clauses is that tasks are reported within 24 hours of completion.
I changed this to 1 hour.
-- David

On 27-Dec-2013 10:11 AM, Toralf Förster wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 12/27/2013 02:30 PM, Toralf Förster wrote:
 The topic was discussed kin the past - yes. And I do understand to
 objection to not overload the network resources of a BOINC server
 with tasks which could be done a day later or so.

 But today I ran (again) into a case, where a task was solved fine
 and its files were uploaded successfully to to the World Community
 Grid server around 23th of December, but the task itself stayed in
 the state Ready to report. Then the computer was s2disked.

 Today I came back - and the task is marked as Too late (the dead
 line was yesterday).

 Well, Christmas is a rare case (within a year) - but I think,
 there's place for an improvement to upload *and* report a task
 immediately instead of reporting it (at least at my system almost)
 later.



 FWIW here're the last 500 lines of /var/lib/boinc/stdoutdae.txt :
 http://bpaste.net/show/162219/

 and I do refer to this task :


   
 Workunit Status   
   
 Project Name: FightAIDS@Home - Vina
 Created:  12/16/2013 11:04:43
 Name: FAHV_x1ZTZ_prnotAS2_0621789_0533
 Minimum Quorum:   1
 Replication:  2


 - --
 MfG/Sincerely
 Toralf Förster
 pgp finger print:1A37 6F99 4A9D 026F 13E2 4DCF C4EA CDDE 0076 E94E
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.22 (GNU/Linux)
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iF4EAREIAAYFAlK9wrgACgkQxOrN3gB26U5YpwD/eBz0CbBnc2wZMjTS74tFnRFW
 yVoTLxpMhLacpIy/jcwA/j3CYUDvmjrMuCzKpFTGaJYO5vYjILvVKsEsroAKTf1X
 =uBvX
 -END PGP SIGNATURE-
 ___
 boinc_dev mailing list
 boinc_dev@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.

___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] updates for trickle_deadline.cpp

[McLeod, John]

If the user has paused a job, they should probably not get it replaced.  If it 
is past deadline, and is still paused, then we might want to abort it.  If it 
is paused and is in deadline trouble, then we might want to warn the user of 
the problem.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of David 
Anderson
Sent: Friday, November 22, 2013 2:33 PM
To: Christian Beer; BOINC Developers Mailing List
Subject: Re: [boinc_dev] updates for trickle_deadline.cpp

Christian:
Each scheduler RPC request includes a list of jobs on the client.
How about if we add the following optional scheduler feature:
enumerate the jobs assigned to the host,
and if any of them is not listed in the request,
assume it's been lost and create a new instance.

This doesn't handle the case where the user paused a job and forgot about it.
Does this case matter?

-- David

On 22-Nov-2013 11:13 AM, Christian Beer wrote:
 Not when the task is lost because the user formated the harddrive or
 paused the task and forgot about it. In those cases, where the user
 doesn't cancel the task but it is not processed either, we would
 generate a new task very late. This is not a desired behavior.
 We could use the trickle up logic to abort the task server side if we
 don't receive a trickle within 14 days but than we have to use a new
 table or other structure to store the last trickle contact.

 Am 22.11.2013 20:02, schrieb David Anderson:
 Wouldn't this be equivalent to having an extremely long deadline to
 begin with?

 On 22-Nov-2013 4:50 AM, Christian Beer wrote:
 Hi David,

 maybe something else is possible. What if the server can mark the
 deadline of the task as non compulsive so the client won't go into
 high priority mode to keep the deadline. This would of course only be
 suitable for projects that either increase the deadline using trickles
 or don't care about the deadline at all.

 Regards
 Christian

 Am 12.11.2013 06:00, schrieb David Anderson:
 Christian:
 Unfortunately, with the current architecture there's no easy way to
 communicate
 to the client that the deadline has changed.
 -- David
 On 11-Nov-2013 2:05 PM, Christian Beer wrote:
 Some users reported that for our long running jobs the client switches
 to High priority mode for RNA World and will not switch to other
 projects as usual.

 I currently have a task on my desktop with an estimation of 340 hours
 with a 20 day deadline (that I can not meet with an uptime of 6h per
 day). I don't want to increase the deadline for those long runners
 because than we have to wait 2 months until a new task is created
 because the first task vanished on the host. Sure this is the worst
 case scenario but we are more flexible with a shorter deadline.

 My fear is that users are aborting our tasks because they think they
 missed the deadline or can't even meet the deadline. I see a lot of
 EXIT_ABORTED_VIA_GUI with our new VM application. This maybe only be
 fixed with an increased deadline but the problem of an underestimated
 runtime can still occur and if the task is still running on the client
 we want to know on the server. And the client should also know that
 there is more time available to finish the task and there is no hurry.

 Regards
 Christian

 Am 11.11.2013 22:28, schrieb David Anderson:
 Thanks; I committed these.

 Currently the deadline isn't changed on the client.
 I'm not sure this really matters; what do you think?

 -- David

 On 11-Nov-2013 11:28 AM, Christian Beer wrote:
 Hi David,

 now that Trickles are working again I updated the trickle_deadline
 handler. I changed the output to the BOINC format like in
 scheduler.log
 and added a hostid check to the result lookup for more security. Now
 every host can only extend the own results and not others.

 The code is tested on RNA World.

 Regards
 Christian





___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] updates for trickle_deadline.cpp

[McLeod, John]

CPDN does something similar.  They send a trickle up message every couple of % 
toward completion.  If the deadline is past, and there has not been a trickle 
up within a period of time (2 weeks?  a month?), then the task is marked as 
abandoned, and replaced by sending it out to another computer.  The client is 
not updated with a new deadline, but the user base has been educated to know 
that the project has soft deadlines, and not to worry too much about a slightly 
missed deadline.

You could also use the setting to contact the server at least once every X days 
as well.  If there is work on the client, the client will contact the server at 
least this frequently.  Since this is a project setting, there would not have 
to be a change of application.

Having the reply for a trickle up message be able to set a new deadline would 
be nice.

From: Michael Goetz [mailto:m...@asgoodasitgoetz.com]
Sent: Monday, November 25, 2013 9:29 AM
To: McLeod, John
Cc: David Anderson; Christian Beer; BOINC Developers Mailing List
Subject: Re: [boinc_dev] updates for trickle_deadline.cpp

David,

tl;dr version:  I have what may be a better idea; skip to the bottom...

At PrimeGrid, we have more than passing interest in a deadline extension 
mechanism since we have really long tasks that could theoretically be run on 
anything from 32-bit CPUs to the latest GPUs.  We don't currently allow the 
longest tasks to run on CPUs because that would mean extending the deadlines to 
many months, and that would drastically slow down the progress of the overall 
projects.

Being able to extend deadlines would allow us to set the deadlines much 
shorter, which in turn would make for a quicker turn around for validation.

It should be noted that, by a large margin, the #1 cause of missed deadlines is 
NOT slow machines.  It's primarily caused by users simply abandoning PrimeGrid 
(i.e., detaching) or abandoning BOINC altogether.  Therefore, your suggestion 
about enumerating the jobs wouldn't help because in most cases the host simply 
never communicates with PrimeGrid again.

When this topic surfaced a few months ago, I did some research into how we 
could utilize such a function at PrimeGrid.  In the end it's simply not useful 
unless the client can recognize that the deadline has changed.  But if that 
could happen via a trickle-down message, we'd use it like this:

1) Start jobs with fairly short time limits that are reasonable for fast 24/7 
computers.

2) The app (either the native app or the wrapper) would look at the deadline 
and the expected run time and if it's not going to finish with at least 24 
hours to spare it would request a deadline extension to expected_finish_time + 
48 hours.  For this calculation the app would assume it's crunching 24/7 and 
would use application-specific logic to compute run-time.  At PrimeGrid we can 
predict the run time far more accurately than BOINC can measure and 
extrapolate, but this might not work for other projects.  If a host is not 
computing 24/7, the requested deadline extension will be too small, but that 
just means the deadline will get extended every day (or every other day), and 
that's fine.

3) The app will be send a trickle-up message every day.  By detecting that a 
trickle hasn't been received in several days, the server could decide the task 
is abandoned long before the deadline and send a new result out to another 
host.  This could result in extraneous results being sent out if a host is 
offline for several days, but it could also result in much faster cancellations 
of abandoned task.

4) On the server side, when we get a trickle-up message requesting a deadline 
extension, we can decide whether or not to extend the deadline, and convey that 
back to the client by trickle-down.

Now for the better idea:

In theory, we could employ ONLY step 3 and use REALLY long deadline plus this 
mechanism to allow slow computers while still avoiding huge delays simply by 
using trickle ups to report status without needing to extend deadlines.  It's a 
simple server change:  if you haven't received a trickle up message showing 
progress on the task in N days, mark it as expired in the database and a new 
task gets sent out.  That effectively makes the deadline (as it pertains to 
sending out a replacement task) fairly short, whereas the deadline that affects 
how long a host has to finish could be very long.  For me, at least, this seems 
to have the same end result as building a deadline-extension mechanism, but is 
much, much simpler.

The only drawback of the simplified approach is that users who use app_info and 
don't update to the new app that sends status trickles will time-out 
prematurely and cause the server to send out unneeded tasks.

Mike


On Mon, Nov 25, 2013 at 8:43 AM, McLeod, John 
john.mcl...@sap.commailto:john.mcl...@sap.com wrote:
If the user has paused a job, they should probably not get it replaced.  If it 
is past deadline, and is still paused, then we

[boinc_dev] unbounded slot dirs

[McLeod, John]

An unbounded number of slot dirs. Would be caused by High Priority picking up a 
task, running it for a few minutes, discovering that that particular task was 
no longer in high priority, and picking up one that was now in high priority.  
Repeat until all tasks have run for a couple of minutes in high priority.  
(This should have been fixed by the recent change to EDF for the project rather 
than selecting the tasks that were tagged as high priority).

The other way would be to have slots that cannot be cleaned out (but I thought 
that bug was fixed a while ago).

On a different note, could we change the calculated maximum number of slots to 
cope with machines with more than 1000 CPUs?  I know that machines like that 
are rare now.  How about n_cpus * 100 for the number of slot directories 
allowed?
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] unbounded slot dirs

[McLeod, John]

I was figuring that they went up to a few thousand, not a few million before 
there was trouble.

I want to know what file system they were using that could cope with 12 million 
directory fanout in one directory.  I know that the MS directory systems fall 
over around 5K...

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of David 
Anderson
Sent: Thursday, October 24, 2013 2:33 PM
To: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] unbounded slot dirs

Possibly, though in this case (12 million slot dirs)
that would imply that the client has 12 million tasks,
which is unlikely because then the client would completely bog down
because of the N^2 scheduling logic.
It's more likely due to a failure to clean out slot dirs,
and I suspect it's specific to Volpex.

I'll make the ncpus*100 change.

-- David
On 24-Oct-2013 11:26 AM, McLeod, John wrote:
 An unbounded number of slot dirs. Would be caused by High Priority picking up 
 a task, running it for a few minutes, discovering that that particular task 
 was no longer in high priority, and picking up one that was now in high 
 priority.  Repeat until all tasks have run for a couple of minutes in high 
 priority.  (This should have been fixed by the recent change to EDF for the 
 project rather than selecting the tasks that were tagged as high priority).

 The other way would be to have slots that cannot be cleaned out (but I 
 thought that bug was fixed a while ago).

 On a different note, could we change the calculated maximum number of slots 
 to cope with machines with more than 1000 CPUs?  I know that machines like 
 that are rare now.  How about n_cpus * 100 for the number of slot directories 
 allowed?
 ___
 boinc_dev mailing list
 boinc_dev@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.

___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] Put BOINC in the browser!

[McLeod, John]

Found the answers to the questions I asked earlier.

Current limitations

Native Client currently has the following limitations:
*no support for hardware exceptions
*no support for process creation / subprocesses
*no support for raw TCP/UDP sockets (analogous versions-websockets for TCP and 
peer connect for UDP-are in the works and will be available soon)
*no support for query to available memory
*inline assembly must be compatible with the Native Client validator (you can 
use the ncval utility in the SDK to check)

This list pretty much makes  BOINC development for PNaCl dead before start.  In 
particular, BOINC needs to create sub processes, and it needs to do TCP.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Molly 
Mackinlay
Sent: Tuesday, October 08, 2013 4:29 PM
To: boinc_dev@ssl.berkeley.edu
Subject: [boinc_dev] Put BOINC in the browser!

Hi BOINC!

I've been reading about your platform and the amazing projects you enable
like LHC@Home, Seti, and Einstein@Home, and it sounds like an amazing
opportunity to harness the computing power of your average user to increase
our understanding of how the world works. Running simulations of beam
dynamics, protein folding, or particle collisions sounds pretty cool, but
I'm always wary of downloading a plugin or creating an account, so I've
never personally participated. That being said, I want to help compute the
future of physics, biology, and neuroscience too!

BOINC sounds pretty cool and I wanted to let you know about a new piece of
technology called Portable Native Client (PNaCl) that could make it usable
in the browser without forcing the user to download any annoying or buggy
plugins. I think you guys are working on something amazing to make the
world a better place, but it could reach even more people if they didn't
have to install anything. Just a thought, but maybe this catches your fancy!

PNaCl lets C and C++ code run efficiently (but safely!) inside a tab in
Chrome, meaning you don't have to rewrite all your code in Javascript to
put your application online. PNaCl enables you to take advantage of the
performance of native apps, while gaining the portability of the web. Check
out our Common Use Cases for more info about how it could work with your
application and feel free to reach out to me with questions, concerns, or
feedback.

Thanks so much for your time!
~Molly

Molly Mackinlay | APM 2013 | mackin...@google.com | 425-233-4943
___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] android: transfers in Projects tab

[McLeod, John]

The functionality exists in the advanced view on the transfers tab.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Stephen Maclagan
Sent: Tuesday, October 01, 2013 6:48 PM
To: joachim.fritz...@gmail.com; David Anderson (UCBerkeley); Rom Walton; Kevin 
Reed; Keith J Uplinger; Heinz-Bernd Eggenstein
Cc: boinc_dev@ssl.berkeley.edu; eah_andr...@aei.mpg.de
Subject: Re: [boinc_dev] android: transfers in Projects tab

I'd like a retry transfers button.

My Nexus 7 only uses Wifi, and i 
don't have 24 hour Wifi here, it normally uses a Fon public wifi access 
point, when it connects it often sees a multi hour project backoff for 
the uploads, i can get around that by restarting Boinc, but still 
leaves the backoff for the uploads, i've seen times of between a minute 
or two and 50 minutes so far, which is excessive since i intend to only 
connect to the hotspot for 5 minutes.

Claggy

Original 
Message
From: joachim.fritz...@gmail.com
Date: 01/10/2013 15:29 

To: David Anderson (UCBerkeley)da...@ssl.berkeley.edu, Rom Walton
r...@romwnet.org, Kevin Reedknr...@us.ibm.com, Keith J Uplinger
upl...@us.ibm.com, Heinz-Bernd EggensteinHeinz-Bernd.
eggenst...@aei.mpg.de
Cc: boinc_dev@ssl.berkeley.eduboinc_dev@ssl.
berkeley.edu, eah_andr...@aei.mpg.deeah_andr...@aei.mpg.de
Subj: 
[boinc_dev] android: transfers in Projects tab

I am getting rid off 
the Transfers tab in the Android UI, because:
- there are barely ever 
active transfers to show.
- the only interaction with an individual 
ongoing transfer is to abort
it, which I do not see as a common use 
case.
- making room for a more informative tab (Notices)

Instead, a 
status string could be shown in the Projects tab, for each
project 
individually. Here are a few examples of what I have currently

implemented:
Transfers active (1 Upload  3 Downloads)
Transfers 
pending (2 Downloads) retry in 01:25
Transfers pending (1 Upload)

nothing - if project is not trying to transfer files

The control 
for suspending all network traffic remains unchanged.

Comments?


Joachim
___
boinc_dev 
mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_devTo 
unsubscribe, visit the above URL and
(near bottom of page) enter your 
email address.



___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] android -- boinc not storing cpu features (/proc/cpuinfo features)

[McLeod, John]

Even if it is added to the DB, the clients are going to have to send it every 
time until such a time as all projects are updated.  If it is turned off most 
of the time, the clients will have to notice changes and send an update if the 
list no longer matches the one that was sent last.  This can be caused by 
either a hardware upgrade (moving the BOINC install to a new machine), or an OS 
upgrade (the new or patched OS now notices the new processor flag), or ?.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Jon 
Sonntag
Sent: Friday, August 23, 2013 9:12 AM
To: David Anderson
Cc: BOINC Developers Mailing List @berkeley.edu
Subject: Re: [boinc_dev] android -- boinc not storing cpu features 
(/proc/cpuinfo features)

If not in the database, the 1024 characters of CPU info gets sent every
single time the host contacts the server using network bandwidth over and
over and over and over and over and over  What costs more, a GB of disk
space or a GB of bandwidth?  (Hint: It isn't disk space.)

Jon Sonntag


On Thu, Aug 22, 2013 at 7:08 PM, David Anderson da...@ssl.berkeley.eduwrote:

 We could do this, but it would require adding a 1024-character
 field to the host DB table, which would increase the DB size somewhat
 (e.g. by 1 GB for projects w/ 1M hosts).
 Probably not worth it.

 On 22-Aug-2013 3:14 PM, Carl Christensen wrote:

 it might be nice on the boinc project's web page for computer (as Bernd
 mentioned) to print the p_feature field (like we do for bencharks)?  plus
 the
 coprocessor line I was thinking ARM Neon  VFP counted as a
 coprocessor
 (FPU rather than GPU)!  ;-) __**
 _
 boinc_dev mailing list boinc_dev@ssl.berkeley.edu
 http://lists.ssl.berkeley.edu/**mailman/listinfo/boinc_devhttp://lists.ssl.berkeley.edu/mailman/listinfo/boinc_devTo
  unsubscribe,
 visit the above URL and (near bottom of page) enter your email address.

  __**_
 boinc_dev mailing list
 boinc_dev@ssl.berkeley.edu
 http://lists.ssl.berkeley.edu/**mailman/listinfo/boinc_devhttp://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
 To unsubscribe, visit the above URL and
 (near bottom of page) enter your email address.

___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] Serious bug in BOINC android.

[McLeod, John]

Or, a reminder on the first startup that the device name is local host, and 
picking a different name would be a good idea to avid confusion with other 
devices?

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Daniel 
Carrion
Sent: Monday, August 19, 2013 5:08 AM
To: Raistmer the Sorcerer
Cc: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] Serious bug in BOINC android.

I wonder if it's worth adding a bit of code for Android build to allow
users to inject a name like NativeBOINC does?


On Mon, Aug 19, 2013 at 6:41 PM, Raistmer the Sorcerer raist...@mail.ruwrote:

   Since every android machine has the same hostname localhost, I
  think any new connection by an identical device will seem as an attempt
 to
  reattach a device.  I don't know the full list of properties compared,
 so I
  don't know if memory or OS revision is one of them or not.  I hadn't
  noticed it because all my hosts have different CPU revisions or a
 different
  number of processors.
 
 localhost can be changed if user names its device (just as default
 windows host name can be changed).
 And new name will be visible in hosts list on project web page. I renamed
 most of my Android devices and new names are vidible for me on project's
 hosts web page.
 Moreover, I have 2 identical G-tabs, only names are different. And they
 visible on SETI@home project as 2 different devices from very beginning
 of their use.


 
 ___
 boinc_dev mailing list
 boinc_dev@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.

___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] CPU throttling and GPU apps

[McLeod, John]

The only problem is that there is no real standard for determining the 
temperature of the CPU (every manufacturer seems to have done it differently.  
Speed fan is keeping up with this, it is probably not something that BOINC 
developers really should be attempting to do.

-Original Message-
From: Charles Elliott [mailto:elliott...@verizon.net] 
Sent: Tuesday, July 09, 2013 7:15 AM
To: McLeod, John; 'David Anderson'; boinc_dev@ssl.berkeley.edu
Subject: RE: [boinc_dev] CPU throttling and GPU apps

Three of my computers are in a small second floor bedroom with an asphalt
roof and a box fan placed in a window close to the ground for its only
ventilation.  During the afternoons room temperatures are 95 F or higher,
too much for the computers.

If heat is the problem, it makes more sense to measure CPU/GPU temperatures
and reduce the load on a device if the temperature rises above a set point,
and increase it if the temps go below a lower set point.

I wrote a Java program that does exactly that.  It accesses temperatures by
parsing a SpeedFan logging file on each computer, and affects Boinc by
changing the ncpusN/ncpus line in cc_config.xml and issuing a
read_cc_config RPC.  Something similar might be possible for the GPUs.

It seems to work.  Yesterday, its first day of operation, during the
afternoon it lowered the CPUs used of the three computers from 8 to 6, and
then last night, starting about 10:30, it slowly raised them back to 8,
where it is now.

Charles Elliott

 -Original Message-
 From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf
 Of McLeod, John
 Sent: Monday, July 8, 2013 11:21 AM
 To: David Anderson; boinc_dev@ssl.berkeley.edu
 Subject: Re: [boinc_dev] CPU throttling and GPU apps
 
 How about changing it to not throttle apps that use less than the
 current throttling value?  E.g. if throttling is set at .9, don't
 throttle a task that uses .8.
 
 -Original Message-
 From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf
 Of David Anderson
 Sent: Friday, July 05, 2013 11:50 PM
 To: boinc_dev@ssl.berkeley.edu
 Subject: Re: [boinc_dev] CPU throttling and GPU apps
 
 I changed it not throttle apps that use  .5 CPUs
 -- David
 
 On 04-Jul-2013 2:38 PM, Eric J Korpela wrote:
  The only pro I can think of would be to reduce GPU use to keep
  temperature or power use down, but that would be better implemented
 as
  GPU throttling.
 
  On Thu, Jul 4, 2013 at 5:52 AM, Bernd Machenschalk
  bernd.machensch...@aei.mpg.de wrote:
  On 04.07.13 13:15, Heinz-Bernd Eggenstein wrote:
 
  I guess there are several pros and cons, e.g.:
 
  cons:
  - one one hand, GPU apps (depending on the CPU share?) get a
 higher OS
  prio (in terms of niceness) to prevent the GPU being starved.
 Throttling
  the CPU might very well cause this starvation
  - if a GPU app has a rather low CPU runtime share in the first
 place,
  further CPU throttling does not seem too useful.
  - in order to avoid GPU load to interfere with the user doing
 non-BOINC
  related stuff, there is already the setting Suspend GPU work while
  computer is in use.
 
 
  Here's one more:
 
  When not synchronized with GPU-CPU communication (kernel launches,
 data
  transfer) throtteling an App can break any running GPU task. I'm not
 sure
  whether the throtteling implementations of all BOINC Clients that
 are being
  used properly honor critical sections, nor am I that all GPU apps of
 all
  projects make proper use of these.
 
 
  pros:
  I can't think about many
 
 
  Actually I can't think about any.
 
  Best,
  Bernd
 
 
  ___
  boinc_dev mailing list
  boinc_dev@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.
  ___
  boinc_dev mailing list
  boinc_dev@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.
 
 ___
 boinc_dev mailing list
 boinc_dev@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.
 ___
 boinc_dev mailing list
 boinc_dev@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.

___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] Suggestions for resolving bug: could not connect to BOINC

[McLeod, John]

First place to start is 
http://boinc.ssl.berkeley.edu/trac/wiki/SoftwareDevelopment#

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Caterpillar
Sent: Tuesday, July 09, 2013 11:17 AM
To: boinc_dev@ssl.berkeley.edu
Subject: [boinc_dev] Suggestions for resolving bug: could not connect to BOINC

Hello, I am a Fedora user and I am active in Fedora community. I am writing
to you to get some good suggestions in fixing a bug we have on Fedora
platform. By a year we are having an annoying bug about BOINC manager.
Every single time you open it, you will get an error message about could
not connect to BOINC
https://bugzilla.redhat.com/show_bug.cgi?id=839531
Since the Fedora mantainer of BOINC is very busy and I would like to help
him and fix this bug, I need some basic infos about how to begin... because
it is the first time I try to approach in fixing a BOINC bug. My C
programming skills are medium.
This is a Fedora related bug, since I asked to other Linux users and they
don't experience this trouble.

Thank you for your time.
___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] CPU throttling and GPU apps

[McLeod, John]

How about changing it to not throttle apps that use less than the current 
throttling value?  E.g. if throttling is set at .9, don't throttle a task that 
uses .8.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of David 
Anderson
Sent: Friday, July 05, 2013 11:50 PM
To: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] CPU throttling and GPU apps

I changed it not throttle apps that use  .5 CPUs
-- David

On 04-Jul-2013 2:38 PM, Eric J Korpela wrote:
 The only pro I can think of would be to reduce GPU use to keep
 temperature or power use down, but that would be better implemented as
 GPU throttling.

 On Thu, Jul 4, 2013 at 5:52 AM, Bernd Machenschalk
 bernd.machensch...@aei.mpg.de wrote:
 On 04.07.13 13:15, Heinz-Bernd Eggenstein wrote:

 I guess there are several pros and cons, e.g.:

 cons:
 - one one hand, GPU apps (depending on the CPU share?) get a higher OS
 prio (in terms of niceness) to prevent the GPU being starved. Throttling
 the CPU might very well cause this starvation
 - if a GPU app has a rather low CPU runtime share in the first place,
 further CPU throttling does not seem too useful.
 - in order to avoid GPU load to interfere with the user doing non-BOINC
 related stuff, there is already the setting Suspend GPU work while
 computer is in use.


 Here's one more:

 When not synchronized with GPU-CPU communication (kernel launches, data
 transfer) throtteling an App can break any running GPU task. I'm not sure
 whether the throtteling implementations of all BOINC Clients that are being
 used properly honor critical sections, nor am I that all GPU apps of all
 projects make proper use of these.


 pros:
 I can't think about many


 Actually I can't think about any.

 Best,
 Bernd


 ___
 boinc_dev mailing list
 boinc_dev@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.
 ___
 boinc_dev mailing list
 boinc_dev@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.

___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] Questions around BOINC

[McLeod, John]

It is not really what is going on at the server end from the client end.  We 
know how it works overall, so we can see how the details mesh.  This would not 
really be obvious just by watching the client.

-Original Message-
From: Charles Elliott [mailto:elliott...@verizon.net] 
Sent: Friday, June 21, 2013 7:51 AM
To: McLeod, John; 'Chanda Sarkar'; 'Christian Beer'
Cc: boinc_dev@ssl.berkeley.edu
Subject: RE: [boinc_dev] Questions around BOINC

Instead of all these questions, why don't you just attach a computer to
Boinc's SETI@Home project, or another -- there are tens of them -- and watch
how it works.  Your questions seem to fundamental and trivial to those who
have been using Boinc for years.

Charles Elliott

 -Original Message-
 From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf
 Of McLeod, John
 Sent: Thursday, June 20, 2013 11:53 AM
 To: Chanda Sarkar; Christian Beer
 Cc: boinc_dev@ssl.berkeley.edu
 Subject: Re: [boinc_dev] Questions around BOINC
 
 Each work unit will be made into one or more identical tasks depending
 on the initial replication setting.  Each of these tasks will be sent
 to a different computer.  When the task on an individual computer is
 completed, the result of the computation will be uploaded.  If more
 than one task was sent, the results will be compared in the validator.
 
 Some applications can do a quick reverse computation to see if a result
 is valid or not, others require two results of the same computation to
 compare to each other.  Unfortunately, individual computers cannot be
 trusted as they may overheat, be overclocked, have a random computation
 error, or (grumble) be maliciously modified so that credit accumulates
 faster.  Hence the need for validation of computational results.
 
 SETI Classic had a handful of clients that were modified such that they
 would return pre-calculated results as quickly as the system would
 allow so that they would gain credits faster - thus potentially harming
 the science being done.  This handful of clients returned a large
 number of invalid results.  The same thing could happen in BOINC if
 there is no validation.
 
 -Original Message-
 From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf
 Of Chanda Sarkar
 Sent: Thursday, June 20, 2013 7:42 AM
 To: Christian Beer
 Cc: boinc_dev@ssl.berkeley.edu
 Subject: Re: [boinc_dev] Questions around BOINC
 
 Hi,
 
  Thanks for the information! But the URL that I read -
 http://boinc.berkeley.edu/trac/wiki/JobIn , says, in *JOB *section* -
 '*One
 or more *results*, each of which describes an instance of a
 computation,
 either unstarted, in progress, or completed. *The BOINC client software
 refers to results as tasks**'. *So, one work unit(job) may be
 associated
 with one or more results? More over what is the exact meaning of result
 file is it a single output file or a collection of output files that
 refers
 to single work unit.
 
 One more question that comes into my mind comes after reading -
 http://www.irelandboinc.com/how-boinc-works.
 Under Credit section - 'Each work unit may be sent to several
 computers'
 and 'When at least two results have been returned, the server compares
 them. If the results agree, then users are granted credits.'.
According to this statement, same work unit(job) are
 sent to
 different machines for computation. So, does that mean same work
 unit(or
 job) may span multiple machines?.. which would contradict to the
 earlier
 mail.
 
 Do correct me if I am wrong
 
 Thanks,
 Chanda
 
 
 
 On Thu, Jun 20, 2013 at 2:36 PM, Christian Beer djangof...@gmx.net
 wrote:
 
  Hi,
 
  I'm not Rom but I hope I can help you too.
 
  1. That scenario is already the principal design behind BOINC. Once a
  task is associated with a host (gets send) this will not change. So
 in
  your example: 't1' will only be processed on 'M1', if for some reason
  this is not succesfull the server will create 't3' and send this to
 'M3'.
 
  2. What you see in your Screenshot is exact the behaviour I described
  above. 't1' was created when the workunit (job) was created (because
 of
  initial_replication=1) it got send to Computer 1619876 ('M1') on June
 13
  later (on June 17) this computer reported that it has detached from
 the
  project and discarded all remaining tasks. So the server created
 another
  task ('t2') and it got send to 'M2' (1518828). This is also a normal
  BOINC behaviour. If the first task is successfull there will be no
  second task because the workunit is considered complete if one task
 is
  succesfull (minimum_quorum=1).
 
  Regards
  Christian
 
  Am 20.06.2013 10:53, schrieb Chanda Sarkar:
   Hi Rom,
  
I have two questions around BOINC -
  
1. Is there any chance that single task within a work unit is
   processed only once on a single machine and no other machine.
   For example :
   Assume there is a work unit 'A' that has two tasks 't1' and 't2'.
 't1

Re: [boinc_dev] Can we do shared memory with no disk usage?

[McLeod, John]

It is easy to set check pointing to a longer time.  There is already a setting 
available for this.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Steffen Möller
Sent: Monday, June 17, 2013 4:04 AM
Cc: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] Can we do shared memory with no disk usage?



 Gesendet: Montag, 17. Juni 2013 um 08:46 Uhr
 Von: David Anderson da...@ssl.berkeley.edu

 Manager/client communication uses TCP - no disk I/O.
 So the possible sources of large disk I/O are:

 1) checkpoint or output file generation by apps
 2) writing of client_state.xml (or maybe other files)
 by the BOINC client

The checkpointing and the client_state.xml for my 24/7
machines I would very much like to just switch off or
have updated only every hour or have their update initiated
only upon request by the boinc client.

 3) client/app communication via memory-mapped files.
 According to my calculations,
 this should generate less than 1 MB/Hour per task.
 Note: we use memory-mapped files (mmap) instead of
 pure shared memory segments (shmget)
 because Mac OS X has a system-wide limit of 32 shared-mem segments,
 and some Linux systems have limits.
 Maybe there's a way to configure memory-mapped files
 to not write back to the disk file, but I can't find one.

It should be the shm_open with mmap together, i.e. just substituting the
call to open that BOINC currently performs with shm_open.
From http://pubs.opengroup.org/onlinepubs/009695399/functions/shm_open.html

fd = shm_open(/myregion, O_CREAT | O_RDWR, S_IRUSR | S_IWUSR);
rptr = mmap(NULL, sizeof(struct region),
   PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);

Should be disk-free, with /myregion only having a symbolic meaning.
Here
http://stackoverflow.com/questions/4836863/shared-memory-or-mmap-linux-c-c-ipc
I also found a reference to an interesting IPv6 to localhost with multicast 
idea,
No idea if that is applicable for BOINC. The trend is more towards 
open_shm+mmap.

Many thanks for the swift reply

Steffen


 Can someone investigate which of these is the source of the large I/O?

 -- David

 On 16-Jun-2013 11:03 AM, Steffen Möller wrote:
  Hello,
 
  iostat gives rather drastic values for the amount of data that is written 
  to disk by
  BOINC and/or its applications.  Some good fellow once crafted a but report 
  about it
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636075
  and my own reply was not overly helpful at the time. To reduce the IO 
  overhead is
  certainly helpful. Reduced latency is one thing, but with an outreach to 
  the mobile
  world there are many SSD / flash device users who care so much about write 
  endurance.
 
  It kept bugging me, and quite a while back it came to me that this may not 
  be
  because of the application's work but instead be mere overhead of a file 
  based
  communication between the app and the boinc-client / boinc-manager. I just 
  never
  got around chasing this up, also having read so often about communication 
  done via
  shared memory, which should not need much IO, and if so, then not with disk 
  devices
  but something like tmpfs. Let's see how it is done, I just thought.
 
   From what I found, there are two functions to create shared memory in 
  BOINC, both in
  lib/shmem.cpp. One is through
 create_shmem
  which internally uses shmget and should be just fine. The other is
 create_shmem_mmap
  which internally uses mmap - which can be memory-only or not. The early 
  mmap allowed the
  memory only (anonymous) sharing only for forks of the same process. For 
  anything else
  one needs to pass a regular file descriptor to communicate to mmap from/to 
  where to get/write
  the data. Newer years brought the function shm_open 
  (http://linux.die.net/man/3/shm_open),
  which creates an entry in /dev/shm if I got this right, and allows 
  forwarding this fd for
  a complete in memory-only communication with a (pseudo-)file-mapping mmap.
 
  In today's BOINC code, mmap is called with a file descriptor created with 
  open (no
  typo, it is from boinc/lib/std_fixes.h), which itself calles open64 as 
  defined in
  /usr/include/fcntl.h (?) and expects to create a regular file.
 
  I admit not to know too much about the consequences of a memory-only 
  communication for BOINC.
  It is not more than a couple of megs every second indicating the status of 
  the applications,
  right? So not too much memory would be taken. With checkpointing performed 
  independently,
  this could then work just fine. Is there something I did not see? I am 
  otherwise much tempted
  to address it and see how far I get. Some extra thinking is required to 
  maintain a
  compatibility between the BOINC client and older statically linked 
  applications. With Debian
  we have the applications dynamically linking to the same BOINC library as 
  the BOINC client.
  Promising enough? Please direct me.
 
  

Re: [boinc_dev] Questions around BOINC

[McLeod, John]

Each work unit will be made into one or more identical tasks depending on the 
initial replication setting.  Each of these tasks will be sent to a different 
computer.  When the task on an individual computer is completed, the result of 
the computation will be uploaded.  If more than one task was sent, the results 
will be compared in the validator.  

Some applications can do a quick reverse computation to see if a result is 
valid or not, others require two results of the same computation to compare to 
each other.  Unfortunately, individual computers cannot be trusted as they may 
overheat, be overclocked, have a random computation error, or (grumble) be 
maliciously modified so that credit accumulates faster.  Hence the need for 
validation of computational results.

SETI Classic had a handful of clients that were modified such that they would 
return pre-calculated results as quickly as the system would allow so that they 
would gain credits faster - thus potentially harming the science being done.  
This handful of clients returned a large number of invalid results.  The same 
thing could happen in BOINC if there is no validation.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Chanda 
Sarkar
Sent: Thursday, June 20, 2013 7:42 AM
To: Christian Beer
Cc: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] Questions around BOINC

Hi,

 Thanks for the information! But the URL that I read -
http://boinc.berkeley.edu/trac/wiki/JobIn , says, in *JOB *section* - '*One
or more *results*, each of which describes an instance of a computation,
either unstarted, in progress, or completed. *The BOINC client software
refers to results as tasks**'. *So, one work unit(job) may be associated
with one or more results? More over what is the exact meaning of result
file is it a single output file or a collection of output files that refers
to single work unit.

One more question that comes into my mind comes after reading -
http://www.irelandboinc.com/how-boinc-works.
Under Credit section - 'Each work unit may be sent to several computers'
and 'When at least two results have been returned, the server compares
them. If the results agree, then users are granted credits.'.
   According to this statement, same work unit(job) are sent to
different machines for computation. So, does that mean same work unit(or
job) may span multiple machines?.. which would contradict to the earlier
mail.

Do correct me if I am wrong

Thanks,
Chanda



On Thu, Jun 20, 2013 at 2:36 PM, Christian Beer djangof...@gmx.net wrote:

 Hi,

 I'm not Rom but I hope I can help you too.

 1. That scenario is already the principal design behind BOINC. Once a
 task is associated with a host (gets send) this will not change. So in
 your example: 't1' will only be processed on 'M1', if for some reason
 this is not succesfull the server will create 't3' and send this to 'M3'.

 2. What you see in your Screenshot is exact the behaviour I described
 above. 't1' was created when the workunit (job) was created (because of
 initial_replication=1) it got send to Computer 1619876 ('M1') on June 13
 later (on June 17) this computer reported that it has detached from the
 project and discarded all remaining tasks. So the server created another
 task ('t2') and it got send to 'M2' (1518828). This is also a normal
 BOINC behaviour. If the first task is successfull there will be no
 second task because the workunit is considered complete if one task is
 succesfull (minimum_quorum=1).

 Regards
 Christian

 Am 20.06.2013 10:53, schrieb Chanda Sarkar:
  Hi Rom,
 
   I have two questions around BOINC -
 
   1. Is there any chance that single task within a work unit is
  processed only once on a single machine and no other machine.
  For example :
  Assume there is a work unit 'A' that has two tasks 't1' and 't2'. 't1' is
  send to machine 'M1' for processing and  't2' is send to machine 'M2' for
  processing. Is it a possibility that 't1' which is processed on machine
  'M1' will never be processed for any other machine ?
 
 
   2. Is there any possibility that task within a work unit may be
  generated with unpredictable time span which could be a day or more? I am
  attaching a snap shot for the same
  URL : http://screencast.com/t/HOvebaVpP0N
  In the above image it is seen for  a work unit
  'cryo_bk__chain_I_subrun_000_SAVE_ALL_OUT_IGNORE_THE_REST_86456_479' that
  has two tasks. One is created on 13th June 2013 and other on 17th June
  2013. Is there a possibility that tasks within work units can be created
  with unpredictable time span? Please correct me if I am wrong.
 
 
  Thanks,
  Chanda
  ___
  boinc_dev mailing list
  boinc_dev@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.

Re: [boinc_dev] Validator problem

[McLeod, John]

Different processors can come up with slightly different results for each step 
in a long calculation.  If you allow processors of different types to crunch 
the same work unit, then you will have to write some fuzziness into your 
validator.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
radim.vanco
Sent: Tuesday, June 04, 2013 7:26 AM
To: boinc_dev@ssl.berkeley.edu
Subject: [boinc_dev] Validator problem

Hi,
I have one problem with this custom validator. It is based on custom validator 
on wiki, it compares three numbers with decimal point and check structure 
before it. It works fine but after some time (two - four  days) it will start 
to mark all results as inconclusive. If I test it on only a few WUs it works 
exactly as I want but when there are many results then it starts after few days 
mark everything as invalid. Does anyone know what could cause the problem? I 
attached source code of the validator.

Radim



___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] task

[McLeod, John]

What tasks get started is based on how much time the projects have gotten in 
comparison to their resource shares.  If a project needs high priority to 
finish in time to report tasks before deadline, that project will get less time 
in the near future (possibly by not allowing work fetch for a bit).

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Toralf 
Förster
Sent: Thursday, May 30, 2013 5:07 AM
To: boinc_dev@ssl.berkeley.edu
Subject: [boinc_dev] task

Since few weeks I'm observing a behaviour that at my 4-core CPU with 3
projects the current running tasks are not arbitrarly choosen from alle
projects, instead often there are 2 task of one project and 2 of
another project (nearly exact same start time), but rarely 2 task of 1
and 1 task of each of the other 2 projects.

Is this just selective attention of mine ?

https://boinc.berkeley.edu/dev/sim_web.php?action=show_scenarioname=105

(screen shot attached therefore 2 devs on Cc:)

-- 
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] possible typo in configure.ac

[McLeod, John]

Pretty much standard for command files...

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Toralf 
Förster
Sent: Thursday, May 16, 2013 3:33 PM
To: Eric J Korpela
Cc: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] possible typo in configure.ac

On 05/16/2013 08:38 PM, Eric J Korpela wrote:
 That x is required.  They are there in case the tested variable is empty
 (in which case it's test x = x  rather than the syntax error test =
ick - of course :-)

-- 
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] GPU and service under Windows

[McLeod, John]

Not without re-writing some of the code.  The problem is that Windows Vista, 7, 
and 8 all run services as desktop 0, and the first user logged in gets desktop 
1.  Yes, it is possible to write code to run things in the user's context 
controlled by the server, however, it is a fair amount of work to do so.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
slauz...@techcrime.ca
Sent: Friday, May 10, 2013 12:45 PM
To: boinc_dev@ssl.berkeley.edu
Subject: [boinc_dev] GPU and service under Windows

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

___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] Scheduler returns No end tag

[McLeod, John]

There are two things that might be happening.  Both in the same area.  CData 
contains some XML -- which the parser is supposed to ignore.  It is also 
possible that, as Nicolas has already noted, that it may be the extreme length 
of one of the xml elements that may be a problem.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Nicolás Alvarez
Sent: Wednesday, May 08, 2013 1:34 PM
To: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] Scheduler returns No end tag

The XML is valid, so it's not a bug in the client. The only
potentially-problematic thing I see is long lines in the stderr text,
which the so-called XML parser in BOINC might be mishandling.

PS: Note that you just publicly posted the account key of this user.

-- 
Nicolás

2013/5/8, Nx Hien diablo_doo...@yahoo.com:
 Dr. Anderson,

 A volunteer has just uploaded this file for us, he said his client is
 currently displaying the No end tag error message.

 Best regards,
 Hien


 
  From: David Anderson da...@ssl.berkeley.edu
 To: boinc_dev@ssl.berkeley.edu
 Sent: Thursday, May 2, 2013 8:03 PM
 Subject: Re: [boinc_dev] Scheduler returns No end tag


 Hien:
 Try contacting the volunteers and ask them for the request file.
 There must be something in it that the server can't parse.
 -- David

 On 02-May-2013 5:35 PM, Nx Hien wrote:
 Dr. Anderson,

 I could not get the request files at the time of error since they are on
 the
 client side but I instead attempted to make to server to write out the
 content of the request at the time of error (attached). The 1st half of
 the
 request is missing. This problem happens to multiple clients.

 Best regards, Hien
___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] Workunits no longer usable

[McLeod, John]

SETI Beta is for testing new versions for the S@H applications.  Things *will* 
go wrong.  If you don't like testing software, then this is not the project for 
you.

Work units are removed from the active DB after some time.  Any credit earned 
stays.  This saves DB space.

The daily quota is reduced on error, and increased (to some maximum) on success.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Charles Elliott
Sent: Tuesday, May 07, 2013 10:08 AM
To: boinc_dev@ssl.berkeley.edu
Subject: [boinc_dev] Workunits no longer usable

Hello:

 

The S@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 wrong.   Now  a
computer that processed 790 

WUs yesterday has only 501 WUs total, some of which are Astropulse, so my
statistics program says I have 

about 0.91 days' supply.  The server says I have exceeded my quota of 35
WUs/day (35???) and won't give me 

any more, and sometime in the middle of the night it decided Your
app_info.xml file doesn't have a usable 

version of SETI@home v7.  It is Tuesday, the server will be down all day,
and it will be sometime late in the 

evening before I can download any more WUs.

 

Several weeks ago a similar incident happened.  I was
carrying something heavy and bumped into the 

computer that was processing S@H WUs.  Boinc must have been writing the
client_state file at the time because 

it was clobbered and Boinc would not run.  For some reason client_state_prev
was unacceptable also.  I make a 

copy of the client_state file every time a WU finishes.  I do that because
my statistics program was having trouble 

finding out which GPU the WU was processed on, and I needed to see what
client_state file it was looking at.  

Thus I have a month's supply of client_state files for every computer.  So
to fix the clobbered client_state file, 

I took the one from the previously finished WU - it was literally seconds
old - and used it to replace the clobbered 

client_state file.  Boinc objected and flushed all the WUs.  

 

There are three facts of which you are obviously unaware:

 

1.   It is intensely humiliating to experience the loss of thousands of
workunits, especially after one has spent hours trying to avoid that exact
situation, and after taking exactly the same actions that had avoided that
loss previously.

2.   You could not realize how much we users have invested in S@H.
First, it costs about $70 a month to process S@H WUs on a computer with a
modern CPU and two medium-sized GPUs.  Second, it takes about one-half to an
hour a day to check each computer to see that it is operating OK.  Third,
there is a huge emotional investment in competing for credits that have no
extrinsic value, which is compounded by the fact that, for whatever reason,
S@H is not analyzing the data we return to it; there have been no results
published since about 2007, that I know of.  So yeah, we fight tooth and
nail for workunits and credits because there is no other measure of progress
and success.  S@H is not a no-holds-barred, all's fair war between users and
the server; it is supposed to be a cooperative venture to find evidence of
extraterrestrial life.

3.   Up until about the 1920s the United States was a Christian country.
While it may seem unfair, until the 20's if a person did not understand the
Christian paradigm, he or she simply could not compete.  That changed in the
30's, in part, I believe, because as a highly industrialized country and a
world leader we had to change the societal emphasis from religion and
ethical behavior to technological competence.  Nevertheless, under the
Christian paradigm when a person makes a mistake God no longer sends a
plague of locusts, huge floods, or asks for a human sacrifice; under the new
deal, He sends a message telling the person what is wrong and how to fix it.
If you want to see this exact same point in secular language, then read Dale
Carnegie's How to Win Friends and Influence People. In any case, 

Re: [boinc_dev] twitter bootstrap and boinc

[McLeod, John]

The original reason for splitting them is that they have different posting 
rules.  Anyone can post to the help desk as you might need help getting started.

Many projects have limited the ability to post to the rest of the forums to 
active users (RAC  X).

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Maureen Vilar
Sent: Monday, May 06, 2013 2:20 PM
To: Francisco Sanz García
Cc: boinc_dev; BOINC Projects
Subject: Re: [boinc_dev] twitter bootstrap and boinc

It looks very cool and clean. I like it.

If you can put the Message Boards and Questions and Answers all on one
page, that would be much better. Otherwise it's difficult for new users to
navigate and find the most suitable place to post. (Personally I think that
the entire BOINC forums should be on one page by default so that project
admins don't have to join the two parts up.)

I see that whether I choose German, Spanish, French, Dutch or Catalan as my
language, considerable parts of the BOINC website and forums remain in
English. Some of these languages have for a long time had very assiduous
translators. Does anyone know what the problem is?


On Mon, May 6, 2013 at 6:01 PM, Francisco Sanz García fras...@bifi.eswrote:

 Hello

 We have this new look and feel almost in production, please visit
 http://registro.ibercivis.es, we added some functionalities like share
 your
 credits to facebook and twitter (once you're registered).  any feedback?

 regards

 Francisco


 2013/5/3 Francisco Sanz García fras...@bifi.es

  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
 
 ___
 boinc_dev mailing list
 boinc_dev@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.

___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

[boinc_dev] rr_sim and work fetch

[McLeod, John]

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 now has to cope with a staggered start for the remaining Non 
High Priority tasks.  Multi CPU tasks would not be allowed to start until such 
a time as sufficient CPUs were available.  Exit the loop when all CPUs are busy 
with EDF work for minimum work  buffer time.  Gaps is information about forced  
gaps due to EDF tasks and multi CPU tasks.  When done, thee will be information 
about saturation of all CPUs and forced gaps up the minimum work queue.  This 
can be used to generate appropriate work fetches.

Pseudo code:

Structure gap
{
Double duration;
Double start_time;
Int n_cpus;
}

Initialize tasks for a new rr_sim run
Bool newTasksMarkedEDF = false;
Double CPUSEDFBusyTill = now();
Double * CPUEDFBusyArray = new double(n_cpus);
Initialixe CPUEDFBusyArray to all 0;
Std::arraygap gaps;
Do
{
newTasksMarkedEDF = rr_sim(CPUEDFBusyArray, 
gaps);
if (newTasksMarkedEDF)
CPUSEDFBusyTill = 
edf_sim(CPUEDFBusyArray, gaps);
}
While (newTasksMarkedEDF  CPUSEDFBusyTill  now() + min_work_buf)

Run time analysis:
Best case:  No tasks needing EDF - single run of rr_sim.

Typical case ought to be a handful of runs through the loop.  We might want to 
cap the number of runs though as:

Worst case:  One run of each per task.

NOTE:  Projects would be marked with the number of tasks that need to run EDF 
by rr_sim. Edf_sim and rr_sim both get shorter on each run as any task already 
marked as consumed by edf_sim would not need to be inspected again.  It is 
already in the EDF array someplace.  Both edf_sim and rr_sim can note a forced 
gap due to EDF requirements.  In both cases, it would be because there was not 
enough work of a low enough count of CPUs to fill the hole.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] [boinc_projects] BOINC 7.0.64/7.0.65 released for the public

[McLeod, John]

A suggestion for the initial estimate of tasks 2 through N of NCI tasks for any 
particular application is to use the mean of the elapsed wall time for all 
tasks for that application.  Note that this would only apply while the reported 
% complete is 0.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of David 
Anderson
Sent: Thursday, April 25, 2013 4:09 AM
To: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] [boinc_projects] BOINC 7.0.64/7.0.65 released for the 
public

Actually, since NCI jobs don't use much CPU,
using FLOPS info to compute time remaining is the wrong idea.

I changed things so that for NCI apps, it will use an estimate based on
elapsed time / fraction done
If fraction_done is zero, it will show ---

-- David

On 23-Apr-2013 1:32 PM, Carl Christensen wrote:
 That's cool.  One thing I should report, not particularly for this version
 but it's been in BOINC clients for quite awhile - is that it seems the
 workunit remaining calculation for non-CPU intensive apps is really off.  It
 used to be that it would report based on elapsed run-time and fraction done,
 which is sensible, i.e. QCN workunits would report (soon after starting) that
 24 hours remain.  For awhile it reports 800 hours remain (over a month),
 which I guess may be a flop estimate I copied over from my old CPDN work
 units! ___ boinc_dev mailing
 list boinc_dev@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.

___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] BOINC 7.0.64/7.0.65 released for the public

[McLeod, John]

I found another glitch with work fetch.

The case is 0.2 days of minimum work buffer,3 days of extra work.  A CPDN task 
with another month of work remaining and a deadline in 15 days - high priority 
single CPU.  1 task from a multi CPU project that is scheduled for all CPUs on 
the system.  No other tasks.

The high priority CPDN task is running, one CPU is idle, and NO work fetch is 
being attempted.

The way out.  Micromanagement.  Disable work fetch for the multi CPU project.  
Suspend the multi CPU task.  Wait for more work to be fetched.  Resume the 
multi CPU task, enable work fetch for the multi CPU project.  Repeat as needed 
for the next month or so.
-Original Message-
From: boinc_alpha [mailto:boinc_alpha-boun...@ssl.berkeley.edu] On Behalf Of 
Rom Walton
Sent: Tuesday, April 23, 2013 3:41 PM
To: boinc_annou...@ssl.berkeley.edu
Cc: boinc_dev@ssl.berkeley.edu; boinc_proje...@ssl.berkeley.edu; BOINC Alpha
Subject: [boinc_alpha] BOINC 7.0.64/7.0.65 released for the public

Howdy Folks,

BOINC 7.0 is now available for public use.  This release includes
numerous bug fixes and new features.

We would like to also thank all the testers and support people across
all the projects for their tireless efforts to make BOINC the best
product it can be.

Here are the big ticket items for this release:

* Intel GPU Support
* Improved client ccheduler and work-fetch policies

Download: http://boinc.berkeley.edu/download.php
Release Notes: http://boinc.berkeley.edu/wiki/Release_Notes
Revision History: http://boinc.berkeley.edu/trac/wiki/VersionHistory

- Rom
BOINC Development Group

___
boinc_alpha mailing list
boinc_al...@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_alpha
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] question howmany BSD / Macs

[McLeod, John]

It ought to be possible to glean information about your own client base from 
the database.  Each client record has information about what type of machine it 
is.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of mark 
somers
Sent: Friday, April 19, 2013 11:10 AM
To: boinc_proje...@ssl.berkeley.edu; boinc_dev@ssl.berkeley.edu
Subject: [boinc_dev] question howmany BSD / Macs

Howmany projects / volunteers actually use BOINC with BSD and or Macs (Intel 
and or PowerPC)? 

I'm contemplating dropping the support for these architectures on our project 
because I lack Mac hardware to compile and test nowadays. I need to get rid 
of graphics from our Classical apps (cruft code and old style graphics stuff 
and hard to migrate to new style graphics allas) and update things and there 
is a lot of work involved in having to support al those different archs. 

But before I decide I'd thought I'd ask...

m.
-- 
mark somers
tel: +31715274437
mail: m.som...@chem.leidenuniv.nl
web:  http://theorchem.leidenuniv.nl/people/somers
___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] question howmany BSD / Macs

[McLeod, John]

Your bets et might be to ask one or more of the folks running stats pages such 
as boincstats.com for the information.  They have it collected for all projects 
already, and might only need a little work to put together a query.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of mark 
somers
Sent: Friday, April 19, 2013 12:21 PM
Cc: boinc_proje...@ssl.berkeley.edu; boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] question howmany BSD / Macs

 It ought to be possible to glean information about your own client base from 
 the database.
 Each client record has information about what type of machine it is.

I'm also interested in some (overall) stats of other projects. I can figure out 
things for
Leiden obviously, but if Leiden is only one of the say two projects supporting 
BSD, it might
be a shame if I would stop support for it for those I guess...

m.




___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] question howmany BSD / Macs

[McLeod, John]

They may be active and have a RAC below 100 (slow machine, or one on more than 
one project), and they may be inactive and have a RAC  100 (very active in the 
past, but have quit).

I believe rpc_time is the last contact to the scheduler for any reason.  Not 
100% on this though.

From: Jon Sonntag [mailto:j...@thesonntags.com]
Sent: Friday, April 19, 2013 12:25 PM
To: McLeod, John
Cc: mark somers; boinc_proje...@ssl.berkeley.edu; boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] question howmany BSD / Macs

The following returns 309 OS X machines on Collatz.  My assumption is that a 
RAC  100 means active which isn't 100% accurate.  Then again, does rpc_time 
get updated when they connect to get global preferences or update even if no 
new tasks is set or if no WUs are sent or received?

select count(*) from host where os_name like '%Darwin%' and expavg_credit100;



On Fri, Apr 19, 2013 at 11:11 AM, McLeod, John 
john.mcl...@sap.commailto:john.mcl...@sap.com wrote:
It ought to be possible to glean information about your own client base from 
the database.  Each client record has information about what type of machine it 
is.

-Original Message-
From: boinc_dev 
[mailto:boinc_dev-boun...@ssl.berkeley.edumailto:boinc_dev-boun...@ssl.berkeley.edu]
 On Behalf Of mark somers
Sent: Friday, April 19, 2013 11:10 AM
To: boinc_proje...@ssl.berkeley.edumailto:boinc_proje...@ssl.berkeley.edu; 
boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
Subject: [boinc_dev] question howmany BSD / Macs

Howmany projects / volunteers actually use BOINC with BSD and or Macs (Intel
and or PowerPC)?

I'm contemplating dropping the support for these architectures on our project
because I lack Mac hardware to compile and test nowadays. I need to get rid
of graphics from our Classical apps (cruft code and old style graphics stuff
and hard to migrate to new style graphics allas) and update things and there
is a lot of work involved in having to support al those different archs.

But before I decide I'd thought I'd ask...

m.
--
mark somers
tel: +31715274437tel:%2B31715274437
mail: m.som...@chem.leidenuniv.nlmailto:m.som...@chem.leidenuniv.nl
web:  http://theorchem.leidenuniv.nl/people/somers
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edumailto:boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edumailto:boinc_dev@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.

___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] A problem with memory used calculations, at, least for 64-bit Windows Vista

[McLeod, John]

A hint:

If it will run on Vista, it will almost certainly run on 7.  The API did not 
change between.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Robert 
Miles
Sent: Thursday, April 18, 2013 1:28 AM
To: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] A problem with memory used calculations, at, least for 
64-bit Windows Vista

I currently have three of the The Lattice Project 3.11 GB workunits 
running on my Windows 7 desktop with 16 GB RAM and BOINC allowed to use 
80% of it.

On the other hand, my Windows Vista desktop with 8 GB RAM and BOINC 
allowed to use 40% of it has not been able to
complete such a The Lattice Project workunit successfully for months.  
Allowing BOINC to use a larger fraction of the memory almost stops the 
execution of any programs that use the keyboard. The 3.11 GB workunits 
just cannot get enough
memory to run properly while a few 32-bit workunits are running, often 
one from Rosetta@Home that uses around 500 MB, not counting any SYSWOW64 
modules.

A few other differences noticed:  The SYSWOW64 modules for Windows 7 
(shown as svchost.exe in the Windows Task Manager if Show processes for 
all users is enabled) are only a fraction of the size of those for 
Windows Vista, which suggests that Windows 7 has them broken into 
smaller pieces so that it does not need to load as much into memory when 
only a fraction of each Windows Vista SYSWOW64 modules are used.

In other words, there is less need for separate limits for 32-bit memory 
space and 64-bit memory space under Windows 7 than under Windows Vista, 
because Windows 7 is more memory-efficient at running 32-bit programs.

Looks like a good reason to install Windows 7 on the 8 GB desktop AFTER 
I'm no longer running any programs that aren't Windows 7 compatible.

Perhaps a way to tell the BOINC client to request ONLY 64-bit workunits, 
or ONLY 32-bit workunits, would be a good temporary workaround  for this 
problem?

 Date: Sun, 14 Apr 2013 20:17:03 -0500
 From: Robert Miles robertmi...@bellsouth.net
 Subject: Re: [boinc_dev] A problem with memory used calculations, at
   least for 64-bit Windows Vista

 Not the main point I was discussing. I was writing mostly about HOW MUCH
 is loaded into memory, not where it is loaded.  32-bit workunits under
 64-bit
 Windows just won't run without any SYSWOW64 modules in memory, and
 usually need about as much memory for the SYSWOW64 modules they use as
 for the 32-bit application program.

 -Reply To -
 Date: Fri, 12 Apr 2013 16:37:48 +
 From: McLeod, John john.mcl...@sap.com
 To: Robert Miles robertmi...@bellsouth.net,
   boinc_dev@ssl.berkeley.eduboinc_dev@ssl.berkeley.edu
 Subject: Re: [boinc_dev] A problem with memory used calculations, at
   least for 64-bit Windows Vista

 Where things are loaded in memory should have no effect on reloading after a 
 checkpoint.  No application should ever store a memory pointer into a file.  
 If they do, then there is a problem with the checkpointing of that 
 application.

 -Original Message-
 From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
 Robert Miles
 Sent: Friday, April 12, 2013 11:56 AM
 To: boinc_dev@ssl.berkeley.edu
 Subject: [boinc_dev] A problem with memory used calculations, at least for 
 64-bit Windows Vista

 I've noticed the BOINC has a problem with memory used calculations under
 64-bit Windows, when running a mix of 32-bit workunits and 64-bit
 workunits.  It does not include the SYSWOW64 modules in use by the
 32-bit workunits (possibly because they are listed as being run by
 System and are not in the 32-bit memory space).

 These SYSWOW64 modules roughly double the amount of 64-bit memory space
 needed to run these 32-bit workunits.

 As a result, a 64-bit workunit can check the memory available, decide
 that it's enough, and start running.  However, if the total RAM is 8 GB
 or less, the doubling of space occupied by 32-bit workunits can exhaust
 the free memory available in 64-bit memory space before the 64-bit
 workunit reaches its first checkpoint, which puts the 64-bit workunit
 into Waiting to run state and can also push it into virtual memory.  If
 Windows does not restore it to the same addresses in 64-bit memory when
 restoring it from virtual memory (I believe I've read that it does not)
 and the application is not sufficiently location-independent, BOINC will
 restart this workunit from the beginning, and probably encounter the
 same problem again, over and over.

 Seen with:
 64-bit Windows Vista Home Premium SP2 (some of the programs I run aren't
 compatible with later Windows versions)
 8 GB RAM, but BOINC limited to using 40% of it to avoid drastic
 slowdowns of non-BOINC 32-bit programs, including one of the programs in
 the path for accepting keyboard input; motherboard will not hold any
 more RAM
 BOINC 7.0.28, but also seen with some earlier 7.0.* versions; haven't
 tried any

Re: [boinc_dev] WrapperApp questions

[McLeod, John]

The BOINC server cannot send a signal to the client.  All communications must 
be initiated by the client.  

Please don't have GPU applications that run forever, that will tend to limit 
the availability of the GPU to other projects.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Henri 
Heinonen
Sent: Sunday, April 14, 2013 5:36 AM
To: BOINC Developers Mailing List
Subject: [boinc_dev] WrapperApp questions

Hi!

How can I run a BOINC GPU application that never ends? How can I eventually
send the signal from my BOINC server to end the workunit?

I'm planning to use WrapperApp (
http://boinc.berkeley.edu/trac/wiki/WrapperApp ) to start this Windows
program: BitTornado.exe -h yourhost -u username -p password

If my worker program (BitTornado.exe) has many files and subdirectories,
how can I include them?

Is this the correct way to do the *worker_job_1.0.xml?*

job_desc
task
applicationworker/application
command_line-h yourhost -u username -p password/command_line
/task
/job_desc
___
boinc_dev mailing list
boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@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.

Re: [boinc_dev] WrapperApp questions

[McLeod, John]

There is also the problem of the scheduler on the client.  It is not set up for 
an arbitrary amount of work.

What do you tell it for the amount of work to be done, and what do you tell it 
for the deadline.  This will affect how your task and tasks from other projects 
get scheduled.

From: Jon Sonntag [mailto:j...@thesonntags.com]
Sent: Monday, April 15, 2013 10:39 AM
To: McLeod, John
Cc: Henri Heinonen; BOINC Developers Mailing List
Subject: Re: [boinc_dev] WrapperApp questions

BitTornado is a Bit Torrent client for peer to peer file sharing.  I have yet 
to see a bit torrent client that is a GPU application.

For the issue with many files and directories, you would probably want to use 
the zip file/folder features.  That way, your app only needs to include the 
name of the zip file but you can put whatever you want into it.

While what John says is true about communications being initiated by the 
client, there is a way, at least kind of
The app would have to be set up to do trickle updates so the client will get 
credit every so often.  I'm not sure whether trickle credit can be done via the 
wrapper though.  You would need to have some type of daemon  run on the server 
which can cancel the WUs.  when you want them to stop.  You should also 
consider awarding credit from the time of the last trickle update to the time 
the WU was cancelled by the server.  So, the server can't make it stop 
immediately.  It would have to wait for the client to do a scheduled update.  
It isn't a perfect solution, but that might get you started.

Jon Sonntag

On Mon, Apr 15, 2013 at 8:56 AM, McLeod, John 
john.mcl...@sap.commailto:john.mcl...@sap.com wrote:
The BOINC server cannot send a signal to the client.  All communications must 
be initiated by the client.

Please don't have GPU applications that run forever, that will tend to limit 
the availability of the GPU to other projects.

-Original Message-
From: boinc_dev 
[mailto:boinc_dev-boun...@ssl.berkeley.edumailto:boinc_dev-boun...@ssl.berkeley.edu]
 On Behalf Of Henri Heinonen
Sent: Sunday, April 14, 2013 5:36 AM
To: BOINC Developers Mailing List
Subject: [boinc_dev] WrapperApp questions

Hi!

How can I run a BOINC GPU application that never ends? How can I eventually
send the signal from my BOINC server to end the workunit?

I'm planning to use WrapperApp (
http://boinc.berkeley.edu/trac/wiki/WrapperApp ) to start this Windows
program: BitTornado.exe -h yourhost -u username -p password

If my worker program (BitTornado.exe) has many files and subdirectories,
how can I include them?

Is this the correct way to do the *worker_job_1.0.xml?*

job_desc
task
applicationworker/application
command_line-h yourhost -u username -p password/command_line
/task
/job_desc
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edumailto:boinc_dev@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.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edumailto:boinc_dev@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.

___
boinc_dev mailing list
boinc_dev@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.