i think i've found out why there are so many rejections on high amounts of threads, it's actually just stupid to send the work as share in the first place --- so the rejection is correct, but sending it to the server is unnecessary.
@GurungBoi:
i'm not limiting them, i just use a different share target, which reduces the shares/min
@wirel1:
i fixed a memory leak, i think this was causing some of the trouble we had last night.
net miner is still using normal priority & 512 mb per thread, if you want to change the priority, you'll have to do it manually.
@all:speaking of problems, here's what i found out about the payout system:
before going berserk: read the following, try to understand it, read it again (!), and if you have something
useful to say write it here (or PM me)
ok, so the server workload was really heavy the last hours, which broke the execution of the payout script, while the normal behavior would be
every X seconds do {
check last payout & the following block (confirmed? orphan? etc. pp)
calculate the payout & next value for all users
send payout info to protoshares backend & execute payout
save all information
}
due to the workload and connection problems last night the communication to the backend had some huge delays, which led to parallel executions of the payout script on the same block
long story short: payouts on some blocks had been executed multiple times
ok, that's bad. bad it's not very bad. why?
because the users that had the most advantage (high values in the payouts) kept mining at the pool, which means i can use the unconfirmed balance of these users to correct their balance.
so what's the problem?
slow miners in the broken payouts don't have enough mined yet (in the unconfirmed block), so they are able to run away with the bounty. let's see what the unconfirmed blocks will bring and i'll try to correct the remaining parts with the fees I've earned, because it was my mistake ... somehow
so why do you tell all this?
because honesty is important! i could have just said nothing (since no of the affected miners didn't noticed something strangely..........). but without honesty i could just go on and introduce "dynamic fees" or have a "hardware failure", or use "software" without ............... <-- ok, sorry, enough, nvm
ok, so give of some numbers?
yes, here we go:
the blocks that have been executed multiple times:
16547: 17x
16794: 3x
16805: 2x
16806: 2x
16859: 2x
16878: 2x
16891: 2x
16903: 18x
17035: 2x
17133: 10x
I've added the difference (negative balance) for the miners who had multiple payouts to the following payout:
http://ptsweb.beeeeer.org/payout/17136check the "diff" field
yes, some numbers there are quite high, but those miners are big miners with many mining machines, this means all unconfirmed blocks can pay for the negative balance and we'll not have a problem with these high values. it's the smaller values that are causing me some a headache.
i used all of my free time today to check/fix that sh--
although there's enough to do on the pool & miner side.
- xolokram
ps. the "leftover" value in the payouts is broken due to this bug, i'll fix that later manually
