BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)

[bible_pay]

Even though things have gotten personal with the sleights and insults, one thing appears to me. That we are a community, and some of what has been brought up really needs to come to light, for the community about how things are being handled. They affect us all. Let's have a non-censored discussion.

It's actually in the best interest of everyone. Let everyone hear. If you all want to argue about whether so-and-so is acting Christian enough, then PMs are the way to go. But for community-wide issues, like how proposals work behind the scenes and potential conflicts of interest.  How can we say that only affects one person who needs to work it out in private? I don't want to make any comparisons to political parties who employ that tactic. Let's just say it tends to end badly for all. I'm really hoping that doesn't happen here.

Do I, as the owner of a tiny amount of biblepay, have the right to understand the proposal process?
Is it true anyone can just "reboot" their proposal until it passes (those with the most votes can take full advantage of this?
Can proposals really be hidden, and who has the decision on that?
How many nodes does the lead dev have?

These are examples of questions that arise because information only comes out piecemeal, maybe leaked from private conversations and messages. I don't want to see this sad trend continue, so let's get things out in the light, maybe then it's easier to trust again?   The problem with "let's just start over", is the questions that spawned the controversy are left unadressed. so the release of tension is only temporary. Then the cycle starts again, maybe with something new added to the fire. We can fix this, but we have to make some new patterns.

Some legitimate concerns from a user from the other thread.

Yep responded over there,  but it is said in a respectful way...  this is the difference inblue

Yes, there is a difference in that the "respectful" way doesn't produce any response from Rob.

I thought that TheSnat's reply to him was perfect and I didn't have anything to add.

InBlue, I apologize for being rude in the past to you.

[thesnat21]

My BBP windows wallet uses 14% of the cpu on a new machine with an Intel i77-7700 3.6 ghz.

Seems high, is this normal?

genproclimit=1

Seema  bit high,  do you have the minersleep parameter setup?

[bible_pay]

My BBP windows wallet uses 14% of the cpu on a new machine with an Intel i77-7700 3.6 ghz.

Seems high, is this normal?

genproclimit=1

Please see if it drops after a few minutes.  Im watching my windows wallet now and its using 1%.
You can also try two more things:
minersleep=500

or

Test both biblepaycore32 or 64 bit just to see if there is a difference.

Minersleep sleeps for 500ms per 5~ second loop or so and lowers cpu usage.

[zthomasz]

Thanks, I changed from minersleep=0 to =500. Now cpu is at 3% instead of 14%.

How high can the minersleep parameter be tweaked without causing a problem?

[bible_pay]

Thanks, I changed from minersleep=0 to =500. Now cpu is at 3% instead of 14%.

How high can the minersleep parameter be tweaked without causing a problem?

You could go to about 10000 and still solo mine (due to our distinct CPID rule), but above that it will be sleeping quite a bit.

[cuarc001]

Looks like you guys started out the gate in 9th place. - https://www.seti-germany.de/wcg/stats_team_all.php?proj=wcg&lang=de

[secoccular]

Looks like you guys started out the gate in 9th place. - https://www.seti-germany.de/wcg/stats_team_all.php?proj=wcg&lang=de

Depends on where you look.

https://boinc.berkeley.edu/dev/forum_thread.php?id=12603&sort_style=&start=120

[thesnat21]

Looks like you guys started out the gate in 9th place. - https://www.seti-germany.de/wcg/stats_team_all.php?proj=wcg&lang=de

Depends on where you look.

https://boinc.berkeley.edu/dev/forum_thread.php?id=12603&sort_style=&start=120

2 different challenges

The one that just started is the 14th bday one

[MIP]

I suspect there are some memory leaks with shared libraries in Ubuntu 18.04.

biblepayd eats up all the memory after some weeks and then crash. The same version in Ubuntu 16.04 stays stable at 25% on a 1GB VPS for months.

At this moment I would not recommend running masternodes in 18.04 as it seems the underlying libs are not mature enough yet.

[capulo]

i'm experiencing lower wcg rac over few last days, my firends too. anybody else?
11/15/2018       1:240:08:39:18       1,538,958       3,356
11/14/2018       1:235:15:29:10       1,751,752       3,300
11/13/2018       1:249:12:11:05       1,919,218       3,595
11/12/2018       1:238:23:13:54       2,175,887       3,618
it goes down a lot for same work. have anyone info whats going on?

i just found that if machine (all threads) starts working on this project, then temperature goes up by 10 degrees...
 wcgrid_mcm1_map
maybe it has something to do with poor results

[cuarc001]

Are/have you been running MCM exclusively? And have you seen a slow down in the validation of work units? MCM require what is referred to as a wingman to validate the work units. Leading up to challenges, you will see numerous people deploying a tactic called bunkering where they load up their machines with a ton of work and then sit on the finished results waiting for the event to start so that they can dump all of the extra results during the challenge time frame. So, it is very possible a lot of your work was getting validated at a later time. Another possibility is that the points for work shifts slightly over time as part of the credit system used. You will find that for one person one type of work unit may pay better than for another person. The next day another work unit type may pay slightly better. In the end they kind of evens out.

[thesnat21]

I find it difficult to believe nobody else has thoughts/comments/concerns on the Proof of Orphan Mining concept?

https://forum.biblepay.org/index.php?topic=306.msg4680

Please join the discussion we want feedback from the public.

[fenton91]

I find it difficult to believe nobody else has thoughts/comments/concerns on the Proof of Orphan Mining concept?

https://forum.biblepay.org/index.php?topic=306.msg4680

Please join the discussion we want feedback from the public.

I personaly think this is realy great and hopping for this project to get attention and beeing carry out.
This is going to the right direction, in the spirit of the coin.

Get that mining job for Orphan, they are going to work soon or later anyway
tho, i wonder what we're gonna do with that coal.

[Sakic]

i'm experiencing lower wcg rac over few last days, my firends too. anybody else?
11/15/2018       1:240:08:39:18       1,538,958       3,356
11/14/2018       1:235:15:29:10       1,751,752       3,300
11/13/2018       1:249:12:11:05       1,919,218       3,595
11/12/2018       1:238:23:13:54       2,175,887       3,618
it goes down a lot for same work. have anyone info whats going on?

i just found that if machine (all threads) starts working on this project, then temperature goes up by 10 degrees...
 wcgrid_mcm1_map
maybe it has something to do with poor results

Yes, I have the same experience, my RAC is going down, but the number of completed work is similar.

[capulo]

Are/have you been running MCM exclusively? And have you seen a slow down in the validation of work units? MCM require what is referred to as a wingman to validate the work units. Leading up to challenges, you will see numerous people deploying a tactic called bunkering where they load up their machines with a ton of work and then sit on the finished results waiting for the event to start so that they can dump all of the extra results during the challenge time frame. So, it is very possible a lot of your work was getting validated at a later time. Another possibility is that the points for work shifts slightly over time as part of the credit system used. You will find that for one person one type of work unit may pay better than for another person. The next day another work unit type may pay slightly better. In the end they kind of evens out.

not exclisively, there are few other tasks like:
11791 boinc     39  19   77004  36764   2372 R 106.2  0.0  14:28.92 wcgrid_mcm1_map
12779 boinc     39  19   77004  36676   2312 R 106.2  0.0   3:29.29 wcgrid_mcm1_map
  415 boinc     39  19   77136  36916   2320 R 100.0  0.0 139:33.93 wcgrid_mcm1_map
 1283 boinc     39  19   77136  36956   2380 R 100.0  0.0 130:30.20 wcgrid_mcm1_map
 1514 boinc     39  19   77136  36880   2320 R 100.0  0.0 128:17.18 wcgrid_mcm1_map
 1522 boinc     39  19   77136  36952   2380 R 100.0  0.0 128:08.43 wcgrid_mcm1_map
 3015 boinc     39  19   77136  36856   2320 R 100.0  0.0 111:57.51 wcgrid_mcm1_map
 3701 boinc     39  19   77136  36924   2380 R 100.0  0.0 104:22.62 wcgrid_mcm1_map
 4085 boinc     39  19   77140  36908   2380 R 100.0  0.0 100:06.13 wcgrid_mcm1_map
 4822 boinc     39  19   77140  36904   2380 R 100.0  0.0  91:31.32 wcgrid_mcm1_map
 5533 boinc     39  19   77136  36892   2380 R 100.0  0.0  83:47.70 wcgrid_mcm1_map
 6267 boinc     39  19   77136  36880   2380 R 100.0  0.0  75:32.74 wcgrid_mcm1_map
10016 boinc     39  19   77004  36744   2320 R 100.0  0.0  34:08.22 wcgrid_mcm1_map
11130 boinc     39  19   77004  36764   2320 R 100.0  0.0  21:42.24 wcgrid_mcm1_map
12005 boinc     39  19   77004  36700   2312 R 100.0  0.0  12:06.78 wcgrid_mcm1_map
23870 boinc     39  19  337244 272312  48300 R 100.0  0.2 238:54.78 wcgrid_mip1_ros
23879 boinc     39  19  437288 362752  54036 R 100.0  0.3 238:55.29 wcgrid_mip1_ros
25413 boinc     39  19  407968 333420  53936 R 100.0  0.3 222:01.77 wcgrid_mip1_ros
25990 boinc     39  19   77268  37024   2380 R 100.0  0.0 215:37.21 wcgrid_mcm1_map
26771 boinc     39  19   77268  37016   2380 R 100.0  0.0 206:55.13 wcgrid_mcm1_map
26909 boinc     39  19   77272  37032   2380 R 100.0  0.0 205:26.09 wcgrid_mcm1_map
27058 boinc     39  19   77268  36968   2320 R 100.0  0.0 203:46.33 wcgrid_mcm1_map
28532 boinc     39  19   77136  37008   2380 R 100.0  0.0 187:26.61 wcgrid_mcm1_map
28944 boinc     39  19   77136  36992   2380 R 100.0  0.0 182:51.89 wcgrid_mcm1_map
30477 boinc     39  19   77140  36992   2380 R 100.0  0.0 165:53.40 wcgrid_mcm1_map
31516 boinc     39  19   77136  36972   2380 R 100.0  0.0 154:22.63 wcgrid_mcm1_map
31525 boinc     39  19   77136  36972   2380 R 100.0  0.0 154:17.46 wcgrid_mcm1_map
31554 boinc     39  19   77136  36976   2380 R 100.0  0.0 154:01.24 wcgrid_mcm1_map
31640 boinc     39  19   77136  36968   2380 R 100.0  0.0 153:03.18 wcgrid_mcm1_map
32117 boinc     39  19   77136  36968   2380 R 100.0  0.0 147:42.83 wcgrid_mcm1_map
 1043 boinc     39  19   77136  36880   2320 R  93.8  0.0 133:00.77 wcgrid_mcm1_map
 2198 boinc     39  19   77136  36928   2380 R  93.8  0.0 120:52.40 wcgrid_mcm1_map

but i was not using bunkering and i have big tasks queue, about 1000 tasks/machine so i'm not suffering from not having tasks
we will see during next days

[thesnat21]

Curious what the cause is...  Thanks for doing investigating guys!

Is there a new project on WCG that is harder than the others? 

I'd be curious to see what % is dedicated to each project

[cuarc001]

Are/have you been running MCM exclusively? And have you seen a slow down in the validation of work units? MCM require what is referred to as a wingman to validate the work units. Leading up to challenges, you will see numerous people deploying a tactic called bunkering where they load up their machines with a ton of work and then sit on the finished results waiting for the event to start so that they can dump all of the extra results during the challenge time frame. So, it is very possible a lot of your work was getting validated at a later time. Another possibility is that the points for work shifts slightly over time as part of the credit system used. You will find that for one person one type of work unit may pay better than for another person. The next day another work unit type may pay slightly better. In the end they kind of evens out.

not exclisively, there are few other tasks like:
11791 boinc     39  19   77004  36764   2372 R 106.2  0.0  14:28.92 wcgrid_mcm1_map
12779 boinc     39  19   77004  36676   2312 R 106.2  0.0   3:29.29 wcgrid_mcm1_map
  415 boinc     39  19   77136  36916   2320 R 100.0  0.0 139:33.93 wcgrid_mcm1_map
 1283 boinc     39  19   77136  36956   2380 R 100.0  0.0 130:30.20 wcgrid_mcm1_map
 1514 boinc     39  19   77136  36880   2320 R 100.0  0.0 128:17.18 wcgrid_mcm1_map
 1522 boinc     39  19   77136  36952   2380 R 100.0  0.0 128:08.43 wcgrid_mcm1_map
 3015 boinc     39  19   77136  36856   2320 R 100.0  0.0 111:57.51 wcgrid_mcm1_map
 3701 boinc     39  19   77136  36924   2380 R 100.0  0.0 104:22.62 wcgrid_mcm1_map
 4085 boinc     39  19   77140  36908   2380 R 100.0  0.0 100:06.13 wcgrid_mcm1_map
 4822 boinc     39  19   77140  36904   2380 R 100.0  0.0  91:31.32 wcgrid_mcm1_map
 5533 boinc     39  19   77136  36892   2380 R 100.0  0.0  83:47.70 wcgrid_mcm1_map
 6267 boinc     39  19   77136  36880   2380 R 100.0  0.0  75:32.74 wcgrid_mcm1_map
10016 boinc     39  19   77004  36744   2320 R 100.0  0.0  34:08.22 wcgrid_mcm1_map
11130 boinc     39  19   77004  36764   2320 R 100.0  0.0  21:42.24 wcgrid_mcm1_map
12005 boinc     39  19   77004  36700   2312 R 100.0  0.0  12:06.78 wcgrid_mcm1_map
23870 boinc     39  19  337244 272312  48300 R 100.0  0.2 238:54.78 wcgrid_mip1_ros
23879 boinc     39  19  437288 362752  54036 R 100.0  0.3 238:55.29 wcgrid_mip1_ros
25413 boinc     39  19  407968 333420  53936 R 100.0  0.3 222:01.77 wcgrid_mip1_ros
25990 boinc     39  19   77268  37024   2380 R 100.0  0.0 215:37.21 wcgrid_mcm1_map
26771 boinc     39  19   77268  37016   2380 R 100.0  0.0 206:55.13 wcgrid_mcm1_map
26909 boinc     39  19   77272  37032   2380 R 100.0  0.0 205:26.09 wcgrid_mcm1_map
27058 boinc     39  19   77268  36968   2320 R 100.0  0.0 203:46.33 wcgrid_mcm1_map
28532 boinc     39  19   77136  37008   2380 R 100.0  0.0 187:26.61 wcgrid_mcm1_map
28944 boinc     39  19   77136  36992   2380 R 100.0  0.0 182:51.89 wcgrid_mcm1_map
30477 boinc     39  19   77140  36992   2380 R 100.0  0.0 165:53.40 wcgrid_mcm1_map
31516 boinc     39  19   77136  36972   2380 R 100.0  0.0 154:22.63 wcgrid_mcm1_map
31525 boinc     39  19   77136  36972   2380 R 100.0  0.0 154:17.46 wcgrid_mcm1_map
31554 boinc     39  19   77136  36976   2380 R 100.0  0.0 154:01.24 wcgrid_mcm1_map
31640 boinc     39  19   77136  36968   2380 R 100.0  0.0 153:03.18 wcgrid_mcm1_map
32117 boinc     39  19   77136  36968   2380 R 100.0  0.0 147:42.83 wcgrid_mcm1_map
 1043 boinc     39  19   77136  36880   2320 R  93.8  0.0 133:00.77 wcgrid_mcm1_map
 2198 boinc     39  19   77136  36928   2380 R  93.8  0.0 120:52.40 wcgrid_mcm1_map

but i was not using bunkering and i have big tasks queue, about 1000 tasks/machine so i'm not suffering from not having tasks
we will see during next days

Just to be clear, I'm not implying that you are having trouble getting tasks. I'm saying the MCM tasks that you complete require a second person to also complete that work unit to verify it. No points are awarded until the work unit is returned AND verified. So, if someone else is bunkering, they may not return their work until their 10 day deadline approaches. Thus you may not have credit for your completed work units until they return theirs. IF they didn't complete on time, then someone else will be sent work units (typically a 4 day deadline) and then you have to wait for them to complete it and return it. So, in some instances you may have to wait up to 2 weeks or more to get the credit. When someone bunkers thousands of work units all at once, there is a possibility that several of your work units are not verified until they turn theirs in. That is why I was asking. If you look at each work unit on the WCG website, you can sort your work units by what is pending verification and pending validation (different scenarios). If your pendings have grown, it is probably from bunkering this large challenge.

If it isn't the pending work, then it is possible that the large amounts of people focusing on the WCG Birthday Challenge may be a case where the credits are adjusting based on other hardware being brought online. WCG uses a form of the Credit New credit system with a few modification the last I knew. Which means over time the points will adjust based on everyone else.

[thesnat21]

If it isn't the pending work, then it is possible that the large amounts of people focusing on the WCG Birthday Challenge may be a case where the credits are adjusting based on other hardware being brought online. WCG uses a form of the Credit New credit system with a few modification the last I knew. Which means over time the points will adjust based on everyone else.

Interesting, are you saying the overall rewards could go down based on the earnings of the "crowd"? 

[capulo]

ah sooo...
pending validation - 12 pages (15tasks /page)
pending verification - 1 page

this is amount of 1 average machine... , this could not be root cause of lower points

[cuarc001]

If it isn't the pending work, then it is possible that the large amounts of people focusing on the WCG Birthday Challenge may be a case where the credits are adjusting based on other hardware being brought online. WCG uses a form of the Credit New credit system with a few modification the last I knew. Which means over time the points will adjust based on everyone else.

Interesting, are you saying the overall rewards could go down based on the earnings of the "crowd"? 

That is what I'm implying yes.

How are points calculated?
Points are calculated in a two-step process which attempts to give a consistent number of points for similar amounts of research computation. First, the computational power/speed of the computer is determined by periodically running a benchmark calculation. Then, based on the central processing unit (CPU) time spent computing the research result for a work unit, the benchmark result is used to convert the time spent on a work unit into points. This adjusts the point value so that a slow computer or a fast computer would produce about the same number of points for calculating the research result for the same work unit. This value is the number of point credits "claimed" by the client. More information about that formula is available here.

Second, research results returned to the servers are validated in a manner which depends on the research project. Then the claimed points for valid results are examined for anomalous (excessively high or low compared to other machines computing the same or equivalent work unit) values and adjusted accordingly. The servers assign the resulting adjusted point values to the member (and team) for each of the returned work units. This process eliminates the ability for malicious users to tamper with results and artificially claim higher points for their work.

The system tries to average things out on its own but it isn't quick. People have dabbled with the system and have had varying results. I do not have the posts linked. However, new hosts added will sometimes score better than long term hosts. But over time it levels out. This may be what people are seeing. It may be something else. A lot of details are unknown.