inblue



Offline



Activity: 470

Merit: 103







Full MemberActivity: 470Merit: 103 Re: BiblePay - New Coin Launch - Official Thread September 13, 2017, 01:53:07 PM #1641 Quote from: bible_pay on September 13, 2017, 01:47:14 PM Quote from: inblue on September 13, 2017, 01:13:16 PM Quote from: oliwer21 on September 13, 2017, 11:02:41 AM BTW 5k coins of reward per block on pool and huge drop of hash is worth of mine for small miners...



@inblue what is your best cpu on witch you got such big hash?



Ahh... This is another topic I wanted to start, but I was too lazy. There are obviously some big changes in this new algo in ways I still don't quite understand. It seems that the algo actually favors mid-range and small miners, because stronger machines don't bring proportionally as much HPS2 (real HPS measured by pool). Now it's much better to have 10 small machines which have 8 threads each than to have 1 big machine which has 80 threads.



Here is a rough comparison of my miners:



blu1 = 16 cores, genproclimit 32, 64k HPS, 42k HPS2

blu2-3 = 24 cores, genproclimit 48, 64k HPS, 42k HPS2

blu4 = 40 cores, genproclimit 80, 55k HPS, 27k HPS2

blu5-9 = 2 cores, genproclimit 8, 17k HPS, 35k HPS2



First of all, why do blu2 and 3 have the same hashrate as blu1? In the previous algo they had about 530k while blu1 had about 350k, and these numbers are exactly proportionate to the number of cores (24 cores = 530k hps, 16 cores = 350k hps, divide them and you'll see, about 22k per core). Now both the 16 core one and the 24 core ones have the same hashrate, as if the CPU on the 24 core machines is not used to its fullest, but it is, it has 100% usage.



But the real mystery here is how in the world does a $20/mo shared VPS (blu5-9) outperform a $250/mo dedicated enterprise machine (blu4)? In the previous algo the high-spec machine was at the top of the leaderboard at around 830k hashrate and the cheap VPSs had around 70k each.

Ahh... This is another topic I wanted to start, but I was too lazy. There are obviously some big changes in this new algo in ways I still don't quite understand. It seems that the algo actually favors mid-range and small miners, because stronger machines don't bring proportionally as much HPS2 (real HPS measured by pool). Now it's much better to have 10 small machines which have 8 threads each than to have 1 big machine which has 80 threads.Here is a rough comparison of my miners:blu1 = 16 cores, genproclimit 32, 64k HPS,HPS2blu2-3 = 24 cores, genproclimit 48, 64k HPS,HPS2blu4 = 40 cores, genproclimit 80, 55k HPS,HPS2blu5-9 = 2 cores, genproclimit 8, 17k HPS,HPS2First of all, why do blu2 and 3 have the same hashrate as blu1? In the previous algo they had about 530k while blu1 had about 350k, and these numbers are exactly proportionate to the number of cores (24 cores = 530k hps, 16 cores = 350k hps, divide them and you'll see, about 22k per core). Now both the 16 core one and the 24 core ones have the same hashrate, as if the CPU on the 24 core machines is not used to its fullest, but it is, it has 100% usage.But the real mystery here is how in the world does a $20/mo shared VPS (blu5-9) outperform a $250/mo dedicated enterprise machine (blu4)? In the previous algo the high-spec machine was at the top of the leaderboard at around 830k hashrate and the cheap VPSs had around 70k each.

I can answer Part of this, but not entirely sure where the rest of the answer lies.

So the HPS2 column should not be brought into the equation in this case, because the pool is paying per Share found per round now, and HPS2 is now based on shares found in the round (Its something like shares found * 1000 * AgeDecayFactor) . So that column contains a bit of luck. Every share is equal also, so the higher power machines should be finding a proportionately higher number of shares.



But moving on, you show that the $20 blu5-9 hashed at 70k in the prior algo, now at 17k, and the $250 blu4 hashed at 800k prior and now at 80k. Meaning that before, you had received 12* the reward for the $250 server, and now you only receive 4* the reward (making the $20 equal to $80 per month, or, an extremely bad ROI). Yes, I see what you mean, the current algo is favoring the mid to small size machines.



So unless you disagree it sounds as if we should talk about why does the new algo favor the mid to small machines, correct?





I can answer Part of this, but not entirely sure where the rest of the answer lies.So the HPS2 column should not be brought into the equation in this case, because the pool is paying per Share found per round now, and HPS2 is now based on shares found in the round (Its something like shares found * 1000 * AgeDecayFactor) . So that column contains a bit of luck. Every share is equal also, so the higher power machines should be finding a proportionately higher number of shares.But moving on, you show that the $20 blu5-9 hashed at 70k in the prior algo, now at 17k, and the $250 blu4 hashed at 800k prior and now at 80k. Meaning that before, you had received 12* the reward for the $250 server, and now you only receive 4* the reward (making the $20 equal to $80 per month, or, an extremely bad ROI). Yes, I see what you mean, the current algo is favoring the mid to small size machines.So unless you disagree it sounds as if we should talk about why does the new algo favor the mid to small machines, correct?

Correct, exactly, you nailed it. Well, ideologically I guess it's not bad to favor the mid to small miners for high decentralization purposes, but I am still wondering from the technical side of things, is that a bug in the algo or something.



Quote from: bible_pay on September 13, 2017, 01:49:45 PM Quote from: inblue on September 13, 2017, 01:41:46 PM Quote from: bible_pay on September 13, 2017, 01:31:35 PM Please be ready for a mandatory upgrade in 4 hours.



I was born ready. Awesome work, very fast.



I see 1.0.3.2 is already on GitHub, so we can start the upgrade?

I was born ready.Awesome work, very fast.I see 1.0.3.2 is already on GitHub, so we can start the upgrade?

This way we can all sort of get in together.

Lets give it a couple hours at least, so the windows users have a "chance" to come online.This way we can all sort of get in together.

I get it. Do you happen to have the info on how many Windows users there are, compared to the Linux users? Correct, exactly, you nailed it. Well, ideologically I guess it's not bad to favor the mid to small miners for high decentralization purposes, but I am still wondering from the technical side of things, is that a bug in the algo or something.I get it. Do you happen to have the info on how many Windows users there are, compared to the Linux users?

noob101



Offline



Activity: 41

Merit: 0







NewbieActivity: 41Merit: 0 Re: BiblePay - New Coin Launch - Official Thread September 13, 2017, 02:10:43 PM #1645 .

According to me there is not much difference between a Aisic miner, aGPU rig and a server running multiple CPUs. I am glad this algo support small miners. I was really getting disgruntled with all the hardcore miners getting most of the coin. This is however besides the point.

I would like to mention for the record:

I have an Acer i3 1.7Ghz with 4GB ram. I get about the same constant in amount of coins regardless of what happens, give or take a few here and there. This is +- 1200 a day if I were to run 24 hours non stop.

The change in algo did not affect me much.

I did not get many banned peer issues.

My wallet is stable.

I have no withdrawal from pool to wallet issues.

I had the whole bad block error thing in my error log, but it did not affect my wallet or my miner.

I upgraded to 1.0.3.1 hassle free.

I am running the miner on 3 threads.

My cpu temp stays around and below 50 degrees.

I do not get any lag or interference from miner in the background while working on my laptop.



And I am very impressed with how the coin is managed. Hat off to the dev.





What do you have against windows users LOL,According to me there is not much difference between a Aisic miner, aGPU rig and a server running multiple CPUs. I am glad this algo support small miners. I was really getting disgruntled with all the hardcore miners getting most of the coin. This is however besides the point.I would like to mention for the record:I have an Acer i3 1.7Ghz with 4GB ram. I get about the same constant in amount of coins regardless of what happens, give or take a few here and there. This is +- 1200 a day if I were to run 24 hours non stop.The change in algo did not affect me much.I did not get many banned peer issues.My wallet is stable.I have no withdrawal from pool to wallet issues.I had the whole bad block error thing in my error log, but it did not affect my wallet or my miner.I upgraded to 1.0.3.1 hassle free.I am running the miner on 3 threads.My cpu temp stays around and below 50 degrees.I do not get any lag or interference from miner in the background while working on my laptop.And I am very impressed with how the coin is managed. Hat off to the dev.

tiras



Offline



Activity: 229

Merit: 100







Full MemberActivity: 229Merit: 100 Re: BiblePay - New Coin Launch - Official Thread September 13, 2017, 02:17:22 PM #1646 Quote from: inblue on September 13, 2017, 01:13:16 PM Quote from: oliwer21 on September 13, 2017, 11:02:41 AM BTW 5k coins of reward per block on pool and huge drop of hash is worth of mine for small miners...



@inblue what is your best cpu on witch you got such big hash?



Ahh... This is another topic I wanted to start, but I was too lazy. There are obviously some big changes in this new algo in ways I still don't quite understand. It seems that the algo actually favors mid-range and small miners, because stronger machines don't bring proportionally as much HPS2 (real HPS measured by pool). Now it's much better to have 10 small machines which have 8 threads each than to have 1 big machine which has 80 threads.



Here is a rough comparison of my miners:



blu1 = 16 cores, genproclimit 32, 64k HPS, 42k HPS2

blu2-3 = 24 cores, genproclimit 48, 64k HPS, 42k HPS2

blu4 = 40 cores, genproclimit 80, 55k HPS, 27k HPS2

blu5-9 = 2 cores, genproclimit 8, 17k HPS, 35k HPS2



First of all, why do blu2 and 3 have the same hashrate as blu1? In the previous algo they had about 530k while blu1 had about 350k, and these numbers are exactly proportionate to the number of cores (24 cores = 530k hps, 16 cores = 350k hps, divide them and you'll see, about 22k per core). Now both the 16 core one and the 24 core ones have the same hashrate, as if the CPU on the 24 core machines is not used to its fullest, but it is, it has 100% usage.



But the real mystery here is how in the world does a $20/mo shared VPS (blu5-9) outperform a $250/mo dedicated enterprise machine (blu4)? In the previous algo the high-spec machine was at the top of the leaderboard at around 830k hashrate and the cheap VPSs had around 70k each.

Ahh... This is another topic I wanted to start, but I was too lazy. There are obviously some big changes in this new algo in ways I still don't quite understand. It seems that the algo actually favors mid-range and small miners, because stronger machines don't bring proportionally as much HPS2 (real HPS measured by pool). Now it's much better to have 10 small machines which have 8 threads each than to have 1 big machine which has 80 threads.Here is a rough comparison of my miners:blu1 = 16 cores, genproclimit 32, 64k HPS,HPS2blu2-3 = 24 cores, genproclimit 48, 64k HPS,HPS2blu4 = 40 cores, genproclimit 80, 55k HPS,HPS2blu5-9 = 2 cores, genproclimit 8, 17k HPS,HPS2First of all, why do blu2 and 3 have the same hashrate as blu1? In the previous algo they had about 530k while blu1 had about 350k, and these numbers are exactly proportionate to the number of cores (24 cores = 530k hps, 16 cores = 350k hps, divide them and you'll see, about 22k per core). Now both the 16 core one and the 24 core ones have the same hashrate, as if the CPU on the 24 core machines is not used to its fullest, but it is, it has 100% usage.But the real mystery here is how in the world does a $20/mo shared VPS (blu5-9) outperform a $250/mo dedicated enterprise machine (blu4)? In the previous algo the high-spec machine was at the top of the leaderboard at around 830k hashrate and the cheap VPSs had around 70k each.

I second this analysis. well done.

another thing to mention is that 1.0.3.1 linux outperfomed win version running on a higher end hardware.

in my case ryzen7 with linux had x10 times hashrate compared to win. I second this analysis. well done.another thing to mention is that 1.0.3.1 linux outperfomed win version running on a higher end hardware.in my case ryzen7 with linux had x10 times hashrate compared to win. BiblePay (BBP) | Reddit - Twitter - Forum - Slack - Discord | C-CEX - CoinsMarkets | Love one another, be a good Samaritan, help those in distress and spread the gospel

bible_pay



Offline



Activity: 1022

Merit: 215





Jesus is the King of Kings and Lord of Lords







Full MemberActivity: 1022Merit: 215Jesus is the King of Kings and Lord of Lords Re: BiblePay - New Coin Launch - Official Thread September 13, 2017, 02:39:04 PM #1651 Quote from: inblue on September 13, 2017, 01:53:07 PM

I get it. Do you happen to have the info on how many Windows users there are, compared to the Linux users?



This is just a guess, since I dont have those figures, although that brings up a good point, that we should make an attempt to grab those figures for development purposes.



Based on my experience with other coins, believe it or not, its usually an 80% windows download rate, 20% linux (1% mac).

However, I believe with BiblePay, we have a handful of grass-root linux supporters who seem to run a high quantity of nodes (IE they seem to

have excess money laying around for hobbies, and/or have some relationship to cloudmining). We might be attracting people who deal with excess PC resources, being the only coin that hasnt been exploited by GPUs.



Anyway, Im going to guess that out of 750 users, 70% are still PC users, but I believe personally that if you went with node count, we would be along the lines of 1000 nodes with 50% being linux nodes... So the linux count is probably skewed due to ROI and huge quantity per hobbyist.



(There are stories on the internet of some coins that tried to launch as linux-only, and they always died.)



This is just a guess, since I dont have those figures, although that brings up a good point, that we should make an attempt to grab those figures for development purposes.Based on my experience with other coins, believe it or not, its usually an 80% windows download rate, 20% linux (1% mac).However, I believe with BiblePay, we have a handful of grass-root linux supporters who seem to run a high quantity of nodes (IE they seem tohave excess money laying around for hobbies, and/or have some relationship to cloudmining). We might be attracting people who deal with excess PC resources, being the only coin that hasnt been exploited by GPUs.Anyway, Im going to guess that out of 750 users, 70% are still PC users, but I believe personally that if you went with node count, we would be along the lines of 1000 nodes with 50% being linux nodes... So the linux count is probably skewed due to ROI and huge quantity per hobbyist.(There are stories on the internet of some coins that tried to launch as linux-only, and they always died.) Bible Pay 🕇

🕇 Announcement | Forum  Slack  Discord  Reddit  Twitter | SouthXChange

🕇 A Christian cryptocurrency | Supporting orphans through a decentralized autonomous charity 🕇

bible_pay



Offline



Activity: 1022

Merit: 215





Jesus is the King of Kings and Lord of Lords







Full MemberActivity: 1022Merit: 215Jesus is the King of Kings and Lord of Lords Re: BiblePay - New Coin Launch - Official Thread September 13, 2017, 02:53:32 PM #1654 Quote from: inblue on September 13, 2017, 01:53:07 PM





Correct, exactly, you nailed it. Well, ideologically I guess it's not bad to favor the mid to small miners for high decentralization purposes, but I am still wondering from the technical side of things, is that a bug in the algo or something.







Alrighty a guess and some homework for you is all I can offer on this today:



So the old algorithm had an outer loop of 1000 X11 hashes and an inner loop of one biblepay hash, meaning that if you ran 80 threads on x11-bbp pre F7000, that distributed thread could conduct its hashing without the resources of the full node. (Whenever the miner needs to access the resources of the full node, for example, asking it for AES/md5/chaining the KJV together) grabbing the pindex bestblockindex map, it is in a way locking the thread for a few milliseconds and grabbing its data and then continuing. In the NEW world, in F7000, its hashing only one X11 hash (for the blockindex), yet 1000 BibleHashes of work being expended per loop. So its no longer able to decentralize a thread with just a math problem (IE x11 solution), and come back and join the rest of the threads, instead, its doing a lot of biblehash->askfullnode->biblehash->askfullnode, etc.



So my guess is this: In f7000, there is a strong reliance on the full nodes availablility, and the thread itself can only do so much work before its waiting around for availablility of the data it needs (like a blockindex for example, from the map). The reason the kernel cant allow two threads to read the same value simultaneously is that would cause a segfault error.



So what I recommend is this: Find a way to run multiple copies of biblepay on one server, and do a side by side comparison of those specs with the sum of the hash of biblepay instances. If the hash throughput is higher on the multiple copies, then we know that I said above is true and the only way to consolidate hardware to high power servers is then to run multiple instances per node.



On a side note if we find that to be the case then that is good- as you said earlier -part of the benefit of requiring the full node is to reward the decentralized full node environment (IE not the people with the biggest nodes) as part of the original vision is to not be greed based but to be service oriented.



Alrighty a guess and some homework for you is all I can offer on this today:So the old algorithm had an outer loop of 1000 X11 hashes and an inner loop of one biblepay hash, meaning that if you ran 80 threads on x11-bbp pre F7000, that distributed thread could conduct its hashing without the resources of the full node. (Whenever the miner needs to access the resources of the full node, for example, asking it for AES/md5/chaining the KJV together) grabbing the pindex bestblockindex map, it is in a way locking the thread for a few milliseconds and grabbing its data and then continuing. In the NEW world, in F7000, its hashing only one X11 hash (for the blockindex), yet 1000 BibleHashes of work being expended per loop. So its no longer able to decentralize a thread with just a math problem (IE x11 solution), and come back and join the rest of the threads, instead, its doing a lot of biblehash->askfullnode->biblehash->askfullnode, etc.So my guess is this: In f7000, there is a strong reliance on the full nodes availablility, and the thread itself can only do so much work before its waiting around for availablility of the data it needs (like a blockindex for example, from the map). The reason the kernel cant allow two threads to read the same value simultaneously is that would cause a segfault error.So what I recommend is this: Find a way to run multiple copies of biblepay on one server, and do a side by side comparison of those specs with the sum of the hash of biblepay instances. If the hash throughput is higher on the multiple copies, then we know that I said above is true and the only way to consolidate hardware to high power servers is then to run multiple instances per node.On a side note if we find that to be the case then that is good- as you said earlier -part of the benefit of requiring the full node is to reward the decentralized full node environment (IE not the people with the biggest nodes) as part of the original vision is to not be greed based but to be service oriented. Bible Pay 🕇

🕇 Announcement | Forum  Slack  Discord  Reddit  Twitter | SouthXChange

🕇 A Christian cryptocurrency | Supporting orphans through a decentralized autonomous charity 🕇

inblue



Offline



Activity: 470

Merit: 103







Full MemberActivity: 470Merit: 103 Re: BiblePay - New Coin Launch - Official Thread September 13, 2017, 03:24:47 PM #1658 Quote from: bible_pay on September 13, 2017, 02:39:04 PM Quote from: inblue on September 13, 2017, 01:53:07 PM

I get it. Do you happen to have the info on how many Windows users there are, compared to the Linux users?



This is just a guess, since I dont have those figures, although that brings up a good point, that we should make an attempt to grab those figures for development purposes.



Based on my experience with other coins, believe it or not, its usually an 80% windows download rate, 20% linux (1% mac).

However, I believe with BiblePay, we have a handful of grass-root linux supporters who seem to run a high quantity of nodes (IE they seem to

have excess money laying around for hobbies, and/or have some relationship to cloudmining). We might be attracting people who deal with excess PC resources, being the only coin that hasnt been exploited by GPUs.



Anyway, Im going to guess that out of 750 users, 70% are still PC users, but I believe personally that if you went with node count, we would be along the lines of 1000 nodes with 50% being linux nodes... So the linux count is probably skewed due to ROI and huge quantity per hobbyist.



(There are stories on the internet of some coins that tried to launch as linux-only, and they always died.)

This is just a guess, since I dont have those figures, although that brings up a good point, that we should make an attempt to grab those figures for development purposes.Based on my experience with other coins, believe it or not, its usually an 80% windows download rate, 20% linux (1% mac).However, I believe with BiblePay, we have a handful of grass-root linux supporters who seem to run a high quantity of nodes (IE they seem tohave excess money laying around for hobbies, and/or have some relationship to cloudmining). We might be attracting people who deal with excess PC resources, being the only coin that hasnt been exploited by GPUs.Anyway, Im going to guess that out of 750 users, 70% are still PC users, but I believe personally that if you went with node count, we would be along the lines of 1000 nodes with 50% being linux nodes... So the linux count is probably skewed due to ROI and huge quantity per hobbyist.(There are stories on the internet of some coins that tried to launch as linux-only, and they always died.)

Very interesting analysis, thank you. I had the exact same thoughts about Linux hobbyists with money or a relationship to cloud mining or access to a lot of unused PCs, perhaps even in some organization.



Do you think there's a way to make the wallet detect OS version so that you could then run a report command just like with version numbers?





Quote from: bible_pay on September 13, 2017, 02:53:32 PM Quote from: inblue on September 13, 2017, 01:53:07 PM Correct, exactly, you nailed it. Well, ideologically I guess it's not bad to favor the mid to small miners for high decentralization purposes, but I am still wondering from the technical side of things, is that a bug in the algo or something.



Alrighty a guess and some homework for you is all I can offer on this today:



So the old algorithm had an outer loop of 1000 X11 hashes and an inner loop of one biblepay hash, meaning that if you ran 80 threads on x11-bbp pre F7000, that distributed thread could conduct its hashing without the resources of the full node. (Whenever the miner needs to access the resources of the full node, for example, asking it for AES/md5/chaining the KJV together) grabbing the pindex bestblockindex map, it is in a way locking the thread for a few milliseconds and grabbing its data and then continuing. In the NEW world, in F7000, its hashing only one X11 hash (for the blockindex), yet 1000 BibleHashes of work being expended per loop. So its no longer able to decentralize a thread with just a math problem (IE x11 solution), and come back and join the rest of the threads, instead, its doing a lot of biblehash->askfullnode->biblehash->askfullnode, etc.



So my guess is this: In f7000, there is a strong reliance on the full nodes availablility, and the thread itself can only do so much work before its waiting around for availablility of the data it needs (like a blockindex for example, from the map). The reason the kernel cant allow two threads to read the same value simultaneously is that would cause a segfault error.



So what I recommend is this: Find a way to run multiple copies of biblepay on one server, and do a side by side comparison of those specs with the sum of the hash of biblepay instances. If the hash throughput is higher on the multiple copies, then we know that I said above is true and the only way to consolidate hardware to high power servers is then to run multiple instances per node.



On a side note if we find that to be the case then that is good- as you said earlier -part of the benefit of requiring the full node is to reward the decentralized full node environment (IE not the people with the biggest nodes) as part of the original vision is to not be greed based but to be service oriented.



Alrighty a guess and some homework for you is all I can offer on this today:So the old algorithm had an outer loop of 1000 X11 hashes and an inner loop of one biblepay hash, meaning that if you ran 80 threads on x11-bbp pre F7000, that distributed thread could conduct its hashing without the resources of the full node. (Whenever the miner needs to access the resources of the full node, for example, asking it for AES/md5/chaining the KJV together) grabbing the pindex bestblockindex map, it is in a way locking the thread for a few milliseconds and grabbing its data and then continuing. In the NEW world, in F7000, its hashing only one X11 hash (for the blockindex), yet 1000 BibleHashes of work being expended per loop. So its no longer able to decentralize a thread with just a math problem (IE x11 solution), and come back and join the rest of the threads, instead, its doing a lot of biblehash->askfullnode->biblehash->askfullnode, etc.So my guess is this: In f7000, there is a strong reliance on the full nodes availablility, and the thread itself can only do so much work before its waiting around for availablility of the data it needs (like a blockindex for example, from the map). The reason the kernel cant allow two threads to read the same value simultaneously is that would cause a segfault error.So what I recommend is this: Find a way to run multiple copies of biblepay on one server, and do a side by side comparison of those specs with the sum of the hash of biblepay instances. If the hash throughput is higher on the multiple copies, then we know that I said above is true and the only way to consolidate hardware to high power servers is then to run multiple instances per node.On a side note if we find that to be the case then that is good- as you said earlier -part of the benefit of requiring the full node is to reward the decentralized full node environment (IE not the people with the biggest nodes) as part of the original vision is to not be greed based but to be service oriented.

A bit more technical lingo than I am able to handle right now, but I got the gist of it. I have some errands to do now, but in the evening or tomorrow I will try to run two nodes on one machine and will report back with the results, to see if your theory is correct (I have a feeling it is). Very interesting analysis, thank you. I had the exact same thoughts about Linux hobbyists with money or a relationship to cloud mining or access to a lot of unused PCs, perhaps even in some organization.Do you think there's a way to make the wallet detect OS version so that you could then run a report command just like with version numbers?A bit more technical lingo than I am able to handle right now, but I got the gist of it.I have some errands to do now, but in the evening or tomorrow I will try to run two nodes on one machine and will report back with the results, to see if your theory is correct (I have a feeling it is).