Pages:
Author

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

hero member
Activity: 714
Merit: 500


I'm very curious to know how a machine with 3.5k HPS can get 78k HPS2, huge difference  Shocked

Does the owner of this machine in this forum? Mind to share what kind of CPU are you using?
PBrusky is doing it right now - he has an 8223 HPS box, and has 78 shares- its just luck.

HPS2 is based on solved shares now (for the current round).

The QWE guy already dropped in the leaderboard.


Yes, I also noticed QWE dropped from the leaderboard, it is truely just luck as you mentioned~~

Wait, I think I am partially wrong, I think its more than luck, he worked his way back to the top.  I think hes got more than one machine pointed to that miner.  Have to head to church.



So, if more than 1 miner to same worker, the HPS in the pool won't sum up?

Nothing important here actually, just my curiosity... Enjoy your weekend Smiley
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords


I'm very curious to know how a machine with 3.5k HPS can get 78k HPS2, huge difference  Shocked

Does the owner of this machine in this forum? Mind to share what kind of CPU are you using?
PBrusky is doing it right now - he has an 8223 HPS box, and has 78 shares- its just luck.

HPS2 is based on solved shares now (for the current round).

The QWE guy already dropped in the leaderboard.


Yes, I also noticed QWE dropped from the leaderboard, it is truely just luck as you mentioned~~

Wait, I think I am partially wrong, I think its more than luck, he worked his way back to the top.  I think hes got more than one machine pointed to that miner.  Have to head to church.

hero member
Activity: 714
Merit: 500


I'm very curious to know how a machine with 3.5k HPS can get 78k HPS2, huge difference  Shocked

Does the owner of this machine in this forum? Mind to share what kind of CPU are you using?
PBrusky is doing it right now - he has an 8223 HPS box, and has 78 shares- its just luck.

HPS2 is based on solved shares now (for the current round).

The QWE guy already dropped in the leaderboard.


Yes, I also noticed QWE dropped from the leaderboard, it is truely just luck as you mentioned~~
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords


I'm very curious to know how a machine with 3.5k HPS can get 78k HPS2, huge difference  Shocked

Does the owner of this machine in this forum? Mind to share what kind of CPU are you using?
PBrusky is doing it right now - he has an 8223 HPS box, and has 78 shares- its just luck.

HPS2 is based on solved shares now (for the current round).

The QWE guy already dropped in the leaderboard.
hero member
Activity: 714
Merit: 500


I'm very curious to know how a machine with 3.5k HPS can get 78k HPS2, huge difference  Shocked

Does the owner of this machine in this forum? Mind to share what kind of CPU are you using?
newbie
Activity: 14
Merit: 0
 Grin

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

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

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

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.

newbie
Activity: 41
Merit: 0
Quote

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.
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
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
newbie
Activity: 27
Merit: 0
@ 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.
newbie
Activity: 41
Merit: 0
@ 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.
full member
Activity: 462
Merit: 103
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 Smiley

[...] 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. Smiley
full member
Activity: 126
Merit: 100
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?
hero member
Activity: 714
Merit: 500

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 Grin

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


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 Grin
sr. member
Activity: 375
Merit: 250

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 😁
Pages:
Jump to: