"Your" problem?
Rom, the garbage escaped HTML stderr_text will be going to *every* project
with v6.12.27 clients attached. They won't *all* upgrade their servers in
the next five minutes, or even overnight.
- Original Message -
From: "Rom Walton"
To: "Travis Desell" ; "Astro Research"
are using stderr_out for storing result values?
- Rom
-Original Message-----
From: Richard Haselgrove [mailto:r.haselgr...@btinternet.com]
Sent: Wednesday, May 25, 2011 12:19 PM
To: Rom Walton; Travis Desell; Astro Research
Cc: boinc_dev@ssl.berkeley.edu; boinc_proje...@ssl.berkeley.edu
S
ified this numerically) They are vulnerable to high
>> value outliers. If there were also a measure approximating standard
>> deviation it might be possible to exclude numbers that are more that
>> two standard deviations off the mean, which would lead to more stable
> moving
There's some documentation in http://boinc.berkeley.edu/trac/wiki/GuiRpc, but
it refers back to to the (L)GPL'd code for details.
When I tried to get a limited subset of the calls to work, I think I resorted
to packet-sniffing.
- Original Message -
From: "Eric J Korpela"
On Mon, Aug
e -
From: "David Anderson"
To:
Sent: Sunday, August 28, 2011 1:33 AM
Subject: Re: [boinc_alpha] User web: message board page navigation
> fixed (please use boinc_dev or private email for server issues).
> -- David
>
> On 27-Aug-2011 12:35 PM, Richard Haselgrove wrote:
Another one for the 'ToDo' list in 24064: there are user reports that trying
'edit profile' results in a 500 Internal Server Error.
I don't have a profile to edit, but can confirm error 500 on 'create profile'.
___
boinc_dev mailing list
boinc_dev@ssl.b
And another one - using the red-x to report forum messages to a moderator also
results in a 500 Internal Server Error.
> Another one for the 'ToDo' list in 24064: there are user reports that trying
> 'edit profile' results in a 500 Internal Server Error.
>
> I don't have a profile to edit, but
Einstein's case is more complicated than that.
Some of their download files (executables, and gravity-wave search data
files) are used many times over by multiple tasks and multiple users: they
are distributed worldwide, and clients are given multiple download urls to
try.
But other download f
Likewise. I have twin hosts, both Q6600 plus 9800GT (so 'pure' cuda, again at
cuda23 level). The anonymous platform member of the pair is getting new work,
but the one I've just set to stock work and reset got:
06/10/2011 00:05:04 | SETI@home | Resetting project
06/10/2011 00:05:08 | SETI@home
&, const char* op)
should work on the selected file, whether the control operation is 'abort' or
'retry' - and that's how it works for individual file backoffs. But it doesn't
extend well to project-level backoffs.
- Original Message -
From: "David An
It certainly happened at SETI a few days ago when the transitioner went
offline (the server hosting the transitioner process crashed). 'Results
ready to send' peaked at about 1,750,000 - the usual limit keeps it between
200,000 / 250,000 - from which we deduce that the splitters (their workunit
Not being a skilled code reader, may I ask if changeset 24385's "improve the
accuracy of FLOPS estimation for GPU apps" applies to anonymous platform?
In the original job runtime estimation whitepaper
http://boinc.berkeley.edu/trac/wiki/RuntimeEstimation, it still says, for new
hosts and new ap
Part 2 of this research: Credit
Because the NumberFields tasks are so variable (from 2 ro 300,000 seconds),
I've been looking at the rate that credit has been awarded - Credits per hour
(of runtime) gives a nice human-scale value.
Here are the results for my four hosts at NumberFields. All four
From: Travis Desell
To: Richard Haselgrove
Cc: BOINC Developers Mailing List
Sent: Monday, November 07, 2011 6:53 PM
Subject: Re: [boinc_dev] APR, DCF and non-deterministic projects
We've had similar issues with the n-body simulations we're doing on
milkyway@home. The run
d be discarded,
and the 'permanent' DCF would be updated as normal, depending on the task
outcome (full DCF correction if success outcome, no change if error outcome).
- Original Message -
From:
To: "Richard Haselgrove"
Cc: "BOINC Developers Mailing List&quo
> > If a project has highly variable jobs, this translates into highly
> variable credit
>
> And this is probably what Richard is pointing out as the core of the
> problem. People see this as a flaw in the credit system - and I have to
> agree to some extent that credit consistency within a single
> That's true. The discussion should not drown in talk about credit.
> As you point out, credit just happens to be one very visible indicator
> that the estimates are sometimes way off.
>
> -- Janus
Way off.
While we're thinking about the wider principles, could we apply a band-aid to
stau
78135
p2030.20100425.G44.31+01.48.C.b1s0g0.0_3752_0] (est. dur. 8949.40 seconds)
- Original Message -
From:
To: "Richard Haselgrove"
Cc: "BOINC Developers Mailing List" ;
; "David Anderson"
Sent: Wednesday, November 09, 2011 4:15 PM
Subjec
> Only if you multiply the estimates for each task by the DCF would it match
> dividing the work request by the DCF. Doesn't matter whether it is client
> side or server side.
>
> jm7
I don't think the client side DCF code has changed much since - according to
the Unofficial BOINC Wiki - version
Would that work under the new v7 client data model, which separates upload
and download files? Since the files are intended to be both generated and
used locally, they would have neither a download nor an upload url.
Also, since Raistmer is working as an independent developer outside a
project
I don't know of any official list, but a SETI volunteer has compiled an
unofficial one:
http://www.hal6000.com/seti/boinc_ati_gpu_cheat_sheet.htm
> Hi,
>
> The current BOINC client is able to determine the CAL version of the
> installed AMD/ATI driver. Is there any way to find out (and commun
For the last few weeks, it looks as if the SETI@home server has been making
strange plan_class choices.
Here's a screen-shot taken this afternoon.
http://img46.imageshack.us/img46/1426/cudaorcuda23.png
There seem to be almost as many tasks assigned to plan class 'cuda' as there
are to plan cla
Further investigation on this. I may have been getting work allocated with
plan_class 'cuda', instead of 'cuda23', because the processing speeds were not
as differentiated as they should have been.
This is because DLLs from the wrong plan_class were being used.
This may be specific to the SETI
; upload of p2030.20100614.G46.20-00.29.C.b0s0g0.0_3344_0_2
> Do 08 Dez 2011 20:49:55 CET | Einstein@Home | [file_xfer] URL
> http://einstein-dl.aei.uni-hannover.de/cgi-bin/file_upload_handler: not
> found
> Do 08 Dez 2011 20:49:55 CET | Einstein@Home | Backing off 7 hr 51 min 19
&g
This used to be a problem with Windows clients, until we updated libcurl in
December 2009 to eliminate a DNS IP caching bug.
I was looking back at those changesets yesterday because of another issue
currently being discussed at SETI. It rather looked as if libcurl was
updated for Windows and Ma
Two sources of information:
http://newscenter.berkeley.edu/2012/05/16/power-outage-darkens-lawrence-hall-rest-of-campus-hill-area/
http://ucbsystems.org/category/active/
According to the second one, power was restored shortly before midnight PDT,
but I wouldn't expect any servers to be re-star
While you have the web format tools open, could you format the donations field
as currency, please?
According to my account details page (home.php), I've donated x.6694824
(presumably dollars) to SETI.
>
>From: Stephen Maclagan
>To: boinc_dev@ssl.berke
I'm still seeing a link for 'all versions' in the row of five links 'System
requirements | Release notes | Help | All versions | Version history'
It leads to http://boinc.berkeley.edu/download_all.php
>
>From: Eric J Korpela
>To: boinc_dev@ssl.berkeley.edu
>Se
The feature seems to be working well, and it eliminates the gap at next-to-last
in long threads, which has caught me out in the past. But can I ask for more
consistency in page navigation links, please?
At the moment, we have:
Task lists:
- navigation displayed as links
- centered on page
- s
Confirmed, and also an irritation here.
Even the single visible post - the one you actually choose to reply to, in what
may be a multi-faceted conversation - shows as 'unread' while you compose the
reply.
>
>From: Jorden van der Elst
>To: David Anderson
>Cc:
I'm finding that they take you to the page that the post is on, but they don't
scroll the page so that the linked post is at the top of the visible area.
I wonder if different browsers behave differently? Testing using IE8 on XP.
>
>From: David Anderson
>To: jo
Following a discussion at LHC
http://lhcathomeclassic.cern.ch/sixtrack/forum_thread.php?id=3457
I've been looking (superficially) at the plan_class code.
Seems that both sched_customize and plan_class_spec offer a sample SSE3 plan
class, tested by finding the substring sse3 in p_model or p_featu
Further checking:
hostinfo_unix.cpp returns sse3
hostinfo_win.cpp returns pni
>
>From: Richard Haselgrove r.haselgr...@btopenworld.com
>
>Following a discussion at LHC
>http://lhcathomeclassic.cern.ch/sixtrack/forum_thread.php?id=3457
>
The particular problem with 0xc135 - "The application failed to initialize
properly" - is that most references found via Google assert that the problem
can be solved by installing the Microsoft .NET framework, but I think that's
highly unlikely to be the platform a BOINC science app is built
http://boinc.berkeley.edu/wiki/Anonymous_platform used to be linked from the
front page of the BOINC User Manual
(http://boinc.berkeley.edu/wiki/User_manual), via 'Make your own client
software '.
On 23 May 2012, that link was redirected to point to instructions for building
BOINC itself - th
dited the Wiki.
>
>From: Eric J Korpela
>To: Richard Haselgrove
>Cc: "john.mcl...@sybase.com" ;
>"boinc_dev@ssl.berkeley.edu"
>Sent: Thursday, 9 August 2012, 17:19
>Subject: Re: [boinc_dev] Error Messages
>
>An "error codes" forum
.
# 1 matches found for "0xc135"
>________
>From: Rom Walton
>To: Richard Haselgrove ; Eric J Korpela
>
>Cc: john.mcl...@sybase.com; boinc_dev@ssl.berkeley.edu
>Sent: Thursday, 9 August 2012, 18:30
>Subject: Re: [boinc_dev] Error Me
I like the style of the one I've just got from Google Chrome:
"502. That’s an error.
The server encountered a temporary error and could not complete your request.
Please try again in 30 seconds. That’s all we know."
>
>
>From: Eric J Korpela
>We could use th
I would hope, and expect, that if anyone set an extreme low-latency value like
a next_rpc_delay of 1 minute or less on a public-facing volunteer project, peer
pressure from other projects would rapidly force them to change their mind.
But as the front page of the website makes clear, BOINC is a
ase,
>so it won't block out other project.
>
>-- David
>
>On 10-Aug-2012 7:36 AM, Richard Haselgrove wrote:
>> I would hope, and expect, that if anyone set an extreme low-latency value
>> like a next_rpc_delay of 1 minute or less on a public-facing volunteer
>>
4, #5... to be contacted.
>
>From: David Anderson
>To: john.mcl...@sybase.com
>Cc: "boinc_dev@ssl.berkeley.edu" ; Richard
>Haselgrove
>Sent: Sunday, 12 August 2012, 22:36
>Subject: Re: [boinc_dev] Changes to client scheduler from 6.
"Used" being the operative word. Neither the current 'LHC classic" project, nor
(unsurprisingly) T4T, has a BOINC v6 graphics_app that could be used for a
screensaver, and I'm not sure whether the current administrators would have
access to the old monolithic code - which would need adapting to
'Leave apps in memory' hardly applies to GPU tasks - they are only preserved in
memory during CPU benchmarks. I certainly run both SETI and GPUGrid in modes
where they are liable to suspension mid-run, and with BOINC set for 'leave apps
in memory' - no problems seen: GPUGrid on my GTX 470 is sus
Just so long as the git-committer message is hooked up properly to the trac
timeline and revision log, please.
In the past, that's been the biggest problem - from my point of view - with
non-atomic commits: something gets changed, and even if there's a reference way
down the checkin_notes file
The SETI@home servers are undertaking one of their periodic explorations of
BOINC's boundary conditions, and appear to have discovered a previously-unknown
positive feedback zone.
Taking my host 5828732 as an example:
http://setiathome.berkeley.edu/results.php?hostid=5828732
At the time of
Reviving this topic, because a small bug has been reported in a SETI forum
discussion (http://setiathome.berkeley.edu/forum_thread.php?id=69946)
If: forum posts are displayed in 'oldest post first' order,
And: the number of visible posts in a thread is an exact multiple of the user's
'messages
This message got caught up in a moderation backlog last week, because of the
size of the attachment. Re-posting for the list - I can supply the SVN-->GIT
lookup table separately (csv file) to anyone who would find it useful.
- Forwarded Message -
>From: Richard Haselgrove
>
Sorry, table lost formatting in email. Try:
26128 6419ac2b4dc248404014f77fa7575adb0056c98f,
ffc2266a58154aaafbfcafa994da7b6e2c7e20bb
26129 690341f17870e981dc04047a4a8274b16d2a5442,
b339b891883140f6ac853025ad236d9a4b3a1f92
26130 0bddda60ea838a7eeb6a87e53b07eaa6a7749959,
865e8d3b21e67f316d1182ba
se of ambiguity - no primary key is possible
until the duplicate references are resolved manually.
>
> From: Oliver Bock
>To: Richard Haselgrove
>Cc: boinc_dev@ssl.berkeley.edu
>Sent: Monday, 19 November 2012, 12:30
>Subject: Re: [b
rkeley.edu/trac/changeset/6419ac2b4dc248404014f77fa7575adb0056c98f/boinc
show svn revision=26128 - in that case, David's is a master code checkin and
Rom is copying to the client_release_7.0a branch.
>____
> From: Oliver Bock
>To: Richard Haselgrove
>Cc: "
soft in this age of GUIs,
and since I only wanted a one-off export in the limited time I had sole use of
the machine, brute force and ignorance won the day.
>
> From: Oliver Bock
>To: Richard Haselgrove
>Cc: "boinc_dev@ssl.berkeley.edu"
I'm participating in the testing of the new N-body application from MilkyWay,
as discussed in the news items on their home page
http://milkyway.cs.rpi.edu/milkyway/
This is still very much a work in progress, and I think the developers are
concentrating on their own application code: I'm intere
Informally on the message boards we tend to call it a 'cache'.
More formally, it might be called 'batch processing'.
>
> From: "Admin Team "St.Petersburg""
>To: boinc_dev@ssl.berkeley.edu
>Sent: Tuesday, 15 January 2013, 14:48
>Subject: [boinc_dev] How do you w
Provided the user is running a late-enough BOINC client to handle OpenCL
'natively'.
Some projects have installed OpenCL applications under a plan_class that will
issue them in response to a native-mode (CUDA or ATI) GPU request, as a
courtesy to users who don't want to upgrade beyond BOINC v6
I noticed one other curious thing while researching a post this morning.
Try opening
http://boinc.berkeley.edu/trac/browser/boinc/client/cpu_sched.cpp?rev=8f05a952a89ba7a51e3dfa0e3c84794433d08c12
- that should open boinc / client / cpu_sched.cpp @ 8f05a95 in the trac browser
Click 'Previous Re
There's some discussion of this in "A first attempt to fix the bug where apps
die with exit(1)"
http://boinc.berkeley.edu/trac/changeset/7f6ab8d49eeaa6df58bf3bc4f61f2f7540d2c7e7/boinc
>
> From: Josef W. Segur
>To: boinc_dev@ssl.berkeley.edu
>Sent: Friday, 8 Mar
The Wiki job status summary table in
http://boinc.berkeley.edu/trac/wiki/JobStatus hasn't been updated to included
the expanded exit status codes introduced by the changeset I just referred to.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http:
RFC1323 (http://www.ietf.org/rfc/rfc1323.txt) provides two "TCP extensions to
improve performance over large bandwidth*delay product paths": Window scaling
and Timestamps.
It's recently come to light that the two big OSs handle these differently.
Linux enables them by default - http://man7.org/
Under what circumstances would an app need to know?
I don't think there is a way at the moment: if you're putting in a feature
request - eg for a converse of the MT --nthreads x cmdline construct - I
suggest you put in some more explanation.
>
> From: Raistmer
Anybody successfully using trac search tools against boinc-v2 committer
messages and changeset numbers?
>
> From: Rom Walton
>To: boinc_dev@ssl.berkeley.edu
>Cc: boinc_proje...@ssl.berkeley.edu
>Sent: Tuesday, 26 March 2013, 21:03
>Subject: [boinc_dev] BOINC v
And the new client code not being backwards-compatible with the old server code.
I have this evening successfully downloaded the files for a new CPDN model (of
the same type as failed under BOINC v7.0.59), using client v6.12.34
>
> From: Carl Christensen
>To: N
Fully agreed. But remember that you have to follow the logic and also
re-instate the DCF code on that project's server.
Say you set work fetch limits of 0.5 days minimum and 0.5 days additional - or
a target work buffer: 43200.00 + 43200.00 sec
Once TrainWreck@home (eventually) becomes the high
ts own DCF.
I invite you to review what happened to DCF in sched_send.cpp (server code), in
http://boinc.berkeley.edu/trac/changeset/1d765245ed6ea666a46b2b5878371c4183accbeb/boinc-v2/sched/sched_send.cpp
>
> From: "McLeod, John"
>To: Richar
caused by a badly-estimated
batch of work.
>
> From: "McLeod, John"
>To: Richard Haselgrove ;
>"boinc_dev@ssl.berkeley.edu"
>Sent: Wednesday, 3 April 2013, 17:11
>Subject: Re: [boinc_dev] The reason for a local DCF.
>
&
Typo alert. "The ... file that the BOINC client writes to each slot" (second
paragraph) is of course init_data.xml, and I suspect the sample file contents
likewise. Calling it app_info.xml may set people's minds running down the wrong
path.
>
> From: Charlie Fe
John.McLeod wrote
> So, you find the following behavior desirable?
>
> User wants a share of 50/50 between CPDN and SETI.
>
> Can only get 99/1 under any circumstances. Not because SETI is not
> supplying work, but because CPDN takes too long?
I've been giving this some more thought: here are th
David Anderson wrote
> That's essentially what "CPU scheduling period" is.
> Setting it to a large number turns off time-slicing
> and runs jobs FIFO (or EDF if needed).
>
> -- David
Or would if it worked / will when it works. There currently seems to be an
interruption to this option in v6.6.20
David Anderson wrote
> That's a good thought experiment.
> The essence of it is that the current client has 2 laws:
>
> 1) avoid idle CPUs
> 2) once a job has been fetched, try to finish it by its deadline
>
> and in some cases (like the one you describe)
> obeying these laws leads to ignoring res
> static inline bool finished_time_slice(ACTIVE_TASK* atp) {
> double time_running = gstate.now - atp->run_interval_start_wall_time;
> bool running_beyond_sched_period = time_running >=
> gstate.global_prefs.cpu_scheduling_period();
> double time_since_checkpoint = gstate.now - atp->ch
> Almost everyplace should be using gstate.now. This is set at the
> beginning
> of the current loop, and it avoids the expense of a system function call,
> and is within few milli seconds of being the same as now(). It also gives
> all actions in the current loop the same timestamp.
>
> jm7
I'
> now() calls a function. now would be a direct variable. At the beginning
> of the current poll, you will find gstate.now = now(). From that point
> on,
> gstate.now can be used as a stand in for the function as it really should
> not change much before the end of the poll loop.
>
> jm7
Then
> Remember gstate.now is a global variable that is set in the main polling
> loop. everything in cpu_sched.cpp should be called well after that is set
> in the main loop.
>
> jm7
That is why I only listed the lines where
now
is used naked, without its modesty being covered by gstate.now or now(
> Check to make certain that is not a local variable. If there is no local
> variable of that name, then it would be the address of the function now().
>
> jm7
Over to David.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berk
> Check to make certain that is not a local variable. If there is no local
> variable of that name, then it would be the address of the function now().
>
> jm7
Over to David.
To clarify: I am certain that there is no local declaration of 'now' as a
local variable in the file cpu_sched.cpp
I do
If the function is part of the CLIENT_STATE class then now is equivalent
to gstate.now.
In a more common variable naming scheme now would have been named m_now
to demonstrate it is a member variable of the class.
- Rom
I can see that 'now' is declared as a double in client_state.h, and
clie
Well done Paul, I think you claim the prize:
http://boinc.berkeley.edu/trac/changeset/17860
- Original Message -
From: "Paul D. Buck"
To: "David Anderson"
Cc: ; "BOINC Developers Mailing List"
Sent: Thursday, April 23, 2009 7:50 AM
Subject: Re: [boinc_dev] [boinc_alpha] 6.6.20 and wo
Space Sciences Laboratory,
> lunch (but not airfare) included.
>
> -- David
>
> Richard Haselgrove wrote:
>> Well done Paul, I think you claim the prize:
>>
>> http://boinc.berkeley.edu/trac/changeset/17860
>>
>> - Original Message -
>> From: &q
> I'll give a good test when the next build is out, but I won't be able to
> reproduce the experimental conditions until Einstein is issuing work
> again -
> dry on all relevant boxes. So we get to relax a bit over the weekend.
v6.6.24 is installed and new work is downloading from Einstein as I t
this been remarked on
before?]
I'll go and preserve the logs, and try and find you the meaningful sections
to upload. More follows.
- Original Message -
From: "Richard Haselgrove"
To: "Richard Haselgrove" ; "David Anderson"
Cc: "BOINC Develope
Pre-emption logs as promised. I have kept the full log with intervening cycles
if needed.
First Einstein task starts after download, at expense of SETI/AP:
24-Apr-2009 14:05:58 [---] [cpu_sched_debug] Request CPU reschedule: files
downloaded
24-Apr-2009 14:05:58 [---] [cpu_sched_debug] schedule
Comment on preceeding logs:
You can tell I got v6.6.24 installed right by the new (coprocessor job,
FIFO) and (CPU job, debt order) messages.
But they don't appear in the second cycle (checkpoint reached). I have
checked, and it isn't an editing error on my part - checkpointing
consistently go
> And the new "Request CPU reschedule: Idle state change" message.
I'm not sure quite what's "new" about this.
As I said, I instinctively took precautions by screen-grabbing BoincView
before touching the v6.6.24 testbed. That's because the BV machine itself,
my P4 Northwood daily driver running
Paul D. Buck wrote
> Again, the point being that we still have the issue were BOINC
> continually changes its mind about what should be running.
>
> One of the causes is that we call the schedulling routine so often. But
> that is not all of it. Even if we do throttle the number of calls to
> I know, Richard you don't see as much need for this, but, this is the
> reason I cannot do more on the other end.
>
> Oh, and I won't even mention the waste of compute time doing nothing once
> every 10 seconds ...
OK, I'm convinced - especially if there's a guard time using that
interesting
TarotApprentice wrote:
> Sometimes tasks take longer than expected. That may then put other tasks
> into deadline pressure. Sure I agree there is no reason to check every 60
> seconds. I think 5 mins is enough to allow for this scenerio assuming some
> other event didn't already trigger the che
> I suppose if we are adjusting DCF in the next go rounds then I will need
> to pay attention to it ...
As it happens, here's one I _didn't_ prepare earlier - happened live just as
I read your mail.
http://img524.imageshack.us/img524/2865/setidcfeffect.png
SETI has been sending out a lot lof
> BOINC Manager shows the CPU time in the task list in the advanced view.
> This shows what is often several hours more for the task. Over 23hrs when
> the other places indicate 17. This seems to be reflected in the estimated
> runtimes as well, which show over 30hrs, even though all tasks have
> There is a problem with sorting if you move to that (basically you give up
> the ability to sort).
>
> jm7
There's a problem with sorting anyway - basically you give up the ability to
UN-sort unless (Windows) you fiddle with the registry - not desirable advice
for the casual volunteer.
What I
> john.mcl...@sybase.com wrote:
>> Paul:
>>
>> The events that drive rr_sim:
>
> OK, so trying a little KISS:
>
>> RPC complete: We have now committed to some more work. Is there
>> anything
>> that needs to start right now to complete on time.
>
> Nope. No need. The request should be reasonable
> 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).
>
> -- David
May I nominate as my personal highest concern the work-fetch de
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
>> 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
>> Rom did an analysis at one time that indicated that the basic
>> connection
>> was about 10 times as expensive as the work for a single report or
>> request.
>
> http://www.romwnet.org/dasblogce/PermaLink,guid,143d4295-8e5f-4361-a883-18ffad817094.aspx
So, has anyone done an estimation of the wa
Paul D. Buck wrote
> Not sure if I have the for sure smoking gun ... but ...
>
> VERY interesting evidence for you developers to ignore ...
>
> TWO Problems, for the price of one nights work.
>
> 1) There seems to be an issue with the way BOINC interacts with the
> zip and unzip which may cause B
That sounds like the problem they had at CPDN Beta with big trickle files -
the sched_request size got too big. Not the number of tasks, but the size of
the file.
You might ask someone with the problem how big that file is - someone at
CPDN mentioned 4MB as a limit.
http://cpdnbeta.oerc.ox.ac.
> Other than that, it works fine. Rather nippy as well.
>
> -- Jord.
If anything, a little too nippy.
I run one workstation-class host - dual Xeon E5320 (8 cores), Quadro FX 1500
(pre-CUDA), Vista Business 32-bit. Monitor is Dell UltraSharp 20" @ 1600x1200
via DVI.
It runs the v5.10.13 core c
> At 12:34 PM +0100 5/19/09, Richard Haselgrove wrote:
>>The BOINC v6.6 managers (currently .20 and .28) show much more screen
>>'flicker' when updating data for running tasks than earlier managers -
>>comparing the current unified task list view with earlier &#x
Charlie Fenton wrote
> Hello Maureen,
>
> We removed it because we want to phase out the V5 clients, and users
> would be more inclined to use a V5 client if it is shown on the
> download_all page, even though it is marked as an older version.
>
> We have now also removed the 5.10.45 and 5.8.16 ve
Charlie Fenton wrote:
> Thanks for bringing this to my attention. I wasn't aware of this issue;
> I've asked Rom to check into it and to restore those versions if needed.
I'm not surprised that you weren't aware of it, but isn't that an inevitable
consequence of running a development model wi
Short answer is not directly.
I'll get that checked in, I didn't even know about that window message.
- Rom
If you or Jord could compile a BM with that mod (Win32), I'll gladly test it
on the multi-manager hardware where I noticed the problem yesterday. (I can
run two managers in parallel
101 - 200 of 424 matches
Mail list logo
