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

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:)

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. 

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.






 

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.

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.

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

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?

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

now pool working stable VIVAT o/

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.

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.

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.

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

Religion and blockchain don't go in pair 

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.

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.

Me too, I'm using ubuntu 16.04 

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.

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

what does this mean ?

"poolinfo3": "HIGH_HASH; HIGH_HASH; ",

I'm getting it on some linux boxes