BiblePay - New Coin Launch - Official Thread

[PhaseshiftUK]

may be this help
sudo add-apt-repository ppa:bitcoin/bitcoin
sudo apt-get update
sudo apt-get install -y libdb4.8-dev libdb4.8++-dev

but first step didnt work for me


root@vmi138854:/home/bible/biblepay# sudo add-apt-repository ppa:bitcoin/bitcoin
sudo: add-apt-repository: command not found

Okay, so it sounds like you aren't running Ubuntu, so that wouldn't work.

The error with ./configure this time is that it can't find the Berkeleydb 4.8 libraries to link against.  You might need to replace "${BDB_PREFIX}" in the command with the actual path.
If running
echo ${BDB_PREFIX}
displays nothing, then it doesn't know where the database libraries are to use.

[PhaseshiftUK]

<snip>
Interesting.  I wonder if the bottleneck is one of the Wine (Windows 'emulation') libraries.  Assuming that you compile the Windows version under Linux against the Wine libraries bible_pay?

I have also noticed that the wallet uses no pagefile resources at all,  so a bottleneck could be possible.

Unless you don't have much memory in your computer I wouldn't expect the wallet to need to use virtual memory (the pagefile on the disk), which is a good things as using memory in the pagefile really slows things down.  The resource intensive aspect of the wallet is processor usage for mining.

[Shoko943]

I don't care about the lower hashrate/payouts, but it's not really "fair" when linux get 2x hashrate on the same hardware. Just wanted to know why

Guys-  Its not getting ignored- we were moving like a steamroller until F7000 hit, and the issue is things have to be prioritized.

Its a higher priority to address Prod issues than "hashrate" issues.

Now it appears the pool is running again without issues so now I can take a look at the hash rate issues across OS.

The pool is storing the OS flavor per miner now, so I should be able to go in and write a report of average speed per OS flavor.

I do see that windows appears to hash at a much slower rate than linux for some reason.
Im seeing 34,000 HPS on my vultr-debian vs 4,000 on my dual CPU xeon windows web server.  Quite a disparity there.  Definitely unintentional from our engineering standpoint.

Yeah im not asking you to magically fix it over night, just look into it. Thanks

For me it sounds like magic cuz they compile against ddos and what we have got? SAME cpu usage but HALF of hash rate2. And it was only wallet upgrade...
And first devs answer was "7000k"?!?!?
Reall!?! Problem devs created 8 HOURS ago not 8 DAYS.

I get you are angry but compare this coin against other small coins.  We have an incredibly responsive Dev.  Block 7000 screwed a LOT of things up.  It was a major change to the algo.  So to fix it, core pieces of the software have to change.  This might change hash rates.  This is still a very new coin, I'm positive the Dev is looking into it.  There have been significant DDOS attacks occurring on this coin and the primary focus of the Dev has been to protect the pool, which is how a lot of newer users mine (and how many people prefer to mine).  So he has not had unlimited free time to fix this issue.

In the meantime, you have several options.  One, run Linux, which seems to be doing better than Windows on the issue.  Two, accept the lower hash rate and live with it until the fix is in, knowing MOST users are doing the same so we're all losing a similar hash rate.  Three, give up on BBP, take your CPU somewhere else and come back next year if you want when the bugs are hopefully all worked out.  Four, fix the problem and upload the solution to Github.

"Run linux" dev said the want support small miners and now "run linux"
There was not such problem with 7000block and even ddos. Prolem is with updates, what happend so special that dev must reduce windows hash on last update? BTW even your xeon-w3503_01 have 2x my ryzen 1700X (80% cpu usage, 37ghz all core) hasrate2... do you think it normal. Where all work from my cpu goes?
i don't want unpolite but miner vultr_debian4 is now in top 10 since 2-3 days, before never... who's this machine?(simple answer).
"We have an incredibly responsive Dev" Yes, for linux. They ignore ALL questions for past 3-4 days from windows users about hash rate. I now that bible_pay is running linux and he dont care windows...
BTW im not angry... i want just get atention of devs to get answers for questions that i make and other windows users. I only want to get through their "ignorance wall" ;P
P.S. Do You know why some users(on laderborad) have 8k HPS and 38k HPS2 and other with 36K HPS get also 38 HPS2?

The dev is not ignoring any question nor is he purposely introducing "bugs/limitations" for windows miners. If anything, you're wrong in assuming that biblepay is a linux guy as even the pool is running on windows.

The f7000 algorithm modification has been extensively talked about the past few weeks including why it was/is necessary and its consequences. There was major issues when it went live so our dev was busy dealing with all of that and I think he did an admirable job in dealing with that chaos. He was also busy fixing the pool and dealing with DDOS attacks so that you could still keep mining using it.

Finally, performance is something difficult to understand as there are so many factors affecting it; from your CPU, memory, disks, internet connectivity to w/e is running on your machine and could interfere with the mining software) and we're talking about a brand new algorithm on top of that! It could even only be an issue with how the hashrate is calculated VS your actual performances.

The performance issue on windows has only been there for a few days and Robert (biblepay) said that he is now looking into it. It might take a long time as troubleshooting performance issues on a specific platform is not an easy task.






 

[noob101]

<snip>
Interesting.  I wonder if the bottleneck is one of the Wine (Windows 'emulation') libraries.  Assuming that you compile the Windows version under Linux against the Wine libraries bible_pay?

I have also noticed that the wallet uses no pagefile resources at all,  so a bottleneck could be possible.

Unless you don't have much memory in your computer I wouldn't expect the wallet to need to use virtual memory (the pagefile on the disk), which is a good things as using memory in the pagefile really slows things down.  The resource intensive aspect of the wallet is processor usage for mining.

Yeah, I just checked my other miner.  Doesn't use pagefile either, but it uses all threads at same hashes per second.  Could be the algo used to filter out GPU and AISIC.  I have 3mb L3 cache and 4gb ram and it is running at less than 50%.  My processor runs at 46-50 degrees,  so cant be overheating either. 

[oliwer21]

The dev is not ignoring any question nor is he purposely introducing "bugs/limitations" for windows miners. If anything, you're wrong in assuming that biblepay is a linux guy as even the pool is running on windows.

The f7000 algorithm modification has been extensively talked about the past few weeks including why it was/is necessary and its consequences. There was major issues when it went live so our dev was busy dealing with all of that and I think he did an admirable job in dealing with that chaos. He was also busy fixing the pool and dealing with DDOS attacks so that you could still keep mining using it.

Finally, performance is something difficult to understand as there are so many factors affecting it; from your CPU, memory, disks, internet connectivity to w/e is running on your machine and could interfere with the mining software) and we're talking about a brand new algorithm on top of that! It could even only be an issue with how the hashrate is calculated VS your actual performances.

The performance issue on windows has only been there for a few days and Robert (biblepay) said that he is now looking into it. It might take a long time as troubleshooting performance issues on a specific platform is not an easy task.

Not only i have problem with performance on windows wallet and not only me wrote this, and we got ONE answer that dont explain anything.
Ok let's wait for response from devs:)

[civilufo]

The dev is not ignoring any question nor is he purposely introducing "bugs/limitations" for windows miners. If anything, you're wrong in assuming that biblepay is a linux guy as even the pool is running on windows.

The f7000 algorithm modification has been extensively talked about the past few weeks including why it was/is necessary and its consequences. There was major issues when it went live so our dev was busy dealing with all of that and I think he did an admirable job in dealing with that chaos. He was also busy fixing the pool and dealing with DDOS attacks so that you could still keep mining using it.

Finally, performance is something difficult to understand as there are so many factors affecting it; from your CPU, memory, disks, internet connectivity to w/e is running on your machine and could interfere with the mining software) and we're talking about a brand new algorithm on top of that! It could even only be an issue with how the hashrate is calculated VS your actual performances.

The performance issue on windows has only been there for a few days and Robert (biblepay) said that he is now looking into it. It might take a long time as troubleshooting performance issues on a specific platform is not an easy task.

Not only i have problem with performance on windows wallet and not only me wrote this, and we got ONE answer that dont explain anything.
Ok let's wait for response from devs:)

Honestly, if you are really impatient at waiting for dev to solve the problem, then I really suggest that you better come back later by end of this year, by the time biblepay will be stable. CPU mining still good to some other algorithm such as cryptonight 😁

[oliwer21]

The dev is not ignoring any question nor is he purposely introducing "bugs/limitations" for windows miners. If anything, you're wrong in assuming that biblepay is a linux guy as even the pool is running on windows.

The f7000 algorithm modification has been extensively talked about the past few weeks including why it was/is necessary and its consequences. There was major issues when it went live so our dev was busy dealing with all of that and I think he did an admirable job in dealing with that chaos. He was also busy fixing the pool and dealing with DDOS attacks so that you could still keep mining using it.

Finally, performance is something difficult to understand as there are so many factors affecting it; from your CPU, memory, disks, internet connectivity to w/e is running on your machine and could interfere with the mining software) and we're talking about a brand new algorithm on top of that! It could even only be an issue with how the hashrate is calculated VS your actual performances.

The performance issue on windows has only been there for a few days and Robert (biblepay) said that he is now looking into it. It might take a long time as troubleshooting performance issues on a specific platform is not an easy task.

Not only i have problem with performance on windows wallet and not only me wrote this, and we got ONE answer that dont explain anything.
Ok let's wait for response from devs:)

Honestly, if you are really impatient at waiting for dev to solve the problem, then I really suggest that you better come back later by end of this year, by the time biblepay will be stable. CPU mining still good to some other algorithm such as cryptonight 😁

i only want answer for question witch i asked 3 days ago. bible_pay was many times in thread and dont bother to answer. but compiled 3 wallets for linux on this time...  if you call me " impatient" so maybe i'am

[seasonw]

The dev is not ignoring any question nor is he purposely introducing "bugs/limitations" for windows miners. If anything, you're wrong in assuming that biblepay is a linux guy as even the pool is running on windows.

The f7000 algorithm modification has been extensively talked about the past few weeks including why it was/is necessary and its consequences. There was major issues when it went live so our dev was busy dealing with all of that and I think he did an admirable job in dealing with that chaos. He was also busy fixing the pool and dealing with DDOS attacks so that you could still keep mining using it.

Finally, performance is something difficult to understand as there are so many factors affecting it; from your CPU, memory, disks, internet connectivity to w/e is running on your machine and could interfere with the mining software) and we're talking about a brand new algorithm on top of that! It could even only be an issue with how the hashrate is calculated VS your actual performances.

The performance issue on windows has only been there for a few days and Robert (biblepay) said that he is now looking into it. It might take a long time as troubleshooting performance issues on a specific platform is not an easy task.

Not only i have problem with performance on windows wallet and not only me wrote this, and we got ONE answer that dont explain anything.
Ok let's wait for response from devs:)

Honestly, if you are really impatient at waiting for dev to solve the problem, then I really suggest that you better come back later by end of this year, by the time biblepay will be stable. CPU mining still good to some other algorithm such as cryptonight 😁

i only want answer for question witch i asked 3 days ago. bible_pay was many times in thread and dont bother to answer. but compiled 3 wallets for linux on this time...  if you call me " impatient" so maby i'am

I don't see dev compiled any wallet for linux, but dev compiled every single version for windows. For linux users, they have to compile it by themselves from github source code. And dev is working very hard to solve the problem, nobody like bugs in the wallet. I can't do anything to help dev on programming, but all I can do is continue mining, and observe the issues, then share to dev, this is what we can do to help dev to track down the issue, pretty much like a tester while mining. I also don't really enjoy uninstalling and reinstalling wallet, but I like to help dev on this meaningful coin, let us work together and help more orphans in the world.

Still, I suggest cryptonight algorithm, you can mine XMR, pretty stable, no bug at all, and you do not need to uninstall and reinstall wallet again and again. If you really want a stable version of biblepay mining, please come back once it is done, but not now.

[oliwer21]

I don't see dev compiled any wallet for linux, but dev compiled every single version for windows. For linux users, they have to compile it by themselves from github source code.

i didn't know that devs don't write wallet for linux....
don't you think, isn't  hard to write "we dont know, we working on it" when few people asking about same problem past 3 days?

[inblue]

Don't know if this will help, but I noticed while playing around on my windows machine using the setgenerate command, that the hash rate decreases exponentially for each tread added.  genproc 1 = 2000h/s,  genproc 2 = 3000h/s, genproc 3 = 3500h/s, genproc 4 = 3800.  I am using Intel i3 1.7ghz .
So basically each thread added is half of the added h/s of the previous thread.

This is spot on, I noticed the same thing, I just didn't have time to thoroughly analyze the numbers like you did. Good research. Also, by your other posts about pagefile etc. you don't seem like a noob at all

[...] fix the problem and upload the solution to Github.

If anything, you're wrong in assuming that biblepay is a linux guy as even the pool is running on windows.

I don't see dev compiled any wallet for linux, but dev compiled every single version for windows. For linux users, they have to compile it by themselves from github source code.

Very good points, 616westwarmoth, Shoko943 and seasonw.

[noob101]

@ Inblue, Thanks for the complement.  Im a noob when it comes to mining. started a month and a half ago.
I think the problem might be at the actual miner and not the wallet.  The cmd miners I used does not have GUI exept for Magi.  I know The newer ones as of this year has support for AES enabled processors and the like.  So maybe it due to those lovely features it might think we are AISIC miners on windows.  I am not familiar with Linux, but I have been a fan since ubuntu.  I am just putting my ideas out there, maybe it helps dev with the issues.

[Shoko943]

@ Inblue, Thanks for the complement.  Im a noob when it comes to mining. started a month and a half ago.
I think the problem might be at the actual miner and not the wallet.  The cmd miners I used does not have GUI exept for Magi.  I know The newer ones as of this year has support for AES enabled processors and the like.  So maybe it due to those lovely features it might think we are AISIC miners on windows.  I am not familiar with Linux, but I have been a fan since ubuntu.  I am just putting my ideas out there, maybe it helps dev with the issues.

The code doesn't have anything that tries to "detect" that you're an ASIC and slow you down. The dev is just trying to make the algorithm by itself extremely hard to be ported to GPUs or ASICs.

[bible_pay]

Hi All,

Yes let me clear up some misconceptions.

I have more windows servers myself than linux servers.  Ive been a .NET, c# and vb6 programmer for 25 years, and over the last 7 years have been doing some cross platform c++ programming for two blockchain projects, that is what originated biblepay, after those other projects "seemed" to have stabilized (lol).  So, I do have a propensity to program in c#, hence the reason the pool is in c#.  This shows that I had no intention to deliberately "hose" the windows guys.

Regarding compilation, I pulled all the bitcoin scripts to make a complete gitian build for : Linux, Windows and Mac and they do work now in Biblepay.  The only reason we dont have a PPA and Ubuntu distributed (binary) build of linux yet-is I want to hand that off to a config manager in the slack team.  We didnt cut any corners, and build windows only builds and say : Hey you linux guys are redheaded step children so you have to compile yourselves.  No, I envision having a PPA, and a config manager pushing the linux binaries to the website automatically (along with MAC).

The code is asic and gpu resistant.  It is not pulling any OS specific library in to make it run orders of magnitudes faster on any OS.  The code is 99% cross platform already.  Its being hung up by something very basic- I believe.  (As I cannot envision the cross compiled AES/c++/boost/misc dependencies to function with such a high disparity level).

We just have an issue where windows is hashing slower inside the miner, because it seems to be waiting for locks more than linux is. 

My GOAL is this:  To produce a binary release that hashes within a tolerance level of 10% across platforms.  I realize its frustrating to push a release that hashes 70% slower on the largest portion of the userbase, thats redicules.

So in light of that, my next priority is to look at the miner and see if we can bring Windows up to the same relative speed of Linux.

Rob

[noob101]

The code doesn't have anything that tries to "detect" that you're an ASIC and slow you down. The dev is just trying to make the algorithm by itself extremely hard to be ported to GPUs or ASICs.

Thanx for the info. Did not know its about portability. Thought it was a "detect algo"  lol.   What are your thoughts about that it could be the actual miner having trouble supporting the newer CPUs? Most of them are just adjustments to previous versions from 2012.  Or my other theory is that Windows are trying to manage cpu processes and causes bottle necks. And another is that the algorithm might be to awesome for windows to handle. Any input will be appreciated. I like to learn.

[bible_pay]

The code doesn't have anything that tries to "detect" that you're an ASIC and slow you down. The dev is just trying to make the algorithm by itself extremely hard to be ported to GPUs or ASICs.

Thanx for the info. Did not know its about portability. Thought it was a "detect algo"  lol.   What are your thoughts about that it could be the actual miner having trouble supporting the newer CPUs? Most of them are just adjustments to previous versions from 2012.  Or my other theory is that Windows are trying to manage cpu processes and causes bottle necks. And another is that the algorithm might be to awesome for windows to handle. Any input will be appreciated. I like to learn.

I would rule out the CPU type, extensions, and newer models first, and hone in on the OS being the problem first, as I have two clues already:
I have a dual xeon windows server 2008R2 that hashes at 4000, while the similar rented server hashes at 30,000 on vultr in Debian, and on my desktop PC, I have a 6 core AMD that hashes at 4,000 in windows, and in the Virtual machine on the same machine hashes at 4,000 in ubuntu (while the machine is 70% busy).  So in light of that, it sounds as if we have some type of mutex in windows...

Let me take a look at the OS priority levels and do some testing.

[noob101]

The code doesn't have anything that tries to "detect" that you're an ASIC and slow you down. The dev is just trying to make the algorithm by itself extremely hard to be ported to GPUs or ASICs.

Thanx for the info. Did not know its about portability. Thought it was a "detect algo"  lol.   What are your thoughts about that it could be the actual miner having trouble supporting the newer CPUs? Most of them are just adjustments to previous versions from 2012.  Or my other theory is that Windows are trying to manage cpu processes and causes bottle necks. And another is that the algorithm might be to awesome for windows to handle. Any input will be appreciated. I like to learn.

I would rule out the CPU type, extensions, and newer models first, and hone in on the OS being the problem first, as I have two clues already:
I have a dual xeon windows server 2008R2 that hashes at 4000, while the similar rented server hashes at 30,000 on vultr in Debian, and on my desktop PC, I have a 6 core AMD that hashes at 4,000 in windows, and in the Virtual machine on the same machine hashes at 4,000 in ubuntu (while the machine is 70% busy).  So in light of that, it sounds as if we have some type of mutex in windows...

Let me take a look at the OS priority levels and do some testing.

That's really weird. Your xeon gets 4000 and my i3 1.7 gets 3300 -  3500 on 3 threads. Did you see my post about the differences in hashing on different amount of threads?

[noob101]

Faulting application name: biblepay-qt.exe, version: 1.0.1.7, time stamp: 0x5685c180
Faulting module name: ntdll.dll, version: 10.0.15063.608, time stamp: 0x8274fd8b
Exception code: 0xc0000005
Fault offset: 0x000000000001b2b9
Faulting process id: 0x1e84
Faulting application start time: 0x01d32f911e97c4b2
Faulting application path: C:\Program Files\BiblepayCore\biblepay-qt.exe
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report Id: fcd49a4d-d98d-4eb1-9615-98c5d47fef19
Faulting package full name:
Faulting package-relative application ID:


This is from my event viewer.  I get a lot of perflib and perfnet errors too.  Dont know if these are related.  Maybe it can assist you. 

[bible_pay]

Faulting application name: biblepay-qt.exe, version: 1.0.1.7, time stamp: 0x5685c180
Faulting module name: ntdll.dll, version: 10.0.15063.608, time stamp: 0x8274fd8b
Exception code: 0xc0000005
Fault offset: 0x000000000001b2b9
Faulting process id: 0x1e84
Faulting application start time: 0x01d32f911e97c4b2
Faulting application path: C:\Program Files\BiblepayCore\biblepay-qt.exe
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report Id: fcd49a4d-d98d-4eb1-9615-98c5d47fef19
Faulting package full name:
Faulting package-relative application ID:


This is from my event viewer.  I get a lot of perflib and perfnet errors too.  Dont know if these are related.  Maybe it can assist you. 

Not really, were up to 1.0.3.7 now also.  I read all my eventviewer logs.

[noob101]

 

Not really, were up to 1.0.3.7 now also.  I read all my eventviewer logs.

This is what happens when i installed 1.0.3.7.  The wallet says 1.0.3.7, but the exe file in the installation folder is 1.0.1.7

[J1980]

 

Finally I got a Linux miner working.

I was already (also in support of the network) pool mining on a my (old) laptop got only 1769hashps lol and here ppl complaint about the speed and differents in OS.

But true I now got a wopping 4000.
Only took me almost whole day to compile ....

Keep up the good work,  and nice to see a coin that actually cares