Author

Topic: [CLOSED] BTC Guild - Pays TxFees+NMC, Stratum, VarDiff, Private Servers - page 403. (Read 903150 times)

legendary
Activity: 3080
Merit: 1080
Yes, mine1.btcguild.com is down, and it looks like the bug is in PoolServerJ, possibly related to the February 20th protocol change [even though it was only supposed to affect old versions of bitcoind].  Working on tracing the problem back immediately.  Until I can figure out what is wrong, mine2 and mine3.btcguild.com are both still running normally!

Yep, you are correct. I immediately switched over to mine2. I'm staying away from mine3 for a reason I'm sure you can think of :p.
legendary
Activity: 1750
Merit: 1007
Yes, mine1.btcguild.com is down, and it looks like the bug is in PoolServerJ, possibly related to the February 20th protocol change [even though it was only supposed to affect old versions of bitcoind].  Working on tracing the problem back immediately.  Until I can figure out what is wrong, mine2 and mine3.btcguild.com are both still running normally!
legendary
Activity: 3080
Merit: 1080
Pool is down!!! mine1.btcguild.com to be specific.
legendary
Activity: 3583
Merit: 1094
Think for yourself
Unless I see a significant number of requests, there will not be a 'no vote' option.

I have yet to hear a valid argument for the need to implement this.  I'm not saying I'm for or against the modifying the block chain.  I'm just saying nobody is putting up a good reason to do it in the first place.

So I guess I would vote for a server which has a no vote capability.  Is that convoluted or what Smiley

Sam
legendary
Activity: 1750
Merit: 1007
A change will be made to mine3.btcguild.com later today.  The node will be switched to a dual support for BIP16 & BIP17, but the coinbase flag will be voting in favor of BIP 17 instead of 16.  This is to allow users to have the opportunity to pick what they vote for (BIP16 on mine1 [default] and mine2, BIP17 on mine3).  Unless I see a significant number of requests, there will not be a 'no vote' option. 

Due to how many miners out there go with the defaults, the default server (mine1/btcguild.com) will remain as a BIP16 voting node.  I do not want to add another 10% of the network as non-voters, which would make BIP16 impossible to pass when added to Deepbit's portion of the network.
legendary
Activity: 1750
Merit: 1007
mine2 and mine3 will be getting a very brief reboot in the next 30 minutes.  Estimated downtime is about 60 seconds (they will go down at separate times).
legendary
Activity: 1750
Merit: 1007
Thanks for that explanation.

Btw, the issues I've been having earlier have sort of "died down" - maybe ceased altogether. But before it stabilized something happened that caused the miner to report efficiency as negative and the  average hashrate also as negative.

Definitely need to point the blame at the miner software for that one, considering they're both impossible Smiley.
legendary
Activity: 3080
Merit: 1080
Thanks for that explanation.

Btw, the issues I've been having earlier have sort of "died down" - maybe ceased altogether. But before it stabilized something happened that caused the miner to report efficiency as negative and the  average hashrate also as negative.
legendary
Activity: 1750
Merit: 1007
whoa..my miner reported 10 new blocks (long poll) in a period of about 10 seconds. If that's accurate, then the pool got crazy lucky!! Smiley

LPs mean a new block on either network (NMC or BTC), even if it wasn't the pool.  Occasionally, the pool might get an NMC block notice before the BTC block by a few seconds if another merged mining pool found one but due to the way the p2pnetwork works, we may have received one block 2-3 seconds before the other.  In those cases, the pool might send two LPs because the two blocks weren't announced close together.

I've also found that cgminer has a weird bug where it will occasionally print out a spree of LPs, even though the pool only sent 1.  It seems to only affect PoolServerJ pools, but it may affect others as well.
legendary
Activity: 3080
Merit: 1080
whoa..my miner reported 10 new blocks (long poll) in a period of about 10 seconds. If that's accurate, then the pool got crazy lucky!! Smiley

LPs aren't only used for new blocks, and even if, most of those were probably namecoins...

Damn, I totally forgot about namecoins..after all btcguild IS a merged mining pool. Silly me.

full member
Activity: 373
Merit: 100
whoa..my miner reported 10 new blocks (long poll) in a period of about 10 seconds. If that's accurate, then the pool got crazy lucky!! Smiley

LPs aren't only used for new blocks, and even if, most of those were probably namecoins...
legendary
Activity: 3080
Merit: 1080
whoa..my miner reported 10 new blocks (long poll) in a period of about 10 seconds. If that's accurate, then the pool got crazy lucky!! Smiley
full member
Activity: 944
Merit: 101
PredX - AI-Powered Prediction Market
Not sure if it's relevant at all but here's mine over the past couple days since I haven't reset the stats:

Accepted (%)    Stale/Dupe/Other
35906 (99.69%)   69 / 13 / 30

Noticed the other and was curious what it meant too but I saw your explanation a few posts above.
legendary
Activity: 3080
Merit: 1080
To be honest I'm not sure. It could very well be how you describe it. I am using a alpha miner (MPBM 0.0.4) so perhaps I ran into a bug or two. But what I'm not too happy about (besides the connection issues) is the high percentage of stale shares (1.4% when it used to be below 0.8%). I guess I'll have to wait a while for the pool to stabilize.

Your stale percentage is the most confusing to me.  My 5870 is showing 16407 (99.93%), 12 stales.  That's mining mostly with mine2.btcguild.com (currently on mine1 (aka: btcguild.com) since the outage earlier to keep an eye on it).

In the last hour on mine1.btcguild.com my stats have shown 0 errors.  I've had "Pool 0 not providing work fast enough" twice, but these were posted _just after_ longpolls (the same second on the timestamp), so at no point was the miner actually idle.  I've made a handful of network configuration changes, hopefully they'll prevent the issue from happening again.

Maybe cause I'm FPGA mining? I'll keep an eye on it overnight, hopefully your network changes squashed this problem.
legendary
Activity: 1750
Merit: 1007
To be honest I'm not sure. It could very well be how you describe it. I am using a alpha miner (MPBM 0.0.4) so perhaps I ran into a bug or two. But what I'm not too happy about (besides the connection issues) is the high percentage of stale shares (1.4% when it used to be below 0.8%). I guess I'll have to wait a while for the pool to stabilize.

Your stale percentage is the most confusing to me.  My 5870 is showing 16407 (99.93%), 12 stales.  That's mining mostly with mine2.btcguild.com (currently on mine1 (aka: btcguild.com) since the outage earlier to keep an eye on it).

In the last hour on mine1.btcguild.com my stats have shown 0 errors.  I've had "Pool 0 not providing work fast enough" twice, but these were posted _just after_ longpolls (the same second on the timestamp), so at no point was the miner actually idle.  I've made a handful of network configuration changes, hopefully they'll prevent the issue from happening again.
legendary
Activity: 3080
Merit: 1080
ok I spoke too soon..errors are back. Oddly enough it rejected two of my shares with "unknown reason"...

U sure you're not being DDoS'ed?

Unknown reason is a VERY rare type of rejection.  It means you submitted work the server has no record of sending you.  The only time it should ever happen is if the pool is restarted (which didn't happen), or if for some reason your miner tried to submit a share from a backup pool to the primary pool.

To be honest I'm not sure. It could very well be how you describe it. I am using a alpha miner (MPBM 0.0.4) so perhaps I ran into a bug or two. But what I'm not too happy about (besides the connection issues) is the high percentage of stale shares (1.4% when it used to be below 0.8%). I guess I'll have to wait a while for the pool to stabilize.
legendary
Activity: 1750
Merit: 1007
ok I spoke too soon..errors are back. Oddly enough it rejected two of my shares with "unknown reason"...

U sure you're not being DDoS'ed?

Unknown reason is a VERY rare type of rejection.  It means you submitted work the server has no record of sending you.  The only time it should ever happen is if the pool is restarted (which didn't happen), or if for some reason your miner tried to submit a share from a backup pool to the primary pool.
legendary
Activity: 3080
Merit: 1080
ok I spoke too soon..errors are back. Oddly enough it rejected two of my shares with "unknown reason"...

U sure you're not being DDoS'ed?
legendary
Activity: 3080
Merit: 1080
Looking into the issues that popped up.  It recovered on its own, which is always a bit of a mystery.  Would really like it if something actually broke so I could find an error somewhere and then trace back the issue more clearly.

 Undecided yeah dunno what could be going on, but I'm back on mine3 (was on deepbit temp) and everything is back to normal.
legendary
Activity: 1750
Merit: 1007
Looking into the issues that popped up.  It recovered on its own, which is always a bit of a mystery.  Would really like it if something actually broke so I could find an error somewhere and then trace back the issue more clearly.
Jump to: