Pages:
Author

Topic: BiblePay - New Coin Launch - Official Thread - page 62. (Read 119845 times)

full member
Activity: 126
Merit: 100

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:)
newbie
Activity: 41
Merit: 0

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. 
newbie
Activity: 27
Merit: 0
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 Smiley

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 Smiley

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.






 



full member
Activity: 345
Merit: 100

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.
full member
Activity: 345
Merit: 100
Quote
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.
newbie
Activity: 41
Merit: 0
Quote

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.

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.

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.
full member
Activity: 345
Merit: 100
Quote

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.

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.

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?
full member
Activity: 126
Merit: 100
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 Smiley

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 Smiley

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?
full member
Activity: 770
Merit: 100
now pool working stable VIVAT o/
full member
Activity: 406
Merit: 101
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 Smiley

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 Smiley

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.
full member
Activity: 126
Merit: 100
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 Smiley

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 Smiley

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"?!?!?
Really after 4 days mentioning this on this thread!?! REALLY!?!?! Problem devs created 8 HOURS ago not 8 DAYS.
newbie
Activity: 41
Merit: 0
Quote

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.


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.
full member
Activity: 159
Merit: 100
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 Smiley

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 Smiley
newbie
Activity: 28
Merit: 0
Religion and blockchain don't go in pair  Grin
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
Quick Update on Bible Pay Accountability:

During the period Before Sanctuaries go live and before autonomous Governance:

Lead Dev will sponsor the orphans manually under the Bible Pay web account.
Note that we received Our Orphan Sponsorship ID # : 07816292.

I successfully requested compassion to transfer our current 89 orphans into the BiblePay corporate account, and compassion approved and updated the request, meaning that future inbound orphan letters will be sent "To Biblepay" instead of to Robert (as some may have noticed in the Inbound Orphan letters).    The inbound letters actually flow in automatically now (as our service imports them).

The accountability link in the wallet should start working over the next hour.

We now have a Data driven menu- meaning that we can add Orphan Links to the accountability menu for Reports without affecting the Pool menus.

Now you can see how much we spent in the "Orphan Expenses" section.  I decided to just keep it very simple, as the auditors can determine total expenses based on $38 * quantity of Premiums Paid vs Quantity of "New" Sponsorships, so I think it is fine now- especially since this is temporary until sanctuaries go live.

Note that I spent $1000 more than we took in, since we are in maintenance at c-cex, and premiums were due today. (No sweat, Im glad to do that since this is a higher calling).


Today, our first batch of 19 letters were sent to Compassion, thanks everyone, for writing those letters, that makes a HUGE difference in these childrens lives.


Also, the bounties for the first 19 letters were PAID.  We will automate that also, very soon.


Things are coming together again, but we have a long way to go to make this totally autonomous.


full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
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 Smiley

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.
hero member
Activity: 714
Merit: 500
Sorry guys, have my son today, so I cant go into much detail.
Luckily, Ive got this new RDP program for my iphone so I was able to restart the pool remotely.

Anyway, 1.0.3.7 is finally out for download for windows.

Please upgrade, this version should reveal what is causing the pool to go down.

I will unban any nodes that are banned now.



Thanks.

The nodes are mining for a while and dropping off from the pool btw. [Linux, 1.0.3.7]
I tried deleting the banlist, debug files and clearing the bans as well with no avail.

Crap, I'm going to spin up a Linux box here shortly to help test too.  What distro are the Linux folks here using (I'm going to run Xubuntu from a USB drive most likely).


I'm using ubuntu 16.04 and 17.04

Me too, I'm using ubuntu 16.04  Wink
hero member
Activity: 906
Merit: 500
when masternodes come out?
I believe Christmas 2017.

As soon as things settle down we will head to the testnet thread on forum.biblepay.org, hopefully you can help test them.


We can also see in the code that it requires around 500k BBP for a single masternode, it seems that you'll also be able to run multiple nodes from a "controller" wallet.  Those are not definitive and could probably change anytime with an update.

But all looks very promising.
full member
Activity: 221
Merit: 100
holy smoke :


mike   mike2   41017.72   56968.49   118   9/16/2017 7:12:58 PM
mike   mike1   40944.48   56137.57   116   9/16/2017 7:12:55 PM
mike   mike3   40438.1   54116.66   111   9/16/2017 7:13:03 PM
full member
Activity: 221
Merit: 100
what does this mean ?

"poolinfo3": "HIGH_HASH; HIGH_HASH; ",

I'm getting it on some linux boxes
Pages:
Jump to: