Bible Pay

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.


Messages - Rob Andrews

Pages: 1 ... 230 231 232 233 234 235 236 [237] 238 239 240 241 242 243 244 ... 277
3541
Updated 4 nodes to 1.0.9.5b. Let us know when the windows wallets are ready. Thanks.

Ok, deployed 1095b for windows, go for it.


3542
Sorry I haven't had time to keep testing lately. V busy at work. I'll update asap. I have a couple months left over credit at some vps server providers so I will look to add these to Rosetta. I have no other use for them!
Sweet! 



3543
Hey guys, hold off on testing 1.0.9.5, I discovered a sync bug.

The good news is I think this has been causing problems in testnet.

Ill have this fixed in 30 minutes.

Ok, all, sorry about that, fixed.

Now please upgrade to 1.0.9.5b and it should sync.

I also added 'exec racdecay' if you want to play around with that, if you run it without a parameter it gives a report on a machine that will have 1000 RAC on a steady basis after 30 days, if you run it with a parameter, enter the amount of new credit the machine will crunch each day and it will give you the corresponding RAC the machine will have in N days in the report.




3544
Hey guys, hold off on testing 1.0.9.5, I discovered a sync bug.

The good news is I think this has been causing problems in testnet.

Ill have this fixed in 30 minutes.


3545
Is it our system that is going to work differently?  Because BOINC says https://boinc.berkeley.edu/wiki/Computation_credit  "Recent average credit: The average number of Cobblestones per day granted recently. This average decreases by a factor of two every week."  And the only other discussions I've seen on line about BOINC compute it the same way.  So it that document out of date, am I misunderstanding what it says or is our system utilizing a different factor?

Your not evaluating the formula exponentially and the definition is correct.  A factor of two every week is the same as the RAC being fulfilled 90% within 2 weeks (its half life) and 99% in 4 weeks.  Ill put the formula in biblepay so you can type exec racformula and see the RAC per day.

Mike:  The formula you posted is correct- its done within the boinc network.


3546
Biblepay 1.0.9.5 - Mandatory upgrade for Testnet

- Allow unbanked to be compensated without PODC Updates
- Added exec unbanked report, this shows a list of the unbanked (used by Sanctuaries)
- Fixed prayers diaplay in overview page  (they were invisible)
- Added UTXO weight and Task Weight to Distributed Computing Page GUI
- Added 7 day Magnitude and 1 day magnitude to exec getboincinfo
- Fixed DC Association process to throw the correct distinct errors for INVALID_CREDENTIALS or ALREADY_IN_CHAIN
- Added cache purging system (to prevent memory bloating in the future)

* Windows is compiling *

3547
My understanding of RAC was it was a weekly half life, so days 0-7 = 100%, 8-14 = 50%, 15-21=25%, etc. etc.

So by my understanding after a week you can roughly estimate that a particular machine will do about double that over the long haul
1 week 50%
2 weeks 75%
3 weeks 87.5%
4 weeks 93.75%
... ...
99% at 7 weeks.

Is that a misunderstanding?

Additionally, I was thinking and wondering if there might be some benefit to the system to require a larger "stake" for higher RAC?  This could alleviate the phone / unbanked poor issue and also be more equitable for the larger RAC users (like it seems like I'm going to be one of).  So basically a graduated system where there were three or four tables for Biblepay UTXO Reward Chart  or maybe making it a percentile based affair?  Such as Stake amount required = 2*RAC for 100% (just spit balling)?  Looking at the leader board, I see a good number of users with RAC in the tens of thousands (and again, I may be one of them at some point), but I don't believe it to be equitable that a 1000 RAC user and a 10,000 RAC user both require the same 50K BBP stake for 100%.

Beyond that, it seems like PoDC is working very very well!  Are we still on target for a mid-to-end-of-March (barring any other significant issues) shift to PoDC?

Yeah, its a misunderstanding of RAC, possibly due to not understand the nature of exponents or what half life of 30 days means.

On day 2 you would have 33% of your RAC in place, on day 8 : 66%, and on day 14 : 90%, roughly similar to what I said in the prior posts.
(By the time the half life hits, you have 90% of your Stabilized RAC in place)!  The Half life is 14 days!

Regarding the second idea, I dont think its beneficial to create arbitrary rules that promote people to split wallets and CPIDs (as thats all they would do, is split the cpid into two if they had to have higher balances).  In addition its important that we run this system for one year in the most simple form possible in order to support it and debug it, then vote on the most important changes after its live for a few quarters.





3548
Rob, I think you know but it wasn't apparent from the conversation. Also, I could not find where you said you started both at the same time in the last 2 pages of this forum, and that was the main point. If I were to compared RAC numbers I would only compare after 4 weeks, at 2 weeks it's still only roughly 80% of what it should be. IF yo ustarted both at the same time then it wouldn't matter as much.

Cool, but its not really a true statement that you need to wait four weeks, even if they are started at completely different times.

When working with exponents, each day both machines are running draws the comparison (of RAC over RAC) closer by 7.14% each - even if they were started at different times, and close to 100% equal in comparison if you wait 14 days, because even in the worst case scenario if Machine B was running for 30 days before machine A, and machine A for only 1 day in advance, by the 14th day, the RAC of machine B is 91% into its average reference reading while machine A is also 91% into its final slot.    By the 15th day this number is close to 99%.   

Thats why magnitude in exec leaderboard is going to reveal highly accurate comparisons of CPIDs without knowing anything about them - but the main difference with magnitude is we are looking at all the machines rolled up to one CPID, and how much total effort they put in (even if they have 90 machines working only 1 hour per day).



3549
Rob, the RAC is accurate from box to box but in the beginning it needs to catch up to speed. If you have 2 identical computers and one was started a week ago and one just now. You cannot compare the RAC of the 2 to arrive at the conclusion that the one started a week ago is faster than the one you started just now. Now, if it was 2 months from now, then yes you can compare the RAC values of the 2 machines.

http://web.archive.org/web/20120418125739/http://www.boinc-wiki.info/Recent_Average_Credit
Mike,
Do you really believe I dont know what RAC is, when I developed the magnitude formula? 

I said I started both at the same time, and you can compare two RAC's to each other if they have been running for 2 weeks, and yes, if they started at different times, you can compare two RACs together after 14 days - because that is the half life of the formula.


3550
If you started both at the same time then it would probably be OK for a comparison. I have one computer that is generating 10,000 credits per day but the RAC is only at 2.5k after 3~4 days.

What is the floating point benchmark score for the Zotac?

I will look at that FPS later once we have a little more lull in the development cycle.

But focusing on RAC for comparison, I dont catch your gist - RAC is the most accurate comparison from box to box, researcher to researcher, because it takes validated tasks into consideration, time into consideration, and smooths out network-disk-random activity to yield one number.  Thats why we base our magnitude off of ones RAC, and since we only have one project, you couldnt get any better.

Looking at credit delta is more useful for the reporting that deals with day to day changes for tamper reports and auditing etc.

It doesnt matter when one started in the cycle.  Since the RAC has a half life of two weeks after two weeks the numbers are the correct comparison for the two hosts, regardless of when one started.




3551
I don't really look at the RAC because it doesn't reach near the real value until a few weeks later. What I do is look at the completed tasks and average out the credits/hour and use this formula to calculate the number of credits per day: (credits/hour)*(#tasks running at any moment)*24hrs. The tasks typically run for either 4 or 8 hours so you can do credits/4hrs or 8hrs and modify the formula. Be sure the # of tasks are the ones actually running and does not include the ones being queued up.

You can see from my android device that I am getting roughly 50 credits per task every 4 hours and I am running 2 tasks at any given moment so my RAC should eventually be 100.

But thats really what RAC is - it gives you an idea about the computing power you have, I realize my RAC wont reach its maximum potential til I have run the nodes for 14 days, but Im taking that into account though.  But anyway for now the small device is 150/550, so its putting out about 25% of what the ryzen is.  Now I dont have to do any complicated credit delta computations or anything.

3552
Yeah, I can't really tell anything yet about which CPU is most efficient. But, for example my phone (snapdragon 800 2.2ghz) and my - very slow - laptop (AMD e-450, 2x 1.65ghz) are getting about the same RAC I think, while I only use 1 core on my phone, and it's only processing when it's charging and above 90% battery (about 8 hours per day or something) and my laptop is processing full time on two cores. But I probably need a longer timeline before I can really say anything conclusive.
Thats interesting the phone can do so well.
Day 2 update: The zotac is up to 150 RAC and the Ryzen up to 550 rac.  Zotac wattage:  15 watts, Ryzen wattage: 250 watts.
Price: Zotac: $300, Ryzen $700


3553
Anything we should be testing tomorrow Rob? When would you like me to set up the additional 7 sanctuaries? I have 3 activated at the moment.

I added the cache purge today and fixed the prayers, but I still need to add the two new metrics and the diagnostic feature.

In the mean time if you want to start bringing more sancs up that would be helpful, because Id like to test the sanctuary rank command to ensure out of 10 sancs, that the top 3 by rank are voting.  The sancs will need a place in the payment queue so it would be good to start adding them tonight if you can.

Ill get an update ready asap.

3554
Rob: your Ryzen is what ryzen 1700? and did only 250RAC for 24hours? .. how much RAM is need for ROSETTA? any help with 1core=1task? thanks guys
Looks like its a ryzen 1700 8 core.  I didnt tweak it to use 100% of the proc til this morning, so I started a new baseline with both this morning.

3555
Yes, my last superblock payment was on block 7425.
And my magnitude is still decreasing.
Ok. I'm going to unhide my PCs :) It looks that it won't be worthy to play with that in prod ;)

Great! 

So far it looks promising - we now have UTXO integrity inside PODC...  And people must do some actual work to maintain the infrastructure... and the Controller wallets are staying on for block security...  Not a bad environment...

No pool required...  I think other coins are going to be jealous.


Pages: 1 ... 230 231 232 233 234 235 236 [237] 238 239 240 241 242 243 244 ... 277