Topic: BiblePay - TestNet Thread - Pool Testing for Proof of Bible Hash Pool (PoBh) - page 14. (Read 13217 times)

just start it with pool config

What must be changed to mine prod pool instead of testnet pool? Also which version of the wallet is required?

OMG ,  it's happenning...     pool website slowed down   a bit .

 when real distribution will start ?

Thanks, very good idea.  Yes, on the 3rd config, I believe the pool is stomping on itself, because one thing it does is keeps track of threadids that hit it and request work.  If the same minerguid (workerid) hits the server with the same threadid and asks for new work, it deletes the old work record.  Therefore shortchanging the potential earnings on that share for the miner.  So I think in this case we will have to tell the users to have at least one workerid per machine.

-=-=-=-=-=-=-=-=-=-=

Guys (and Girls), I just deployed the Prod pool and enabled it for prod testing.
The settings are all the same as testnet, so you should now be able to reboot and start testing against prod.
The payment system is turned on (knock on wood) against the prod server for BBP also.
I see a few miners are already hitting it- if you would, please restart your nodes, as Id like to clear out any old mining threads.

Did some testing on a few different worker configurations:

-2 machines, 2 worker IDs, 1 account: 20231.04 HPS average
-2 machines, 2 worker IDs, 2 accounts: 18982.15 HPS average (both accounts combined)
-2 machines, 1 worker ID, 1 account: 11139.25 HPS average

Was only about 20 blocks each. The first two configurations are essentially equal as expected and agree pretty well with the hashps reported from getmininginfo.

The third configuration is reporting low. If I had to guess, it's randomly reporting the HPS of one machine or the other, rather than combining them. I don't know how common the case of someone running all their rigs under a single worker ID would be, but I figure I'd check it out just in case.

Looking pretty solid. I haven't been able to break anything from my end since the update.

I was thinking in a couple hours, we can switch a few of our miners (but not all) over to the prod chain, and verify the current wallet can hash against prod through the pool.

I have to take care of a couple IT issues now, but I will be back to start enabling Prod for testing in about an hour.

Okay, thanks! I'll check later if the balance will come available

I don't quite understand what you mean with 'testing against prod', buy if you'll tell me what to do, I'll be glad to help you.

hi Dev...when pool go live? ...impossible solo mining...

Good morning!

It looks like your first mining_credit was on 08-14 @ 09:40 AM, that is approx 3 hours from now in the future, so the balance should start becoming mature in about 3 hours, at that point, the appropriate portion of the balance should start becoming available.


=-=-=-=-=-=-=-

So I dont see any pool issues from last night, payments look pretty good.  Maybe we can do some final testing and then towards the end of the day if nothing comes up, we can point our miners to Test against prod to ensure the isolation between nets is working properly, but we probably wont find a block while testing, but it should still be a worthwhile exercise.

Too bad the xeon was DOA Hope your current sever is also fit for the job.

I have a question about the withdrawal form. All the balance is still immature. Is this normal behaviour? I guessed the payout would mature 12 hours after being awarded (and thus a part of the balance should be available to withdrawal at this time), but that doesn't seem to be the case. I've never poolmined before, so I have no idea if this is normal.

Yeah I hate to stress test it in prod but hopefully we will find any remaining bugs.  From a server perspective I think it might be OK but we'll see.  My xeon quad cpu came in and I planned on making that the pool server but it came in DOA, so Ill probably just use the same pool server you hit now as that will take a few weeks to get a new one in.

Ah, I was tracking the HPS and noticed that it started looking correct for multiple workers all of a sudden.

The pool is starting to look pretty good. Hopefully we can get some more people to jump on testnet once it's close to release to stress test it a bit.

Oh ok 10-4 guys, well scratch (most) of what I said earlier, there was a bug in the value carried over into the block_distribution when you have more than one miner on the account!  So now it makes much more sense.

I deleted the last 3 blocks and let them re-pay and now they look pretty sane.

May we Charge forward now!

I've haven't really been tinkering around or anything. Mostly been mining constanty with around 20 khashps. But i tried a few things. I tried mining with one thread. And I also stopped mining for a few blocks (around 1114-1118) and then started again. Before stopping, I think the distribution was as expected, and after starting again, it seems the pool has to 'rebalance' for a few blocks it seems (I have never mined in a pool before, so I have no idea if what I'm saying makes any sense). But I'll see in the next couple of blocks what will happen...

EDIT: at approx block 1110 went from mining with 4 threads to mining with one thread. 30 minutes later I switched back to 4 threads. And 20 minutes later i stopped mining.

If you'd like a log or anything, just tell me how to make one and I'll post it here

Addressing the 2nd point, why a dual miner on one acct is paying less total % perblock than JaapGs single miner:
Its actually not really the two miners themselves summed, its the hashpersec2 root assessment.  I do see what would appears to be a problem on block distribution block # 1114.  In parentheses (thats the hashpersec2 assessment) I clocked in at 40.7k total for both while jaapg clocked in at 19.3k (the payment distribution is obviously OK), but honing in the issue is why did he get half while I was doing 80kh on the pc side (the original hashpersec) with him only doing 18k on hashpersec (thats 4* the hashes in reality)?  The answer lies in the hashpersec2 calculation.  It has a decay factor built in to prevent pool hopping and assigns more weight to more recent solved shares.  I cant find a way to eliminate it and I would assume it would even out over time- but then we have to see.

Looking at 1119 I came back with about 3* the payment but its still a little low, relative to Jaap, then on 1121, it looks like it went south again.  Im wondering how can Jaap always achieve such short term solutions? It could be his machine is solving easier hashes. (Ill take a look at the tables on his miner).

We can either wait and see if it averages out, or go deeper into it.
It might be an issue.

Thanks on point #1, great.
Yeah, I think on the networkhashps, I convinced myself that it needed changed, and in actuality, it appears it should be  changed again, now I think it should have been done this way:

getnetworkhashps 1114 1121 (startblock endblock) with approximately 8 block skips (thats supposedly a little over an hour)

That yields:
169.455075673734 while the pool is currently at 135khps, that seems more sane.

Going back through the chain, for instance with 500 510, it decreases what appears to be appropriately, then around the time of genesis to 100, its really low.  I think that is the problem.  Let me update the code, and I will get back on the rest of the testing issue, thanks for bringing this to the forefront.  Once we release it, this should be relatively easy to check in prod against the bx, I think.

It seems to be very reliable now for mining on a single worker now. Even swapping on and off different workers seems to behave as expected.

I'm pretty sure there's something weird going on with multiple workers on one account, though. Your bible_pay account is only earning about twice as much as jaapgvk despite putting out over 4 times his hash rate. I could understand if it was occasional and he just got a lot of shares that round, but it seems to be every block.

Running some tests now to quantify it a bit better. Running two rigs as two workers under one account right now, going to give it another 10 or 20 blocks then change it so the same rigs are mining on separate accounts, then compare the rewards.

Also, I think the network_khashps is reporting much too low just by comparing it to the pool hash rate. I'm guessing you implemented some of the changes you mentioned the other day?

Ok, 1.0.2.0 is out there now.

Good luck.

Your right, I see the problem.  So when our major version flipped from 1.0.1.4-1.0.1.9, we had no problem.
At 1.0.2.0, there is a problem.

Hang on.

Hi,

I've been mining this coin for a few days (first time I've ever mined a coin). I really like this project and would like to help you by also mining on the testnet. But the version on the site still seems to be 1.0.1.9? I tried both the 32-bit and 64-bit version.