| Info | Message |
|---|---|
| 1) Message boards : BOINC client : BOINC 7.2.42 - Project resource sharing issue ?
Message 57255 Posted 1 Nov 2014 by FalconFly |
Ah, thanks for the reply... That explains alot - and since the project in question has a quorum of 3 and not a hughe userbase, it takes significantly longer to convert its tidal wave of pending credits into granted credits. That likely aggravates the problem additionally. The converging is taking place now, so I think I'm getting pretty close to see them run alongside "nice" to each other again soon. I'll modify that 10 days that you mentioned to a smaller value, that should do the trick :) |
| 2) Message boards : BOINC client : BOINC 7.2.42 - Project resource sharing issue ?
Message 57251 Posted 1 Nov 2014 by FalconFly |
I've recently ran into a very very old problem (which I deemed long solved) : After running a Project mix of SIMAP (CPU only) and Collatz (GPU only), I added another CPU Project (Collatz). What happened then, was that the freshly added Project basically runs exclusively (since 2 weeks now). The only times BOINC 7.2.42 (both Windows and Linux) will allow SIMAP to run is when some of its WorkUnits eventually run into Deadline issues - all despite only 0.5 days Cache is used. So far, only a much older BOINC installation (Linux 6.10.17) reverted to the correct sharing after a few days, now running a perfectly shared 50:50 amongst the two CPU projects. The 7.2.42 installations, however, absolutely refuse to do so. Only when reducing the Resource share from its default 100 to i.e. 25 can I achive that at least some sharing takes place (still about 3:1 for Constellation). So the big question is : Why is it that BOINC 7.2.42 persistently and apparently ignores all rules for fair resource sharing amongst projects? The way it is now, running multiple projects would seem to require quite significant manual intervention. IMHO something is wrong with the resource sharing in the current BOINC release. (although I can't pinpoint it, the behaviour reminds me of a very old Long Term Debt problem, where suspended or "no new work" projects erroneously accumulated massive amounts of debt, making the sharing formula inherently unstable and eventually causing BOINC even to go defunc by refusing to download new work) |
| 3) Message boards : BOINC client : A Real Stumper
Message 10411 Posted 21 May 2007 by FalconFly |
But that would mean benchmarking at Performance Level X, but producing at X-60% depending on P-State achieved... IMHO that's not a feature but a bug. That BOINC is supposed at low Priority is normal, but running at too low Priority to achieve full CPU performance should be reserved as an Option in the Preferences (e.g. "Grant running Projects Priority Level X when Idle, Level Y when in use"), not be the Default. I would like the Idea of my machinery using lowest P-State e.g. after running out of work temporarily, but throttling back to full speed as work becomes available again. As it is now, because of that use of e.g. Cool&Quiet is not possible for me, although I would certainly like to have it turned on. A bit Off-Topic, but use of User-Definable P-States would allow for excellent Throttling according to user-defined conditions. I'd love that one in Summer and make it dependent off Temperatures, for example. |
| 4) Message boards : BOINC client : A Real Stumper
Message 10404 Posted 21 May 2007 by FalconFly |
As far as I know this is a long standing BOINC bug. With intel Speedstep or AMD Cool&Quiet or PowerNow! enabled, BOINC apparently fails to trigger the corresponding CPU Power Management to ramp up clock levels (affects both Linux and Win32). I've seen the respective Performance drops various times, after I forgot to either disable it or set the Power Management to "Performance"... It seems the BOINC benchmarking does manage to trigger it in some Versions, but the Project Clients I have seen did not while running. |
| 5) Message boards : BOINC client : 5.9.x problem reports
Message 10045 Posted 7 May 2007 by FalconFly |
Found an old friend again : Linux V5.9.4 and 5.9.5 still have incorrect Cache amounts. With 0.5 days set and 5.8.x showing a nice ~12h Cache, the 5.9.4 and 5.9.5 cache too much. Not as bad as 5.9.3, but still varies from 18h to 26h. --- edit --- I've opened a Trac Ticket, see if we can work this out from there. |
| 6) Message boards : BOINC client : 5.9.x problem reports
Message 9722 Posted 20 Apr 2007 by FalconFly |
Hm, as I start getting the whole Thread in my normal EMail, it really is recommendable to setup a dedicated EMail Account for participation - then I'd say it gets quite usable. Gotta work on that :) |
| 7) Message boards : BOINC client : 5.9.x problem reports
Message 9714 Posted 20 Apr 2007 by FalconFly |
Ah, that looks better... I regged up, let's see how it works out from there on :) -- edit -- Wow, using that Mailing list will take a while getting used to. I had hoped for something more like a Messageboard *ugh* |
| 8) Message boards : BOINC client : 5.9.x problem reports
Message 9712 Posted 20 Apr 2007 by FalconFly |
My latest Prefs are from MalariaControl. (and as I said, there is no specific Alpha Mailing List in the Link you provided - which is a collection of other BOINC Development related Mailing Lists - , I think we keep missing each other here ;) ... Which of the 8 available Mailing Lists contained in the Page you linked do you mean? Could it be I'm missing Details on that Page simply because I'm not registered to any Mailing lists yet?) |
| 9) Message boards : BOINC client : 5.9.x problem reports
Message 9705 Posted 20 Apr 2007 by FalconFly |
I've checked all available Mailing Lists and found no such thing as "boinc_Bugreports : For people testing pre-release BOINC Versions" None of the existing List Descriptions match the profile of Bug Reporting outside Code-Level (Developers only). |
| 10) Message boards : BOINC client : 5.9.x problem reports
Message 9672 Posted 18 Apr 2007 by FalconFly |
I also found something else, possibly quite a big bug : On all 5.9.3 (Linux) Systems, the Work Buffer kept by the Clients far exceeds the desired Setting. (I have no 5.9.3 Windows Clients running for comparison) Since a few days, I have "Connect to Network every x days" reduced from 1 to 0.5 days. All remaining 5.8.15 and 5.8.16 Clients worked down their caches immediately and show a perfect ~12hrs of Work Buffer, while all 5.9.3 Clients vary from 36 upto 62 (!) hours. I first noted the oversized local Caches as the first Clients ran into "x Deadline misses" on MalariaControl with its typical shorter deadlines when I still had the setting to 1 day (the reason I cut it in half). At that time, the 5.9.3 clients indicated a Work Buffer of upto 120hrs. Looking at the amount of Work actually kept on the Clients, it appears as the Clients indeed fully overload on Work, compared to the much lower desired setting. It's only thanks to the highly varying actual runtimes (often much shorter) of MalariaControl, that the Clients don't miss the deadlines completely. The large variation between work buffers kept on the 5.9.3 Clients is not transparent to me, as all relevant Parameters (CPU efficiency, active fraction, on fraction etc.) are almost identical on all affected machines - they're on 24/7 @ 99.x% efficiency anyway with about no downtimes, no exception. Only good news is, that the 5.9.3 still reacts proportionally to the desired setting... it just remains too large by a factor of 3x to 6x. |
| 11) Message boards : BOINC client : 5.9.x problem reports
Message 9465 Posted 9 Apr 2007 by FalconFly |
Are they dual or single core systems? With or without HT? Almost all of them are Dual Core (Athlon64 X2, x86_64 Fedora Core 4/5/6 Installations) |
| 12) Message boards : BOINC client : 5.9.x problem reports
Message 9454 Posted 9 Apr 2007 by FalconFly |
I've noted the following : The Linux V5.9.3 seems to benchmark quite inconsistently. All my 5.9.3 equipped Systems will change Benchmark results at every benchmark with far higher variation than any other Version I've seen so far (upto 10% variation) For me, this large variation affects Integer Benchmarks only. In comparison, the Float bench remains very consistent, well within 0.1%. (all measured repeatedly on dedicated Systems with no other relevant CPU usage besides BOINC itself) |
| 13) Message boards : BOINC client : BOINC V5.8.x Computer Info/Listings Bugs
Message 8815 Posted 16 Mar 2007 by FalconFly |
Understood, I guess that's anyway just a minor cosmetic problem. So, any insights as to why everything after CPU Vendor is omitted (although correctly listed in the client_state.xml) on Fedora Core 6 ? (I will test Fedora Core 7 RC2 next month, when I upgrade another System, maybe that works out) |
| 14) Message boards : BOINC client : BOINC V5.8.x Computer Info/Listings Bugs
Message 8792 Posted 16 Mar 2007 by FalconFly |
Hm, I still would like the Extensions not to appear in the Project's Computer Listings, as it can be alot. Would be nice to at least have it filtered there downto the most basic ones (i.e. MMX, 3dNow, SSE-SSE3). They could be otherwise kept in a separate Line in the client_state.xml, i.e. Line <cpuflags> ------------ Not as important as the CPU Vendor-only bug anyway. (I have no clue, the data is present in the client_state.xml, it just doesn't make it into the Computer Listings of the Projects) |
| 15) Message boards : BOINC client : What Happened to my CPU Type?
Message 8786 Posted 16 Mar 2007 by FalconFly |
I have exactly the same thing, but strangely only on Fedora Core 6 (older FC 5 and FC 4, Mandrake and RedHat installations updated to BOINC 5.8.11 / 5.8.15 did not exhibit this bug to me) I tried updating FC 6 to latest Packages and Kernel, but that did not change the situation. It's annoying to have Systems going 'incognito'. |
| 16) Message boards : BOINC client : BOINC V5.8.x Computer Info/Listings Bugs
Message 8785 Posted 16 Mar 2007 by FalconFly |
I recently switched all my Systems to V5.8.11 (some to 5.8.15) and noted the following : - Computer Listings now include lots of additional CPU Information (while useful for BOINC itself to have it, does it really belong all there ?) Differences across Operating Systems : Windows2000 SP4 AuthenticAMD AMD Athlon(tm) XP 3000+ [x86 Family 6 Model 10 Stepping 0] [fpu tsc sse 3dnow mmx] Linux (2.4.x upto 2.6.15 Kernel, various Distributions) AuthenticAMD AMD Athlon(tm) XP 3000+ [fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow] Linux (Fedora Core 6 - 2.6.18 and 2.6.20 Kernel) AuthenticAMD ---------------------- Windows Systems list Family/Model/Stepping, but only a few CPU Extensions. Various Linux Systems upto 2.6.15 Kernel list only the CPU Extensions, but there it lists just about... everything. My Fedora Core 6 Systems however, show only CPU Manufacturer and that's it (?) (have this on three separate Systems running FC6, fresh & clean installs) Note : BOINCview V1.4.2b which oversees the entire Network sees the CPU Identifiction correctly on the FC 6 Systems, so BOINC 5.8.x is reading/using it there - it just fails to report it into the Computer listing. ----------------- Apart from the additional Info completely clogging up the Computer Listing pages, I believe this is a Bug worth looking into. If there's anyone able to help me get the CPU Listings sorted out on FC 6, this would be great :) (otherwise, I'll soon have all Systems listed "incognito") |
Copyright © 2025 University of California.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License,
Version 1.2 or any later version published by the Free Software Foundation.