BiblePay - TestNet Thread - Pool Testing for Proof of Bible Hash Pool (PoBh)

[bible_pay]

On the pool issue, I had to throw the switch to enforce the new version.
Ensure you have 1.0.2.4+ running, and it should run fine.

all my workers < v.1.0.2.4 are cut off. 

could you point to clear instructions how to upgrade linux clients ? 

The same way you upgrade from 1.0.1.9 to 1.0.2.3, upgrade your client before mining.

[1714022839]

1714022839

[1714022839]

1714022839

[bible_pay]

I think the pool is down.

DEVs can probably give at least a few hours notice before cutting off people .  
now we have 100s CPUs running and not hitting the pool .
 it gets pretty frustrated .

First of all, I will definitely be giving a notice for maintenance when the pool is in Prod and its going to go down.
The pool is not even in Prod yet.

As far as today is concerned, I had to move the rack and I left it plugged in and it went down without me knowing - sorry about that.

Anyway, your clients will solo mine when you lose the pool connection, so its not really a problem.  The latest version doesnt have the issue where it slows down as it only checks on pool health once every 5 minutes or so.  

[bible_pay]

Yeah, sorry I didn't have time until this morning to sit down and crank the numbers.

So I did two -reindexes under 1.0.2.3, and they were pretty successful, just wouldn't sync the last block or two very timely.

Went into <user>/AppData/Roaming/Biblepaycore/testnet3/...  Blocks/ .... Chainstate/ and Blocks/Index.  Deleted all the files in those folders.  Restarted wallet, it got to the "no block sources available" message in about 20 seconds, again under 1.0.2.3.

Downloaded 1.0.2.4, installed, -reindex worked quickly, syched.  Shut it down, deleted the files again, restarted.  It rebuilt everything in under 1 min.  Synched.  Did one more -reindex, took a lot longer and wouldn't full sych, but I shut it down, the restarted without the -reindex and it got the last bit and was successful.  My test balance was unfazed by all of this (no issues).

Used showblock on a handful of blocks, noticed I just narrowly missed testblock 666 (got 665 and 667).  And noticed the genesis block does not contain a verse from Genesis.  I'm still not very adept at reading the showblock stats, other than the very obvious ones.  I wasn't sure on the block how to see "who" mined it to verify the blocks I mined in test showed that, but other than that, it was good.

LOL, that would be hilarious if we had "In the beginning, God created..." in the Genesis block, dang I wish I would have thought of that before we went live while mining the genesis block.  I could have probably left it mine until it hit a verse from Genesis.


Good, thanks for all the testing.  My tests pretty much are equivalent to yours as far as resyncing and reindexing.

Looks like we are close to make a 1.0.2.6 version for the mandatory, unless someone raises an issue within 2 days or so.

EDIT:
Hey, I think you just gave an idea for a new feature.  We can probably hardcode In the beginning in the Prod chain for block 0, that would be a nice twist for this coin.

[togoshigekata]

Dev dont worry about the haters, youre doing fantastic work!

[tiras]

Dev dont worry about the haters, youre doing fantastic work!

this is really below the belt.   nobody hates anybody here and the DEVs are doing great job . 

it's just the about the team work here .  If we are doing a common job we should be in sync .

[tiras]

On the pool issue, I had to throw the switch to enforce the new version.
Ensure you have 1.0.2.4+ running, and it should run fine.

all my workers < v.1.0.2.4 are cut off. 

could you point to clear instructions how to upgrade linux clients ? 

The same way you upgrade from 1.0.1.9 to 1.0.2.3, upgrade your client before mining.

I didn't do upgrade on linux yet . 
installed it from 1.0.2.3  sources. 
 that's  why I'm asking for help upgrading it further

[tiras]

On the pool issue, I had to throw the switch to enforce the new version.
Ensure you have 1.0.2.4+ running, and it should run fine.

all my workers < v.1.0.2.4 are cut off. 

could you point to clear instructions how to upgrade linux clients ? 

The same way you upgrade from 1.0.1.9 to 1.0.2.3, upgrade your client before mining.

I didn't do upgrade on linux yet . 
installed it from 1.0.2.3  sources. 
 that's  why I'm asking for help upgrading it further

NVM.  I figured it myself

[jaapgvk]

So everything is passing in test?  Westwarmoth, has anyone tried reindexing there blocks file yet in testnet?

Could you (or happy_merchant) explain how to do this? I'd be happy to do it, but I don't know where to start.

Also: the pools on both testnet and main seem to have issues at the moment. All my miners have reverted to solo-mining. And it looks like a lot of other miners also disappeared from the leaderboard.

On the pool issue, I had to throw the switch to enforce the new version.
Ensure you have 1.0.2.4+ running, and it should run fine.

On reindex block chain, start the wallet with '-testnet -reindex' and ensure it recovers with no errors to the top.
Then start in -testnet mode with no blocks, database, and chainstate and ensure it syncs to the top?

Thanks!

I first updated all my wallets to 1.0.2.5. and then I did a reindex on the mainchain wallets. This went without any issues.
I then started a testnet wallet with no blocks etc, and that also synced without any problems. It's poolmining on testnet now

The pool still does seem to have some issues though. It seems my miners jump on and off the pool at seemingly random intervals.

This is the mininginfo I got from my four mainnet miners at about the same time:

{
  "blocks": 5411,
  "currentblocksize": 2059,
  "currentblocktx": 4,
  "difficulty": 0.06419642745191464,
  "errors": "",
  "genproclimit": 7,
  "networkhashps": 168700.7953206531,
  "hashps": 34141.63594535423,
  "minerstarttime": "08-30-2017 16:30:29",
  "pooledtx": 4,
  "testnet": false,
  "chain": "main",
  "biblepay-generate": true,
  "poolinfo1": "",
  "poolinfo2": "",
  "poolinfo3": "CFW 08-30-2017 19:40:11; ",
  "miningpulse": 12081,
  "poolmining": true
}



{
  "blocks": 5411,
  "currentblocksize": 2059,
  "currentblocktx": 4,
  "difficulty": 0.0641964274519146get4,
  "errors": "",
  "genproclimit": 10,
  "networkhashps": 168700.7953206531,
  "hashps": 57553.43191954364,
  "minerstarttime": "08-30-2017 16:31:57",
  "pooledtx": 4,
  "testnet": false,
  "chain": "main",
  "biblepay-generate": true,
  "poolinfo1": "B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; ",
  "poolinfo2": "RM_08-30-2017 19:38:57; RM_08-30-2017 19:39:13; RM_08-30-2017 19:39:20; Submitting Solution 08-30-2017 19:39:25; RM_08-30-2017 19:39:16; RM_08-30-2017 19:38:50; RM_08-30-2017 19:39:20; RM_08-30-2017 19:38:53; ",
  "poolinfo3": "POOL DOWN-REVERTING TO SOLO MINING; POOL DOWN-REVERTING TO SOLO MINING; POOL DOWN-REVERTING TO SOLO MINING; POOL DOWN-REVERTING TO SOLO MINING; POOL DOWN-REVERTING TO SOLO MINING; POOL DOWN-REVERTING TO SOLO MINING; POOL DOWN-REVERTING TO SOLO MINING; POOL DOWN-REVERTING TO SOLO MINING; POOL DOWN-REVERTING TO SOLO MINING; ",
  "miningpulse": 20495,
  "poolmining": true
}




{
  "blocks": 5411,
  "currentblocksize": 2059,
  "currentblocktx": 4,
  "difficulty": 0.06419642745191464,
  "errors": "",
  "genproclimit": 9,
  "networkhashps": 168700.7953206531,
  "hashps": 57725.4744221154,
  "minerstarttime": "08-30-2017 16:31:29",
  "pooledtx": 4,
  "testnet": false,
  "chain": "main",
  "biblepay-generate": true,
  "poolinfo1": "B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; ",
  "poolinfo2": "RM_08-30-2017 19:39:53; RM_08-30-2017 19:39:49; RM_08-30-2017 19:39:57; ",
  "poolinfo3": "POOL DOWN-REVERTING TO SOLO MINING; CFW 08-30-2017 19:39:32; ",
  "miningpulse": 20364,
  "poolmining": true
}



{
  "blocks": 5411,
  "currentblocksize": 2059,
  "currentblocktx": 4,
  "difficulty": 0.06419642745191464,
  "errors": "",
  "genproclimit": 3,
  "networkhashps": 168700.7953206531,
  "hashps": 53349.53213422249,
  "minerstarttime": "08-30-2017 17:30:51",
  "pooledtx": 4,
  "testnet": false,
  "chain": "main",
  "biblepay-generate": true,
  "poolinfo1": "B9LeH2D3pxTHcssNhgBqseJekonk1q36w8; ",
  "poolinfo2": "RM_08-30-2017 19:32:52; ",
  "poolinfo3": "",
  "miningpulse": 20053,
  "poolmining": true
}



The hashrate in the pool is also lower than expected. But maybe that's because they are jumping on and off.
The "poolmining" tag also sometimes switches to 'false'.

[inblue]

Anyway, your clients will solo mine when you lose the pool connection, so its not really a problem.

The hashrate in the pool is also lower than expected. But maybe that's because they are jumping on and off.
The "poolmining" tag also sometimes switches to 'false'.

There is a problem with this and I'm talking about the main net. Mining constantly switches between pool and solo (true/false) and it definitely affects performance. Even in the short periods of time when "poolmining" says "true", there's always the "POOL DOWN-REVERTING TO SOLO MINING" error in the "poolinfo3". With the constant switching we are not mining the same as without switching (e.g. number of shares submitted), because I see that CPU usage is all over the place, at times even dropping to less than 10% instead of the constant 99%. The hash rate also plummets during the constant jumping from solo to pool and vice versa. This probably also affects solo mining because I'm not sure how effective is to solo mine for only a few seconds and then get interrupted again.

Also, when I stopped mining on one of the computers and then resumed, it could never go back to its previously established hash rate, but only around 60% of it, while other identical machines are still on the same hash rate, as though there's some kind of an age priority. If it's of any significance, on the restarted machine, "miningpulse" parameter is around 6000, while on the uninterrupted ones it's about 500K.

Isn't all this just a simple issue with the lack of CPU power on the server? I mean, it could be easily solved by employing a more powerful server and I bet that a few people here would be willing to donate for the costs, myself included. Or simply open source the pool and somebody will host it on a higher-end machine.

[Iuliu]

The hashrate is half as before and at pollinfo3 it says that is down and returning to minningpolo.

Does need to upgrade the wallet to the latest version of 1.0.2.5? How i do the upgrade in windows?

[inblue]

The hashrate is half as before and at pollinfo3 it says that is down and returning to minningpolo.

Does need to upgrade the wallet to the latest version of 1.0.2.5? How i do the upgrade in windows?

On 1.0.2.5 something is different, this is what I see in that line:

Code:

"poolinfo3": "CFW 08-30-2017 20:39:16; Checking on Pool Health to see if back up...08-30-2017 20:40:21; ",

But CPU usage is still chaotic and not nearly fully utilized.

[Iuliu]

The hashrate is half as before and at pollinfo3 it says that is down and returning to minningpolo.

Does need to upgrade the wallet to the latest version of 1.0.2.5? How i do the upgrade in windows?

On 1.0.2.5 something is different, this is what I see in that line:

Code:

"poolinfo3": "CFW 08-30-2017 20:39:16; Checking on Pool Health to see if back up...08-30-2017 20:40:21; ",

But CPU usage is still chaotic and not nearly fully utilized.

If you increase the gneproclimit then the cpu usage increase to.. but than is no more minning because as i understood the pool has an 25 limit threads. But for example my 24 cpu's are used just as 50% .

[tiras]

The hashrate is half as before and at pollinfo3 it says that is down and returning to minningpolo.

Does need to upgrade the wallet to the latest version of 1.0.2.5? How i do the upgrade in windows?

On 1.0.2.5 something is different, this is what I see in that line:

Code:

"poolinfo3": "CFW 08-30-2017 20:39:16; Checking on Pool Health to see if back up...08-30-2017 20:40:21; ",

But CPU usage is still chaotic and not nearly fully utilized.

If you increase the gneproclimit then the cpu usage increase to.. but than is no more minning because as i understood the pool has an 25 limit threads. But for example my 24 cpu's are used just as 50% .

the DEV was warning that hashrate will drop with the updates as he implemented some changes in the algo.  hopefully this wouldn't cut down the output

[bible_pay]

Anyway, your clients will solo mine when you lose the pool connection, so its not really a problem.

The hashrate in the pool is also lower than expected. But maybe that's because they are jumping on and off.
The "poolmining" tag also sometimes switches to 'false'.

There is a problem with this and I'm talking about the main net. Mining constantly switches between pool and solo (true/false) and it definitely affects performance. Even in the short periods of time when "poolmining" says "true", there's always the "POOL DOWN-REVERTING TO SOLO MINING" error in the "poolinfo3". With the constant switching we are not mining the same as without switching (e.g. number of shares submitted), because I see that CPU usage is all over the place, at times even dropping to less than 10% instead of the constant 99%. The hash rate also plummets during the constant jumping from solo to pool and vice versa. This probably also affects solo mining because I'm not sure how effective is to solo mine for only a few seconds and then get interrupted again.

Also, when I stopped mining on one of the computers and then resumed, it could never go back to its previously established hash rate, but only around 60% of it, while other identical machines are still on the same hash rate, as though there's some kind of an age priority. If it's of any significance, on the restarted machine, "miningpulse" parameter is around 6000, while on the uninterrupted ones it's about 500K.

Isn't all this just a simple issue with the lack of CPU power on the server? I mean, it could be easily solved by employing a more powerful server and I bet that a few people here would be willing to donate for the costs, myself included. Or simply open source the pool and somebody will host it on a higher-end machine.

I agree there is a problem.  On the bright side, the code itself on the client side still looks solid and on the pool side, OK.

Im going for the low hanging fruit first.  The network rack is plugged into a 100mbps service, and the first thing that didnt smell very good is the entire bandwidth is utilized.  My voip phone is down, everything down.  

So I installed an anti-ddos firewall program on the web server and sure enough we are being ddossed.  I see about 50 IPs that keep sending some binary data about 60 times per second.

Otoh, the pool traffic is pretty clear, its XML back and forth.

So I just started adding rules and blocking the binary traffic.  
Also, there are quite a few servers out there that have not upgraded that are hogging some of the bandwidth, so I had to ban some of those IPs also.  Now we are down to about 17% utilization, try it again please.

Ill look at the 'health down' messages on my box now also.

[happy_merchant]

I agree there is a problem.  On the bright side, the code itself on the client side still looks solid and on the pool side, OK.

Im going for the low hanging fruit first.  The network rack is plugged into a 100mbps service, and the first thing that didnt smell very good is the entire bandwidth is utilized.  My voip phone is down, everything down.  

So I installed an anti-ddos firewall program on the web server and sure enough we are being ddossed.  I see about 50 IPs that keep sending some binary data about 60 times per second.

Otoh, the pool traffic is pretty clear, its XML back and forth.

So I just started adding rules and blocking the binary traffic.  
Also, there are quite a few servers out there that have not upgraded that are hogging some of the bandwidth, so I had to ban some of those IPs also.  Now we are down to about 17% utilization, try it again please.

Ill look at the 'health down' messages on my box now also.

Was afraid that might happen. Seems to happen a lot these days, DDoS the pools to knock miners off the network so you can find more blocks.

Does getting pool down errors still massively slow down miner performance? If miners smoothly revert to solo mining when the pool goes down with no significant drop in performance then the hit to the network hashrate would be low and there would be no motivation to DDoS (not that that'd necessarily stop them).

[616westwarmoth]

I'm not sure why DDoS would be effective either, except for the idea that if the pool gets knocked off right before the solution is found, then all the hashes for that block from the pool are wasted.  Granted, I would think that would require someone to be paying attention to the block chain pretty fiercely but that doesn't really make much sense.  The only other thing that makes a bit more sense is a campaign of a hacker who has an axe to grind with religion but really, if that were the case (not suggesting or condoning this) why wouldn't they hit some high profile target like Joel Osteen or The 700 Club.  So really, the only thing that makes much sense is a rival coin, which is sad to think about, or someone that doesn't realize no pool all that hash goes solo (and for the short term, that's a zero sum game, maybe long range the lack of a pool drives out other miners, but that's a bit hard to fathom).

We need more pool servers, I've offered as well to buy and run one if the price wasn't outlandish but I think the Dev wants to get a more finished product out there before that sort of thing happens.  The counter argument to that is if there were one or two or three other supporters (I won't name anyone at the risk of offending, but I'd wager there's five or six posters in this thread contributing half the posts), like myself, that were willing to buy or at least Co-Lo a pool server under the direction of the Dev with the understanding it would be remotely accessed and upgraded on the short term by him and after his pool software was "prime time", would then become the hosts duty, there would be enough takers.

[inblue]

Does getting pool down errors still massively slow down miner performance? If miners smoothly revert to solo mining when the pool goes down with no significant drop in performance then the hit to the network hashrate would be low and there would be no motivation to DDoS (not that that'd necessarily stop them).

Of course it affects solo mining performance, my machines go to full CPU usage and hash rate only when there is no pool parameter in the conf file. Otherwise, they are either about 60% hash rate, or just showing 100% but CPU is constantly going up and down and doesn't get a full utilization, not even for 10 seconds, while on solo it's very steady.

You can also observe that everyone's shares in the leaderboard have dropped significantly compared to the times when pool mining was steady. I suggested it was DoS 3 days ago but it was dismissed.

[seasonw]

Does getting pool down errors still massively slow down miner performance? If miners smoothly revert to solo mining when the pool goes down with no significant drop in performance then the hit to the network hashrate would be low and there would be no motivation to DDoS (not that that'd necessarily stop them).

Of course it affects solo mining performance, my machines go to full CPU usage and hash rate only when there is no pool parameter in the conf file. Otherwise, they are either about 60% hash rate, or just showing 100% but CPU is constantly going up and down and doesn't get a full utilization, not even for 10 seconds, while on solo it's very steady.

You can also observe that everyone's shares in the leaderboard have dropped significantly compared to the times when pool mining was steady. I suggested it was DoS 3 days ago but it was dismissed.

Wow, just read last few pages of this thread and realized that pool has been DDOSed. No wonder the connection to pool is unstable and hashrate was drifting up and down recently, and some of my mining machine had 0 hashrate sometimes...

[bible_pay]

Does getting pool down errors still massively slow down miner performance? If miners smoothly revert to solo mining when the pool goes down with no significant drop in performance then the hit to the network hashrate would be low and there would be no motivation to DDoS (not that that'd necessarily stop them).

Of course it affects solo mining performance, my machines go to full CPU usage and hash rate only when there is no pool parameter in the conf file. Otherwise, they are either about 60% hash rate, or just showing 100% but CPU is constantly going up and down and doesn't get a full utilization, not even for 10 seconds, while on solo it's very steady.

You can also observe that everyone's shares in the leaderboard have dropped significantly compared to the times when pool mining was steady. I suggested it was DoS 3 days ago but it was dismissed.

It wasn't dismissed.

EDIT:
To Happys point: the software IS designed to solo mine when the pool is down.  The important thing about the feature is: Its supposed to solo mine for a good chunk of time, ie 5 minutes, while it is determined that it is in solo mode.  That would give you a consistent hash rate when the pool is down.  If the feature is fluctuating, it is malfunctioning.  That means that a ticket needs to be put in on github describing the problem.

[tiras]

is it possible to use multiple machines to solo mine in a single wallet i.e. sort of combine hashpower ? 

Yes, just copy the encrypted wallet.dat file to each machine. That way I only had the wallet running in the taskbar on my home PC (not mining) and I got notifications when one of the remote machines found a block.

does it mean hashrate will be really combined or every PC will keep mining separately just sending results into the same address ?