BiblePay - New Coin Launch - Official Thread

[emdes]

A friend just told me that his hashrate dropped from 11k Hashps1 25-30k Hashps2, now he's getting 8k and 6k (Intel CPU) just by upgrading from 1.0.3.4 to 1.0.3.7 (same conf file). So it's not only me  

[oliwer21]

A friend just told me that his hashrate dropped from 11k Hashps1 25-30k Hashps2, now he's getting 8k and 6k (Intel CPU) just by upgrading from 1.0.3.4 to 1.0.3.7 (same conf file). So it's not only me  

I got drop from 25k to 15k on this upgrade.
Windows ver really sucks...
@Bible_pay we are posting problems here for about 5 pages and we are totaly ignored...

[slovakia]

but i have to write this: after upgrade wallet i get double coins like before 

[emdes]

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

[slovakia]

its true

[tiras]

what does this mean ?

"poolinfo3": "HIGH_HASH; HIGH_HASH; ",

I'm getting it on some linux boxes

[tiras]

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

[gigabyted]

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.

[seasonw]

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 

[bible_pay]

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.

[bible_pay]

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.

[KRT96]

Religion and blockchain don't go in pair 

[emdes]

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

[noob101]

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.

[oliwer21]

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

[616westwarmoth]

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.

[slovakia]

now pool working stable VIVAT o/

[oliwer21]

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?

[PhaseshiftUK]

<snip>
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?

[noob101]

<snip>
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.