Posts by Tern
|
1)
Message boards :
Number crunching :
Rosetta Beta 6.00
(Message 108305)
Posted 14 Apr 2023 by  Tern
Post: Most projects let you choose whether you want to run beta applications or not. I don't. There's no way to shut these off other than stopping Rosetta work altogether. |
|
2)
Message boards :
Number crunching :
Not had anything new for about four days
(Message 81600)
Posted 16 Jun 2017 by Tern
Post: How are your resource shares allocated across your projects? Lynne, this question doesn't relate to disk space, but to the "Resource Share" numbers in BOINC Manager - the default is "100" for a new project, but you can set them to whatever you like (within reason). If you want, for example, to run 50% Rosetta, 30% Seti, 10% WCG, and 10% Asteroids, you could set these numbers (in each project's preferences page) to 50, 30, 10, and 10. (Or 500, 300, 100, 100, etc. - it's the ratio that matters.) I'm running 20+ projects with resource shares from 1000 down to 1, but I use a spreadsheet to figure out what the shares should be (since some of my hosts can't run some projects). With four projects and one PC, the percentage-guess approach should work fine. (Um. Unless you have a GPU, in which case SETI and Asteroids will run there as well as on the CPU and get more credits than you expect, so if you're trying to equalize credits, you may have to drop those a notch.) BOINC will run each project APPROXIMATELY enough to match the resource shares you have set. It will not do so all at once - it may run SETI for a day or two, then Asteroids, with a WCG thrown in the middle, then finally get back around to Rosetta and run nothing but it for a while. All depends on work availability from project, accuracy of estimates of how fast a task can complete on your computer, deadline pressures, if some projects are running GPU tasks and others only CPU, and phase of the moon... Suspending and unsuspending projects can really confuse things (NOT recommended for debugging, only when you decide not to run a project for a few weeks!) in the scheduler's tiny (very tiny) brain. The situation gets more complex when you start setting the BOINC preferences to anything higher than "store at least 1 days work" or "store up to 1 days additional work" (which is there mainly for people with intermittent internet access, or who run "unstable" projects that go down a lot - none of yours fit that criteria - so please don't mess with that without need). The "event log" the moderator mentioned is accessed from the BOINC Manager Menu - it gives much more detailed info than is given in the "Projects" tab, which just says "deferred x minutes". For example, it may be saying "Not requesting tasks - not highest priority project", which means the scheduler is trying to run SETI right now or something. Or it may say "Requested tasks for CPU - got zero tasks, project has no work", which means, well, what it says... BOINC is extremely "flexible" (just look around the boards for instructions on editing your own XML files and such...) which unfortunately means it is extremely complex to fully understand. Luckily, most people don't NEED to understand very much of it. I've been doing this for a while (Rosetta since 2005...) and I learn something new constantly if I'm not careful. Patience is definitely a virtue - sometimes when new to BOINC, we see something (like not getting any work) and get concerned, but in a few hours (or days) it all works out. It is designed to be "set up and forget" - the more you play with settings, the LESS likely you are to get what you want, unless you do a lot of research first. Those options are there because the heaviest BOINC users demand them, not because the average user will ever need them. Best bet if in doubt is often to wait a week and just make sure your credits are going up in all projects... maybe tweak a resource share here or there. Sounds like it's "fixed" itself now on your machine. If not, we're all here to help on these boards! :-) EDIT: Just looked at your host and tasks; you MAY want to go to Rosetta Project Preferences and reduce the "Target CPU run time" - I use 4 hours - which will get you more tasks that run shorter times each. All your other projects have reasonably short tasks, and having Rosetta running one task for almost 24 hours will definitely cause the scheduler to ignore Rosetta for a while to give the others time to catch up! |
|
3)
Message boards :
Number crunching :
Who is the official tech here
(Message 9576)
Posted 22 Jan 2006 by Tern
Post: Paul, I think this is one of the first things I said, who is official ? Just to clarify for the LAST time... A) I did not write that FAQ, I copied it from an obscure and heavily modified thread into a new place, and properly credited the person who DID write it (hugothehermit) B) I do not recommend moving BOINC around, have never tried it, and would recommend it as a last resort only C) I am not a moderator or official at this time, under any id, although I was when I created that thread. And when I did so, my tag said "forum moderator"; when I had them remove it, it removed it from prior postings as well. D) BOINC isn't designed and will not work well as a single-project system. You may want to run only one project, but if so, then you will simply have to accept that you will have idle CPUs at times. Just pick something, anything, give it a .01% share, and when Rosetta doesn't have work, _they_ suffer, but at least you're doing _something_. E) Adding additional forums is possible but don't look to WCG or CPDN for examples, they had something in place _before_ BOINC and BOINC is 'shoehorned in'. Look instead at Einstein, where the BOINC code has actually been improved/expanded. This is a very old topic. I'm sorry, I'm not in a position where I give a shit what's said about me right now, but it's not fair to hugo that I get credit for his hard work. Goodbye all, and good luck. |
|
4)
Message boards :
Cafe Rosetta :
Personal Milestones
(Message 9210)
Posted 17 Jan 2006 by Tern
Post: 15,000 Rosetta, 85,000 total BOINC. Still trying to get Rosetta "above" SETI (which means about 25,000) and CPDN "above" Predictor (which means about 10,000). :-)  |
|
5)
Message boards :
Number crunching :
Recent Average Credit
(Message 9203)
Posted 17 Jan 2006 by Tern
Post: What fields are required, and how the math is done, is not the point. The problem with _any_ approach other than the current one, is simply that some program must run daily, and read and write EVERY RECORD. The current approach reads NO records that wouldn't already be read. If you don't read BACK_4, then how do you move it to BACK_5? It's not needed in the calculation, but it's needed because it has to be moved. Reading 1 or 10 fields in a record is irrelevant; reading another record is very relevant. |
|
6)
Message boards :
Number crunching :
Help us solve the 1% bug!
(Message 9201)
Posted 17 Jan 2006 by Tern
Post: This "kernal_task" that takes CPU time - recent thread in SETI in Q&A-Mac; might look there...Well Bill, I would but I can't find it. Sorry - I sent you to the wrong place. here is the thread I had in mind, on the BOINC boards instead of SETI - but it's not going to tell you anything new. |
|
7)
Message boards :
Number crunching :
Recent Average Credit
(Message 9198)
Posted 17 Jan 2006 by Tern
Post: River~~ Exactly my point the RAC is not needed and is wasting cycles, it is a complex piece of Math for it`s own sake. I'm not going to defend the RAC; I don't like it either. But it is a single number that gives an _idea_ of how much you are producing for the project at any moment. Yes, it's worthless for a new participant because it climbs too slowly, and it doesn't instantly show when someone is producing less, because it decays too slowly. For the _average_ "set it and forget it" participant, however, who starts everything up and doesn't micromanage it, it is a single figure that can be used to determine if they're doing "more" or "less" than someone else. Your point is that you would prefer a _different_ number to do the same thing; a different way of calculating. We've seen that this different number is already available to you, done the way you want it, at Free-DC. You're still saying the project should use this method and drop RAC. RAC just needs the old figures for running total and RAC. There are three other items we need; the date/time of the last update of RAC, the current date/time, and how much credit you're being given right this second. That's it; NO history, NO "how many credits you had at any point in the past", NO start date. What the server has to store and retrieve to do RAC is - RAC, date/time of RAC, and total credits. Current date/time and current additional credit are available to the program that is recalculating the RAC. How about my way.... You're right, I'm going to tell you the figures are not held on the server. Your method would require not only changing the code, and adding a new (MASSIVE) program that would run every day, but adding six additional fields in the database, for the last six day's total credits. Even ignoring the additional megabytes of data storage, that's not the problem. Let me attempt to explain in "pseudo-code" why your simple request is incredibly complicated... Current RAC: Validator program runs to add credit. Reads database record it's about to update and gets RAC, RAC_DATE, and TOTAL_CREDIT. Using those and CURRENT_DATE and CURRENT_CREDIT, it calculates the new RAC, and writes the new value into RAC, the CURRENT_DATE into RAC_DATE, and adds CURRENT_CREDIT to TOTAL_CREDIT and writes it back in. One database read of three fields, one database write of three fields. (Repeated for participant, host, and team records.) Weekly, SOME projects run a "decay/cleanup" routine. This is the same code as above, but the CURRENT_CREDIT input is 0. These projects show a decreasing RAC when someone quits; if this is not run, then the RAC "freezes" when someone quits. Some projects do not run this routine, simply because it requires a LOT of database reads and writes; one for every participant, host, and team record. This can take hours to run, and severely slows down the servers while it's running. Moving Average Method: We'll assume the 7-day average _replaces_ current RAC: if it's in addition to, then the following is done in addition to the preceding. Validator program runs to add credit. Reads database record it's about to update and gets TOTAL_CREDIT. Adds CURRENT_CREDIT to TOTAL_CREDIT and writes it back in. One database read of one field, one database write of one field. (Repeated for participant, host, and team records.) No database load change from current approach, just less math. No gain, no loss. New "Carl's Average Calculating Program" runs. This MUST be done every day, and at the exact same time every day. Validator must be stopped while it runs. If it does not run "on time" for some reason, the Validator must not run until CACP can be run; otherwise "today" will get too much credit and "tomorrow" too little. This program is based on the old "decay" weekly program. It reads and writes every record in the three tables, as follows; Read TOTAL_CREDIT, CREDIT_BACK_1, CREDIT_BACK_2, CREDIT_BACK_3, CREDIT_BACK_4, CREDIT_BACK_5, and CREDIT_BACK_6. Subtract CREDIT_BACK_6 from TOTAL_CREDIT and divide by 7. Write this value to RAC. Write CREDIT_BACK_5 into CREDIT_BACK_6, CREDIT_BACK_4 into CREDIT_BACK_5, etc., shifting all the numbers "back a day". Trivial math; but requires a read and a write for every record in the participant, host, and team tables. ----- So - maybe you can see that what you are asking for is not just a "change in the math", but for every project to run a program that reads and writes tens or hundreds of thousands of records - EVERY DAY. When there is _already_ a program that was originally supposed to be run weekly to do "RAC decay", reading and writing those records; but some projects have HAD to stop running it, simply because even once a week, and even though the "decay" program doesn't require shutting off the validator, it puts too heavy a load on their servers. MAYBE you could get by with running this program weekly instead of daily... but people are NOT going to like having their RAC changed only once a week. Or you could just drop RAC completely and let the 3rd-party sites do it; but that will not reduce the project's load at all (still have to do the one read/write for each new credit) and participants who _do_ use the RAC will be screaming. The current method of RAC was chosen _because_ it can be updated "only when credit is added" - when the system is _already_ reading and writing that record. Any other method of coming up with a RAC that _I_ can think of, requires some program to read and write _every_ record, on some regular schedule. Therefore, the formula for RAC may be "tweaked" a bit here and there, but it's not going to be changed significantly. |
|
8)
Message boards :
Number crunching :
Help us solve the 1% bug!
(Message 9174)
Posted 17 Jan 2006 by Tern
Post: This "kernal_task" that takes CPU time - recent thread in SETI in Q&A-Mac; might look there... |
|
9)
Message boards :
Number crunching :
AMD vs Intel
(Message 9173)
Posted 17 Jan 2006 by Tern
Post: Anyone know what the "recent average credit" timeperiod is? A week? It's a "halflife" calculation - very complicated. My AMD 3700 was running about 600 w/ optimized SETI apps and clients, now it's mostly Rosetta, so running about 500. See the thread on "Recent Average Credit". |
|
10)
Message boards :
Number crunching :
Recent Average Credit
(Message 9164)
Posted 17 Jan 2006 by Tern
Post: If the look-ups are so complicated one has to wonder where stats site like Boinc Stats and FreeDC get the data to show daily credits for the last 30 days for any user on any project. If I understand it correctly, the stats sites get a "once or twice a day" XML feed from each project, with the _current_ credits of each participant. (I've heard that the SETI XML takes over two hours to generate. It's publicly available if you want to look at it; I've never been that interested.) They then store this data in their own database, which makes it easy to subtract "current" from "yesterday" to get "amount done today". They do their own calculation of RAC and store that as well. The stats sites run this process every "x" hours, and the data is static otherwise; the project sites are running in "real time" - every time the validator awards credit for a WU, the total credits and RAC for those hosts and participants and teams is recalculated. The projects _main_ focus is on the WUs; _that_ data is critical to them. The entire "hosts and participants and teams" area of the database is only there to satisfy the participants, and to attract new ones. The stats sites main focus is providing pretty graphs and data for their team members, etc., and they can do as much as they have the server capacity and interest in doing. The projects don't have staff that isn't already overloaded with _project_ issues, so "credit" issues come in a very distant second place. |
|
11)
Message boards :
Number crunching :
intel3.2dc versus intel 3.8
(Message 9163)
Posted 17 Jan 2006 by Tern
Post: If the 3.2 is a dual core and the 3.8 is not, I would _definitely_ get the dual core. If they are both dual core, then I would look at the "overclockability" of the 3.2; I went with AMD, personally, so I know nothing about these specific Intel chips, but when I compared the AMD 3700 to the AMD 3800, I found the 3700 could be overclocked to _easily_ outrun the 3800, and was cheaper, and had a larger cache... and overclocked, even as little as I was willing to do, would equal or better the _4200_, which I couldn't afford. If the two chips are identical except for speed, and you aren't going to overclock, then it's entirely a financial decision - the 3.8 is faster, is it worth the extra money? Look at sites like www.tomshardware.com and www.bleedinedge.com and www.anandtech.com, NOT at the CPU manufacturer sites or computer builder sites, for info on real performance and overclocking. |
|
12)
Questions and Answers :
Windows :
Upgrading Hardware
(Message 9111)
Posted 15 Jan 2006 by Tern
Post: Please read the "Please read before posting" message... If you move the hard drives, it SHOULD continue right on from where it left off. I think running your queue dry would be a safe bit of insurance though. Windows will likely ask for the authorization key as it's a "new installation". |
|
13)
Questions and Answers :
Macintosh :
Disk Space Allocation
(Message 9110)
Posted 15 Jan 2006 by Tern
Post: Please read the "Please read before posting" message... but the answer to your question is that you need to change the preferences on allowed disk space on the website. |
|
14)
Message boards :
Cafe Rosetta :
Hellooooooooo
(Message 9109)
Posted 15 Jan 2006 by Tern
Post: A big Texas howdy, y'all. :-) |
|
15)
Message boards :
Number crunching :
Report stuck & aborted WU here please
(Message 9106)
Posted 15 Jan 2006 by Tern
Post: It had temporarily backed-off downloading the .exe, but then when the WU files finished downloading, Boinc tried to run them before it finished downloading the .exe. Yes, this has happened to me before, and it's been reported. It's an annoying BOINC bug. I _thought_ it had been fixed somewhere in the 5.2.x series though... |
|
16)
Message boards :
Number crunching :
Recent Average Credit
(Message 9090)
Posted 15 Jan 2006 by Tern
Post: I calculate 7-day averages Hm... quite nice... says my 7-day avg is 236. I just looked at both BOINC Synergy and BOINCStats, and if it's done at either of those, I can find it. Carl - at least what you're after IS available. Just not from the source that it should be. And I agree about the difficulty in understanding RAC. It's a mess, and even if the "design" were perfect, because of some known flaws, it flat doesn't "work". I'm just saying that a 7-day average is not "the" answer either. MORE choices to me is always better; give me both! |
|
17)
Message boards :
Number crunching :
Recent Average Credit
(Message 9087)
Posted 15 Jan 2006 by Tern
Post: WU / Berk.eley Just to clarify; RAC is a UCB invention, part of BOINC, not something WU came up with. I have no idea why they made it so complicated; because of the timing issues, it's pretty meaningless at the project site. I'm showing 176.92 at the project, and 173.8 at BOINC Synergy, which is _probably_ more "correct", as they use a fixed date/time to do the calculation. All this really tells me is that I'm doing ABOUT half as much Rosetta as you are with your RAC of 343. (Trying to hit a goal on Einstein, very close now...) Regardless, you're correct in deducing that it's, um, flawed... :-) Still, I can see that the current system (if it could be debugged a bit) would be "more stable" than just a moving 7-days average, and does have _some_ advantages; your method wouldn't work before someone had done 7 days work, for example, and if someone stopped work, would drop by 1/7 per day, be at 0 in a week. With EDF mode and long term debts, it can easily be more than a week before you "come back" to a project; RAC won't drop all that much in the interim, where a simple moving average would. No, RAC isn't going to go away - what I _would_ like to see is for either BOINC or the stats sites to add a moving average IN ADDITION TO the current RAC. |
|
18)
Message boards :
Number crunching :
Report stuck & aborted WU here please
(Message 9070)
Posted 15 Jan 2006 by Tern
Post: 14-01-06 22:39:34|rosetta@home|Pausing result NEW_SOFT_CENTROID_PACKING_1di2_225_9449_1 (removed from memory) This is DEFINITELY the known bug. You _MUST_ set "leave applications in memory when preempted" to _YES_!!! |
|
19)
Message boards :
Number crunching :
Report stuck & aborted WU here please
(Message 9047)
Posted 14 Jan 2006 by Tern
Post: And I think these errors are related to project switching. I noticed one time that Rosetta was working fine, then BOINC switched projects, and when it reloaded Rosetta next time, it tried to start then gave the error. These look like the "application not left in memory" bug; if you have "leave applications in memory when preempted" set to "no", you'll need to set it to "yes" until this bug is exterminated... |
|
20)
Message boards :
Number crunching :
Credits Granted
(Message 9036)
Posted 14 Jan 2006 by Tern
Post: But, it seems _all_ Rosetta results have the same _ESTIMATED_ time, when in reality, the actual times vary quite a bit. Just had a good example of this; a WU that was estimated at 20+ hours just finished in 4:11:22. Remaining WUs in the queue dropped to 18:47 estimates. If you look at this host here you'll see a _6x_ range of CPU times... the DCF was set very high by the 26-hour one, is just now back _down_ to 2.33... There's only eight completed results for that host, makes it very easy to see what's going on. I think the "Increase_cycles" WUs should have been issued with at least double the estimate they got, and the "no_sim_anneal" ones possibly half the estimate. However it's done, the estimates should definitely not be the same on them. |
Next 20
©2024 University of Washington
https://www.bakerlab.org