Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Me neither...
I can't get new tasks from rosetta@home on my Android phone. I tried seti@home and from them I do get tasks, so I think it's related to rosetta and not Boinc.
Does anyone else have the same problem? Maybe they don't always have tasks for Android phones?
About their server: I looked at this page: https://boinc.bakerlab.org/rosetta/server_status.php
I see now that it says that for 'Rosetta for Android' there are 0 'not sent tasks'. So that means that they are 'empty' at the moment regarding Android tasks I guess?
Good, but just to clarify, once associated, the CPID wont lose association (for one year). I think we will need to ask researchers to reassociate once per year, once they fall out of the chain.
But if you want to search your PODC Update transactions for the Last transmission you should see a 24.01 hour lag, to know why your weight dropped to zero for 6 blocks.
I dont see how thats happening - can you please double check your synced? After that run this first, log output then restart client and log output?
From my node I see your 95a utxoweight @ 13:59, wait thats just 30 minutes ago:
exec datalist utxoweight:
"95A79CD5829E8315B0B946709930DF18 (03-02-2018 13:59:34)": "100"
I think what happened is you ran the command when your utxo weight ran out, then it synced within 6 blocks after....
You can find out by looking for your last PODC Update Before 3-2-2018 @ 13:59 UTC, But it must contain the XML for the CPID: 95A.
Meaning you would have to look at the showblock blocknumber, then the coinbase transaction vout 0.
If its showing up now in exec datalist utxoweight, then I think we just had a 24 hour lag between PODC update for that One CPID.
EDIT: I forcefully created a contract on my hot sanc to see your 95a status, and it did pick up 100% for both weights.
Hi all,
I've no idea on setting up a MS for testnet, but I can put my laptop in testnet as a miner if that helps??
I've dloaded bionc and joined the BBP team, so wouldn't take much (dload new wallet). Let me know if I can be of any use?
Damian
It looks like this sheet is exactly accurate.
I believe I need to update my prior RAC assessment to say "The lions share of RAC is realized by day 20" (with 86%), and very little (13% happens) between day 21 and 40.
I just added the rac decay function with in and out to the next version of the client and it agrees with your latest spreadsheet.
Sorry, I meant if you are receiving 1000 per day, Yes you would have a RAC of 940 or so by the 4th week yes, Close to what the sheet says.
But without compounding and tracking each days old rac, your sheet shows that on the 14th day the user would only have accrued 75% of the RAC, when in reality it would be closer to 83% (due to compounding). That would put the sheet on par with what I would expect to have as a researcher and on par with what the boinc formula is doing when you plug in each days old rac plus each days new rac into the function.
And thats why I made a comment a week ago about being able to compare two machines as long as they were both on for 14 days- for all intents and purposes the RAC has stabilized after that point and they can be compared.
void update_average(
double work_start_time, // when new work was started
// (or zero if no new work)
double work, // amount of new work
double half_life,
double& avg, // average work per day (in and out)
double& avg_time // when average was last computed
) {
double now = dtime();
if (avg_time) {
// If an average R already exists, imagine that the new work was done
// entirely between avg_time and now.
// That gives a rate R'.
// Replace R with a weighted average of R and R',
// weighted so that we get the right half-life if R' == 0.
//
// But this blows up if avg_time == now; you get 0*(1/0)
// So consider the limit as diff->0,
// using the first-order Taylor expansion of
// exp(x)=1+x+O(x^2).
// So to the lowest order in diff:
// weight = 1 - diff ln(2) / half_life
// so one has
// avg += (1-weight)*(work/diff_days)
// avg += [diff*ln(2)/half_life] * (work*SECONDS_PER_DAY/diff)
// notice that diff cancels out, leaving
// avg += [ln(2)/half_life] * work*SECONDS_PER_DAY
double diff, diff_days, weight;
diff = now - avg_time;
if (diff<0) diff=0;
diff_days = diff/SECONDS_PER_DAY;
weight = exp(-diff*M_LN2/half_life);
avg *= weight;
if ((1.0-weight) > 1.e-6) {
avg += (1-weight)*(work/diff_days);
} else {
avg += M_LN2*work*SECONDS_PER_DAY/half_life;
}
} else if (work) {
// If first time, average is just work/duration
//
double dd = (now - work_start_time)/SECONDS_PER_DAY;
avg = work/dd;
}
avg_time = now;
}
Let's see if my estimate is accurate after 4 weeks:
My computer with an ATOM processor gets about half the CPU mark as the CPU you have in your computer and has the same number or cores. Your Ryzen 1700x estimation comes from comparing it to 2 different CPUs with known credits/day and by using the scores from cpubenchmark.net. The predictions are for full CPU usage without any interference.
Zotac: 1,800RAC max
1700x: 17,305RAC max
This is a relatively impressive spreadsheet, in that I see that it uses the correct exponent function (2.71) that BOINC uses and the decay formula appears to be correct, but I see a few bugs in the sheet that causes it to lag over time:
- This does not take into consideration the compounding effect of RAC. RAC is compounded at least once per day (roughly) when a host solves a WU. For example, lets say machine A had zero rac, and worked for 24 hours to solve a 100 RAC workunit, once per day. That means it would check in One Day after epoch, 86400 in since inception with 100 credits, and while those 100 are granted, its first decay point would be ONE day, its RAC IN would be the age of its PRIOR RAC (of 0). On Day 2, its prior rac of 100 would be 2 days old and its new 100 credit would be 1 day old. With a grand total of 189 rac on day 2.
So you must add a running total to this to show the prior days RAC total, and the new total so that they always are able to be decayed separately per the formula (Not 0 for one and the grand total for the IN).
- If the machine is crunching 100 new Credits per day, then the grand total in 4 weeks must be a RAC of 903 (not 100). 100 Credits per day means 100+100+100... = 500 RAC on week 1... Not 50 rac on week 1.
So I think if you add a running total for Prior days End and New days begin it will match boinc.
A 100 RAC input should yield a 920~ or so RAC at the end of the 31 day period...
Great job!
Wow those are beasts! So I should be looking for 10,000 RAC out of this baby. Ok, Ill keep it running, not going to overclock it til we are in prod LOL.
I think it was the sleep setting in win7: the default was to sleep after 30 minutes. Its making more RAC than the Zotac sleeping and I only disturbed it once per day to wake it up by accident, so much for green power... Well at least the solar project might be fun in the future.
Mini update on the Zotac vs the Ryzen: Dont give up on the Zotac, its really starting to shine now, believe it or not.
Zotac RAC 460, Ryzen RAC 710! That means zotac is doing 65% of the RAC of a ryzen, yet it costed less than half and its wattage is 1/10th that of the ryzen. It may actually prove to be "the winner" in the end...
I dont think there is a possibility of changing the current maximum budget cap (of 20% : 10% to Charity, 5% to IT, 2.5% to P2P and 2.5% to PR) - as that is what we promised to the investors. I know I railed for 5% for IT during inception when I discovered the dire necessity (the decision was based on the greater good, coming down to survival) but I am also a staunch advocate of sticking with what we have forever. Our emissions rate, our deflation rate and our block cap and our budget cap per block - forever now, I beleive its set in stone now. (On a side note you will see the next total monthly budget increased due to technical reasons - we based the old 5.7MM budget on the Maximum difficulty possible, starting in the PODC world, we will be basing the budget on PODC diff which is much lower so we will have more breathing room in 40 days, and also, our 7 min block targets will kick in, giving us more breathing room).
Mike, Im not sure I understand, you said in the general section you would want us to change the governance system? LOL. And I still didnt receive a clear answer: Do you intend to raise 3 payments of 500K each, for a total of 1.55 M to start One sanctuary, or do you intend to ask for payment # 5, 6, 7 to start More than one sanctuary? And finally, I dont understand how other biblepay community members can have a say in future charity expenditures by Sanctuary #1 if they cant vote on a proposal to spend it in the governance system. Would this be done manually, by You, in the forum, basically where User 10, 11 and 12 submits some type of Forum Post to spend the sanctuary money and You manually approve these expenditures (based on said forum posts) without any voting system (such as in client voting for current budget proposals)?