> OK, you had a 4 core system. How much OTHER work was there. If the amount
> of other work on the system makes the resource fraction for that project
> 0.125, then the rr_simulator comes up with an answer of 80 hours till
> completion again.
I do not at all understand bringing in "how much OTHE
El Jue 30 Abr 2009 00:24:18 Paul D. Buck escribió:
> If it is an open project idiots like me usually sign up and would
> provide you with lots of clients.
If I started getting thousands of users, I'd reach an Internet bandwidth
bottleneck quite before the DB starts feeling the load! :)
That's wh
On Apr 29, 2009, at 4:21 PM, Nicolás Alvarez wrote:
> El Miércoles 29 Abr 2009 20:09:56 Martin escribió:
>> Nicolás Alvarez wrote:
>> [...]
>>
>>> I think a good way to use the "offer, then accept/request" scheme
>>> is to
>>> first ask for an offer from *all* projects, analyze the offers,
>>
El Miércoles 29 Abr 2009 20:09:56 Martin escribió:
> Nicolás Alvarez wrote:
> [...]
>
> > I think a good way to use the "offer, then accept/request" scheme is to
> > first ask for an offer from *all* projects, analyze the offers, decide
> > what to keep, and only then contact the projects again tel
Nicolás Alvarez wrote:
[...]
> I think a good way to use the "offer, then accept/request" scheme is to first
> ask for an offer from *all* projects, analyze the offers, decide what to
> keep, and only then contact the projects again telling them if we accepted or
> rejected it. Otherwise, it's l
El Miércoles 29 Abr 2009 19:02:58 Martin escribió:
> So how did you hack around the:
>
> seti_boinc-timecvt.o: In function `short_jd_string(double)':
> timecvt.cpp:(.text+0x541): undefined reference to `strlcpy(char*, char
> const*, unsigned int)'
> [...]
>
> ?
>
> What's needed?
>
> The autoconf c
El Martes 28 Abr 2009 01:00:46 Jack Lambert escribió:
> I think that the "tasks" and "projects" tab in the advanced view
> should be integrated into each other, or the user should be given the
> option to view them as such. Basically I think that only the projects
> tab should remain, and in
Matthew, Anyone,
> Hi everyone - I've just compiled BOINC 6.7.4 on IRIX. The level of
> bastard hackery required was 6 (out of 10). I'm running s...@home right
Excellent.
So how did you hack around the:
seti_boinc-timecvt.o: In function `short_jd_string(double)':
timecvt.cpp:(.text+0x541): und
El Miércoles 29 Abr 2009 08:18:24 Martin escribió:
> A future more elaborate client scheme could be to request a number of
> WUs and then preferentially select those WUs that will make best use of
> that host's resources throughout that client's scheduler queue of cached
> tasks. For example, to ma
El Miércoles 29 Abr 2009 18:32:24 Matthew Saunier escribió:
> Hi everyone - I've just compiled BOINC 6.7.4 on IRIX. The level of
> bastard hackery required was 6 (out of 10). I'm running s...@home right
> now, as it seems to be one of the few projects that supports
> mips-sgi-irix. Please let your
Hi everyone - I've just compiled BOINC 6.7.4 on IRIX. The level of
bastard hackery required was 6 (out of 10). I'm running s...@home right
now, as it seems to be one of the few projects that supports
mips-sgi-irix. Please let your other projects know that IRIX is not dead
(yet).
So, do you guy
El Miércoles 29 Abr 2009 17:36:26 Martin escribió:
> More seriously, the main db cost is in the number of connection
> attempts. Also there is a bandwidth cost in initiating each connection.
> Hence why the results download/upload is batched as far as is possible.
Connecting to a DB isn't an impor
El Miércoles 29 Abr 2009 11:13:04 john.mcl...@sybase.com escribió:
> Negotiation involves multiple round trips to the server, multiple DB access
> spinups. This will kill some servers. This is very unlikely to occur.
The horrible DB layout currently in use (huge fragmentation mostly caused by
b
On Apr 29, 2009, at 1:36 PM, Martin wrote:
>>> Previous arguments against: Too complicated and too much server
>>> overhead.
>>>
>>> Argument for: Reduced overall server overhead, improved throughput
>>> of
>>> the Boinc server - client system, simplified client scheduler.
>>>
>> Prove that i
>> Suggestion:
>>
>> Permit negotiation between the client and server to give virtuous
>> cooperation over what tasks are downloaded when.
>
> Negotiation involves multiple round trips to the server, multiple DB access
> spinups. This will kill some servers. This is very unlikely to occur.
You'
I don't know what you said because your mail program and the mailing
list does not seem to agree with each other.
Why not baby steps...
As I said in the text file this is what you told me is the essence of
the current BOINC operational loop.
What SHOULD it be to be correct in your mind?
mai
On Apr 28, 2009, at 12:14 PM, David Anderson wrote:
> At this point I'm interested in reports of bad scheduling
> or work-fetch decisions, or bad debt calculation.
> When these are all fixed we can address the efficiency
> of the scheduling calculations (if it's an issue).
Is the point of the e
jm7
"Paul D. Buck"
To
john.mcl...@sybase.com
On Apr 29, 2009, at 6:08 AM, john.mcl...@sybase.com wrote:
> You have the logic upside down.
What logic, where?
> Your code leads to major thrashing of tasks.
Um, how... I only witch out tasks at task completion and at TSI
> Unless you check the global state, you run the risk of starting and
OK, you had a 4 core system. How much OTHER work was there. If the amount
of other work on the system makes the resource fraction for that project
0.125, then the rr_simulator comes up with an answer of 80 hours till
completion again. If the the resource fraction for that project was
0.0625, rr_
I just read this email again, i hope i did not come across wrong, if i did,
i apologize.
The intended purpose was getting the message out to volunteers and team
founders to contact local news and media in their own country, a kind of
local effort. But many volunteers and team founders, like me, ar
>> My question is - ought *every* download complete trigger work
>> scheduling ? Yes, there may be circumstances where a download gets
>> deferred for days. But when the (RPC) assignment for the task comes
>> through, can't a "time check threshold" be put on *that* task, such
>> that if all down
The following mechanism can help with this:
http://boinc.berkeley.edu/trac/wiki/ProjectOptions#Scheduling:acceleratingretries
Alejandro Rivero wrote:
> I can not follow the large discussion, but we have a problem with
> short jobs when researchers want to get the whole batch back in one
> week. Of
I can not follow the large discussion, but we have a problem with
short jobs when researchers want to get the whole batch back in one
week. Of course a solution is short deadlines. Another solution is to
start with the minimum initial results to send (one or two) and to
increase it by hand, in the
> Because scheduling ALSO takes into account the resource share, and a bit of
> a safety margin.
>
> 100 -26.4 - 1 is 72.6 hours. // the -1 is the task scheduling period. If
> this is larger, the tasks have to complete earlier. The reason is that the
> task scheduling period is the granularity
QCN is not a CPU intensive project. Non-CPU intensive projects are
scheduled to run all the time.
jm7
Jack Shultz
Doesn't QCN have peripheral accelerometers he could attach?
On Wed, Apr 29, 2009 at 7:36 AM, Martin wrote:
> We're talking high powered multi-core systems at the moment...
>
> But what of more lowly PCs?
>
> For example, what now can run on an old PIII that is on for an average
> of 4 hours each
None of my machines are that fast (but they are on almost all of the time).
My slowest at the moment is a 333MHz. My fastest is a 2.0 MHz Core 2 Duo.
jm7
Nicolás Alvarez
Its about 3 weeks to the s...@home 10th anniversary. I think maybe some of
the staff of the s...@home project might want to consider writing out some
kind of official press release with basic information about the project and
some kind of short history.
Writers need time to write articles and they
jm7
boinc_dev-boun...@ssl.berkeley.edu wrote on 04/29/2009 07:18:24 AM:
> Martin
> Sent by: boinc_dev-boun...@ssl.berkeley.edu
>
> 04/29/2009 07:18 AM
>
> To
>
> BOINC Developers List
>
> cc
>
> Subject
>
> [boinc_dev] Work Scheduling (pt 2, Cooperative Scheduling?)
>
> Phew, what a hornets n
El Miércoles 29 Abr 2009 08:36:50 Martin escribió:
> We're talking high powered multi-core systems at the moment...
>
> But what of more lowly PCs?
>
> For example, what now can run on an old PIII that is on for an average
> of 4 hours each day?
>
> Certainly not s...@h Astropulse... Guaranteed EDF
The task being downloaded cannot be started unless the last file is also
downloaded. It is NOT therefore eligible for start, and will not be
scheduled for a start until its last file is downloaded.
jm7
Miku
Because scheduling ALSO takes into account the resource share, and a bit of
a safety margin.
100 -26.4 - 1 is 72.6 hours. // the -1 is the task scheduling period. If
this is larger, the tasks have to complete earlier. The reason is that the
task scheduling period is the granularity that the CPU
You have the logic upside down.
Your code leads to major thrashing of tasks.
Unless you check the global state, you run the risk of starting and
stopping a series of tasks IN THE SAME SECOND. because they all
checkpointed, and there is a perverse chain of what to run next.
Inspecting the global
I, for one, like it.
I didn't suggest it earlier (with my proposal) because this would have been
a major change, where I was aiming for a few smaller ones.
But this - from my point of view - could (single-resource-queue for a
certain timespan (ie. cache-size) together with global queue (additiona
We're talking high powered multi-core systems at the moment...
But what of more lowly PCs?
For example, what now can run on an old PIII that is on for an average
of 4 hours each day?
Certainly not s...@h Astropulse... Guaranteed EDF for just one WU to be
chewed on for months to then get no cr
Oooops! Typo! That should read:
... To my mind, that misses a lot of opportunity *for optimising*
throughput of the whole Boinc system, especially so for clients
connected to multiple projects. ...
Martin wrote:
> Phew, what a hornets nest the scheduler appears to be! This tangentally
> follows
A big overhead and instability in the present scheduler appears to be
that /everything/ gets rescheduled for any change of system state.
That is, all previous effort made to make a schedule of WUs is thrown
away as being worthless.
Instead, can the following idea work?
Have a WU fifo queue fo
Phew, what a hornets nest the scheduler appears to be! This tangentally
follows on from the "6.6.20 and work scheduling" thread...
The present Boinc server <--> Boinc clients scheme is that a client asks
for a minimum time of WUs and the Boinc server responds with nothing or
anything. The Boinc
>> This sounds like the [rr-sim] bug - using wrong CPU speed estimate -
>> that was fixed in v6.6.17
>
> Yes, but is the fix still in the code? :)
Oh, that's cynical! :-)
Yes it is - line 159 of trunk/boinc/client/rr_sim.cpp
___
boinc_dev maili
On Apr 29, 2009, at 12:47 AM, Richard Haselgrove wrote:
> Mikus wrote
>
>> I've seen the following (presumably in chase of a "missed deadline")
>> - I forget which release of the BOINC client I was using. [I run
>> off-line; my interval-between-connects is 1.1 days; my additional
>> work days ar
Mikus wrote
> I've seen the following (presumably in chase of a "missed deadline")
> - I forget which release of the BOINC client I was using. [I run
> off-line; my interval-between-connects is 1.1 days; my additional
> work days are 1.x days (for a total ready-queue size of 2+ days).]
>
> From o
42 matches
Mail list logo
