I guess it's always good to start by checking the defined error codes when
you get an error code, go figure.
Thanks.
On Tue, Aug 18, 2009 at 8:14 PM, David Anderson wrote:
> #define ERR_FILE_TOO_BIG-131
>// an output file was bigger than max_nbytes
>
> Jeremy Cowles wrote:
>
>> I'm spor
#define ERR_FILE_TOO_BIG-131
// an output file was bigger than max_nbytes
Jeremy Cowles wrote:
> I'm sporadically getting the following error (stderr of the failed result):
>
>>
>
> 17:34:22 (2592): called boinc_finish
>
>
>
>
>
>
>
> pymw_contest_runner_15_b1250638070_0_0
>
>
I'm sporadically getting the following error (stderr of the failed result):
>
17:34:22 (2592): called boinc_finish
pymw_contest_runner_15_b1250638070_0_0
-131
>
Is this an indicator that the work unit could not be uploaded?
This seems strange because both machines are on a LAN in
Nicolás Alvarez wrote:
> The robustness principle is often misunderstood. The idea is that, given
> invalid input data, it shouldn't *crash*. Which doesn't mean it should behave
> as if the invalid data wasn't there.
>
> a...@home, for example, crashes with a segmentation fault if given --nthre
El Martes 18 Ago 2009 20:53:50 Lynn W. Taylor escribió:
> Nicolás Alvarez wrote:
> > El Martes 18 Ago 2009 20:45:19 Lynn W. Taylor escribió:
> >> No, I don't.
> >>
> >> It seems that you're arguing that the BOINC science applications should
> >> be fragile -- that they should expect a pristine and
Is Linux going to get a stable 6.6 version?
--
~Kathryn
___
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
Nicolás Alvarez wrote:
> El Martes 18 Ago 2009 20:45:19 Lynn W. Taylor escribió:
>> No, I don't.
>>
>> It seems that you're arguing that the BOINC science applications should
>> be fragile -- that they should expect a pristine and unchanging
>> environment and not try to anticipate the inevitable
El Martes 18 Ago 2009 20:45:19 Lynn W. Taylor escribió:
> No, I don't.
>
> It seems that you're arguing that the BOINC science applications should
> be fragile -- that they should expect a pristine and unchanging
> environment and not try to anticipate the inevitable errors.
>
> I can't say it bett
No, I don't.
It seems that you're arguing that the BOINC science applications should
be fragile -- that they should expect a pristine and unchanging
environment and not try to anticipate the inevitable errors.
I can't say it better than Jon Postel: be conservative in what you do,
be liberal in
El Martes 18 Ago 2009 20:25:09 Lynn W. Taylor escribió:
> Which is more surprising to the end-user:
>
> - Crashing without warning (with our without notifying the project)?
>
> - Quietly handling a new parameter?
>
> Seems an easy choice.
What do you mean with crashing "without warning"? Would you
I'd like to question the whole idea of overcommitment.
When the app is multithreaded, but the internal implementation is not
data-parallel, i.e. it requires sync b/w threads and works by phases, the
slowdown will not be 1.5, but rather the performance of the slowest thread.
Typically with multith
Which is more surprising to the end-user:
- Crashing without warning (with our without notifying the project)?
- Quietly handling a new parameter?
Seems an easy choice.
Nicolás Alvarez wrote:
> El Martes 18 Ago 2009 20:13:19 Lynn W. Taylor escribió:
>> There is no reason to *not* correctly hand
El Martes 18 Ago 2009 20:13:19 Lynn W. Taylor escribió:
> There is no reason to *not* correctly handle "surprising" command line
> options.
There is no reason for the client to mess with data given by the project
before handing it to the app. What next, the client adding tags to XML input
files
In this kind of context, anything else is really sloppy programming.
There is no reason to *not* correctly handle "surprising" command line
options.
... especially if the projects can change them.
Nicolás Alvarez wrote:
> El Martes 18 Ago 2009 19:50:52 Kamran Karimi escribió:
>> This works fine
El Martes 18 Ago 2009 19:50:52 Kamran Karimi escribió:
> This works fine if the app treats such argument as optional. So BOINC apps
> should just ignore any command line options they don't understand. Projects
> can change the name of these arguments on the server, so a clash can be
> avoided.
Exa
This works fine if the app treats such argument as optional. So BOINC apps
should just ignore any command line options they don't understand. Projects can
change the name of these arguments on the server, so a clash can be avoided.
-Kamran
-Original Message-
From: boinc_dev-boun...@ssl
El Martes 18 Ago 2009 17:12:43 Eric J Korpela escribió:
> I have a couple thoughts. I agree that it's probably better to
> overcommit in cases like this. Haven't been following the discussion
> closely, so maybe these have been suggested.
>
> 0) Multithreaded applications should all have a -num_
On Tue, Aug 18, 2009 at 1:33 PM, David Anderson wrote:
> I don't want to require apps to be able to dynamically change their
> parallelism.
> This would greatly increase the difficulty of developing multithread apps.
It depends to a large extent on the app. But I agree it shouldn't be
required.
BOINC allows computation or networking to be disabled by setting the
time range to 24:00-00:00 but the advanced preferences dialog gives an
invalid format error because the validation in wxDateTime::ParseFormat()
only allows for hours up to 23. At the moment the only way to set the
start and s
I don't want to require apps to be able to dynamically change their parallelism.
This would greatly increase the difficulty of developing multithread apps.
Also I'd like to avoid running apps at different priorities.
That would make BOINC more obtrusive (real or perceived) than it is now.
I'm che
I have a couple thoughts. I agree that it's probably better to
overcommit in cases like this. Haven't been following the discussion
closely, so maybe these have been suggested.
0) Multithreaded applications should all have a -num_threads command
line option that sets the maximum number of threa
A random thought.
Have a "Scheduler" at boinc.ssl.berkeley.edu.
Have the users that want to work on TRAC actually attach to the Project.
Now you have the CPID and can look up the CobbleStone contribution of those
users for all projects.
Set a minimum contribution for the creation of a TRAC tick
There is a newer spam filter for Trac that supports Captcha.
- Rom
-Original Message-
From: boinc_dev-boun...@ssl.berkeley.edu
[mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Eric Myers
Sent: Tuesday, August 18, 2009 2:38 PM
To: David Anderson (BOINC)
Cc: BOINC Developers Mai
On Tue, 18 Aug 2009, David Anderson wrote:
>
> We're looking at upgrading to the current version of trac (0.11)
> which may have better spam-prevention features.
If the newer Trac does not prevent this, another way to prevent such spam
is to require some kind of approval for creating new Trac acc
Best would be to allow tasks to indicate "flexible" resource usage and in
that case, have BOINC suggest a number of CPUs to consume. In that case,
if the tasks were tagged as flexible, the resource scheduler would indicate
that the 1 CPU task gets a CPU task, and a flexible task gets 3 CPUs.
This
Consider this case:
a 4-CPU system with a long high-priority 1-CPU job
and a bunch of 4-CPU jobs.
With your proposal,
it would run the 1-CPU job and the other 3 CPUs would be idle for a long time.
What's the right thing to do here?
If we run the 4-CPU jobs, we reduce the amount of CPU time that
th
Another batch of trac spam appeared
even though I removed the TICKET_APPEND permission
for authenticated users.
I removed all TICKET_* permissions for the time being.
Please report bugs on this email list rather than trac.
We're looking at upgrading to the current version of trac (0.11)
which may
Oliver Bock wrote:
> Hi Rom,
>
> Do you focus on ATI's Stream SDK or OpenCL?
Neither one.
BOINC just detects the hardware and driver version,
and allocates devices.
-- David
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkele
Stream SDK.
We are code complete with the detection of the GPU and David checked in
the server changes yesterday.
- Rom
-Original Message-
From: Oliver Bock [mailto:oliver.b...@aei.mpg.de]
Sent: Tuesday, August 18, 2009 10:42 AM
To: boinc_dev@ssl.berkeley.edu
Cc: Rom Walton; boinc_p
Hi Rom,
Do you focus on ATI's Stream SDK or OpenCL?
Cheers,
Oliver
On Tuesday 18 August 2009 16:24:52 Rom Walton wrote:
> We have decided to make the 6.10 release solely focused on ATI GPU
> support, as such the remaining big ticket work-items will be punted to
> the 6.12 release.
>
>
>
> I'll
We have decided to make the 6.10 release solely focused on ATI GPU
support, as such the remaining big ticket work-items will be punted to
the 6.12 release.
I'll be creating the 6.10 branch from trunk today and begin the release
process for the 6.10 client.
We believe we can have the 6.10 re
El Martes 18 Ago 2009 04:19:04 Bruce Allen escribió:
> Thanks -- I have been thinking along similar lines. I am also
> consulting the author (who teaches at Berkeley, as a matter of fact) of
> one of the central legal papers on 'derivative works' and whether or not
> dynamic linking creates a 'der
Hi Nicolás,
Thanks for the suggestion. I'm first consulting an independent legal
expert on these questions. But I will probably double-check that
expert's response as you suggest.
Cheers,
Bruce
On 8/18/09 2:34 AM, Nicolás Alvarez wrote:
> El Lunes 17 Ago 2009 20:56:27 Eric J Korpela
Hi Eric,
Thanks -- I have been thinking along similar lines. I am also
consulting the author (who teaches at Berkeley, as a matter of fact) of
one of the central legal papers on 'derivative works' and whether or not
dynamic linking creates a 'derivative work'.
Cheers,
Bruce
On 8/18
34 matches
Mail list logo
