Topic: [ATTN: POOL OPERATORS] PoolServerJ - scalable java mining pool backend - page 3. (Read 31109 times)

No I am not running it right now but just about to set a server with it installed.  Msg shadders with your properties file and see if he can see anything wrong.

I hope it's just a settings issue cuz I'm going to turn off push to upstream.

@DavinciJ15: Are you running 0.09 right now? I run into a 1 million share nmc round and just wondering if you already succeeded in finding a block with this version?

Thanks for help, bro!

I second that. On http://yourbtc.net I have 70 stales out of 150,000 shares or .04%. Incredible.

What ever you did it looks good so far I only see the correct partial-stale,  no stales no unknown-work.  I will let it run until there is a double LP.

use the link in the above post

+1

http://poolserverj.org/dist/mm-mini-binary.09.debug.tar.gz

im getting a 404 error http://poolserverj.org/dist/mm-mini-binary.09.tar.gz

If anyone has some spare time to play it would be really helpful if someone could download this version and run it for a while then send me the log:
http://poolserverj.org/dist/mm-mini-binary.09.debug.tar.gz

It looks like stales have been dramatically reduced but for some reason cgminer is sending back a few works that are registering as unknown.  The above version is identical to .08 but has a bit of extra logging in it that should help track down the source of the problem.

edit: updated post to point to .09 which has a minor fix for issue where in some cases partial-stales were treated as full shares.

If anyone's downloaded .08 and found an odd looking file in there:  bitcoin-poolserverj-0.0.2-SNAPSHOT.jar

That's actually poolserverj.jar which I forgot to rename.  It should be in the bin directory and *no where else*.  I've uploaded a new version with the correct name. 

That was my original suggestion you shot down as too complex! Jack bean stalk!   

what i did not know is you could do this in SQL...

instead of this...


So I was on the SQL ignorance planet!  My problem is I don't think of SQL as a computer language, I think of it as a bad hack for accessing data and thus forget how robust it is.

OH well.  Learn something new everyday.

Anyhow...
I say having more than 32 block chains is crazy so unsigned INT is the way to go.

Thus my vote is for a bit wise column!

Davinci

I have to agree.  Writing shares to DB is already one the biggest bottlenecks in psj.   Doubling or tripling the number of rows written is definately not ideal, likewise with using a seperate table with a many-to-one relationship.

I'm wondering if perhaps a floating point share value column should be added.  There would need to be an interface so the pool could dynamically update the value of each chain.  The value field is then the sum of the solved chain's values.  The disadvantage of this is that values are changed frequently then it's retrospectively difficult to go back and try to work which chains each share solved for.

The remaining options are a single consolidated column like bitfield flags or a boolean column per chain.  I'm not sure what factorial planet davinci was on but the way you normally do it is allocate each bit to a flag.  so 1 = bitcoin, 2=namecoin, 4=scamcoin.  Then each is easy to extract with a simple logical &.

If you don't want to record which chains are solved you have a simple choice between accept or reject partials.  Accepting them provides the miner no incentive to fix any latency problems and hurts the network overall, not mention costing PPS operators a pretty penny.  Reject is going to fill yr inboxes with complaints (which I personally think you should be redirecting to the namecoin forum).

I already added a third merged chain "stifflersmomchain" to the scenario.

We only need this table, you can query the db and set where statement to the desired chain on the column "chain".
Plus we already set the name of the merged chain into the psj property file (source.local.1.merged.chains=namecoin).

It's even possible to set an int instead of a string for the chain column, in case we wanna use the id (source.local.1.merged.namecoin.chainid=1).

Doubling up the shares may be simple to search but a problem if you start adding more than one other block chain.  May I suggest a new column, repurposing of a current column, or a master/detail table (shares/chain) are the best options.

I like large growth potential so that it does not need to be redone when it's time to grow.

What do you think of adding a new table for all additional mm chains like this:



Keep the shares table clean and main chain (btc) only. That counts for all columns.

Add a new table for all merged chains and only enter a new row under 2 conditions:
- merged chain got our_result = 0
- merged chain got upstream_result = 1

In case a share is valid for all chains, don't even add a row to the shares_merged table.

Let me know what you think about that?

if you mean a single share from yr own pool... btc diff / nmc diff ~= number of nmc only shares per btc+nmc share

If you mean across the whole network that's a bit more complicated since you've got to account for non-merged miners.

how often does a single share solve a nmc and btc block?

your suggestion 1 is how the current implementation works.  A normal accept share will have our_result=true, reason=null.  A partial-share will have our_result=true, reason=partial-stale

re: 2.... Perhaps a bit mask would be an option.  Though this is limited and any combo value field tends to make efficient db queries difficult to achieve.

My suggestions to you had two parts be ether way the a partial share should tell the miner that it was accepted (IMO).

1) Insert into the reason column "partial-share" or "partial-stale", this allows the pool op to allow or deny the share as valid share an option in PSJ acceptPartialShares=true and reasonForPartial="" should be in the properties file.

2) Add an optional column called ChainMask where the bit marked block chain is placed into the column.  For example if you have 3 chains the value of Parent is 1, second is 2 and third is 4, if the share is valid for chain id 1 and 2 the value in the mask column is 3, if the share is valid for 1 and 4 the value in the mask column is 5 and all of them would be 7. 

The only issue with 2 is as you add chains the combo's are a factorial of the chains.

That's my 2 BTC cents.

I would like to see other ideas.


Davinci

Ive just been looking through the cgminer source code and it looks to me like it does use prev_block_hash as an indicator of whether the block has changed.  I'm happy to stand corrected but if that's the case it's a fairly serious problem.  It means whenever an aux chain finds a new block but the parent chain doesn't that cgminer will ignore the new work (even if it gets it via longpoll).  I don't know how many other miners do this but pool ops should start looking into this.

With 'partial-stale' shares being accepted it effectively means the miner will get credited for both chains while only working on one.  Unless shares are actually assigned a 'credit value per chain' the choice is between crediting these partial shares or disallowing them unless the share is valid for all chains.  The 'credit value per chain' option will require and extra database column which will break pushpool compatibility completely (it had to happen sometime) and require all pool ops to make some mods in how they are calculating worker shares.

Need feedback from pool ops on how to deal with this.  This is a particularly significant issue for PPS pools where you'd end up paying out a full share where only part of the work is valid.