Topic: [CLOSED] MaxBTC.com Pool - Closed Indefinitely Aug 3rd 2013 - page 6. (Read 27524 times)

Thanks for looking into that. At least now I have an explanation

Didn't mean to infer there was a discrepancy in submitted shares, just the rejected ones.

I checked a few of the shares at the beginning and end of the log file and they are all logged on our side.  The share.log has 4314 entries and the server also logged 4314 entries so I'm assuming it's all there.  However, 41 of the shares are logged on our side as stale and the remaining 4273 were accepted.  All the shares in the share.log file are shown as accepted.  Cross referencing with the merged mining (NMC) side, the shares were shown as accepted and not stale.  Since only one result can be sent back to the miner, an overall accepted response was returned instead of the stale BTC one.  If all merged mining results were stale, you'll get back a stale response instead of accepted.  This is why you're seeing more accepted shares on your side than what the server is showing.

The log isn't showing any discrepancies in # of submitted shares as suggested in your original post.  If you have a log that shows that sort of discrepancy, go ahead and send that and I'll take a look.

Sure, I'll get that going a bit later.

Can you turn on shares logging on CGminer for about an hour and send it to me?  An hour should be enough to show the discrepancy, correct?

Sorry, stales, not invalids!

I've got less than 50 invalids in ~7million shares.  30 of those were from one card in a 6hr period because it was failing (100+oC).

systems that used to use poclbm but use phoenix (with phatk2) now:

3425484 shares
14880 stales

0.4325123736906909%

systems that have always used phoenix:

3269499 shares
3344 stales

0.1021741647857841%

total:

6694983 shares
18224 stales

0.2714648900294598%

current round:

9950 shares
11 stales

0.1104306796506375%

High invalid rate aside... I'm still getting a very large discrepancy between CGminer and maxbtc reported invalid rate. It does seem that maxBTC it telling cgminer a share valid, then deciding it's not.

No proxies.
Just reset everything... See how it looks after a couple of hours.

The displayed info is usually cached for about a minute.  To get an accurate count, you'll need to stop mining for about 2 minutes and then refresh your stats.

However, the cached numbers shouldn't be off by as much as you're showing.  Your stale rate is also much higher than most users.  I believe the majority of them are seeing < 1% stales.  Are you going through any proxies?  Can you reset the stats on your miners and see if it still diverges?

Do you accept shares unconditionally? I'm getting quite a discrepancy between cgminer stats and your stats:

CGminer:
Gets:1116
Accepts: 7805 
Rejects:3
Discards: 155
Stale: 0

maxBTC:
Gets:1108
Accepts: 7066
Stale: 282

We've been at 0.6.2.2 since a few days after the announcement of 0.6.2, which we initially heard about thanks to you.

I like the direction the bitcoind code is going but it's hard to argue that Gavin hasn't fouled up in how he's been dealing with the recent releases, with many things being done in secret.  BIP16 was initially stalled after it was announced while network consensus was being done.  Then when Deepbit finally switched over to BIP16, he gives pools two weeks to switch over to an unstable beta known to have lockup problems.  A few hours before the BIP16 deadline, the "stable" 0.6.0 release is announced after 2-3 hours of the "it compiles and runs" release candidate testing.  0.6.2 comes out of nowhere and pools must update or else a DoS or fork may occur; have you seen the kind of changes 0.6.1 made?  That is a major change from a deployment POV and needs heavy testing to make sure that there are no deadlocks and that no corruption occurs.  How much stress testing did it really have?  I've already noticed one area in the code where the locking differs between 0.6.0 and 0.6.2, which may be due to bad code updating (it's very easy to mess up), but have not investigated it.  And I've barely looked at the 0.6.2 code.  Backports were mentioned but no info was given on where they could be found.  Were 0.6.1 or 0.6.2 really ready or were they rushed?  Given the changes to 0.6.1, it might have been better to have a 0.6.0.1 patch instead.  We were already (accidently) using a seemingly stable pre-0.6.1 build so the switch to 0.6.2 wasn't a big deal.  If pools/services were made aware of the risk with 0.6.1, I don't think many would have updated right away.


The mailing list would be helpful.  Even a sticky in all bitcoin subforums indicating the current version and its release notes would help.  New version or release candidate annoucements usually get drowned in the sea of threads.

the pool, i guess... my donation total is about 50% of what i've gotten from invalid blocks

though even if you threw out the invalids, the luck is about 2x what it should be

it's more blocks solved than eclipsemc over the last 4 days, w/ about 1/5th the hash rate

Nothing mining pool specific, though there was a security update recently everyone should do if they haven't yet. (0.6.2)

Two sides to that statement, pools need to stay aware of what's going on and recently the devs have actually started posting in the mining thread if there is pool specific stuff - ie BIP16.


I idle in the developers IRC chanel and subscribed to the dev mailing list ages ago, just to keep up - informing pools isn't anywhere I could find in developers job descriptions .
There is talk of making a "poolop mailing list" so the devs can pass pool specific info along in a timely manner. talk...so far

Headsup - most devs care about bitcoin/bitcoind and no have interest in "monolithic pools", big ones or small ones -I feel this has changed slightly over the last few months, mainly due to the devs need for consensus from miners to do the recent BIP changes.

Yeah, I'm not too sure what's going on but everything appears to be functioning correctly and in sync with the network.  The competing blocks have all been found within 20 seconds of each other and blockchain.info is seeing them (both ours and the competitors') within a minute after being found.  I'm not sure what the norm is but a quick browse of the orphans at blockchain.info shows a lot of orphans recently and seems to indicate that the smaller pool usually loses out against a bigger one.

Bitcoind was restarted to clear out a potentially slow selection of connected nodes and the number of connections were increased.  Hopefully Gavin's not doing another one of the required updates to bitcoind and not informing smaller pools.

Lots of invalid blocks lately.  It's starting to hurt.

dns updated for me in 3 or 4 hrs (err, well, 3 or 4 hours after I woke up... so maybe 12 or so max).   i wouldnt have noticed it except for the website, miners point to 50.57.5.119

I noticed!  thanks for doing those reports, btw.  pretty awesome.


ok, lemme pm you for more info.

Trying to payout a little over 7.2BTC and I'm still getting the error.

Well, looks like your luck has turned - Maxbtc had the highest luck and lowest average shares per round for the last week for any of the 17 pools I monitor:

https://bitcointalksearch.org/topic/weekly-pool-and-network-statistics-77000

how much are you trying to queue?  bitcoin or namecoin?