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

Website access needs to be https://www.btcguild.com (note the WWW).  Still trying to find some way for the load balancer to forward an HTTPS request to the webserver without that error.

Is it me or is the pool a bit wonky recently (perhaps due to the server move). Screenshot attached:



Uploaded with ImageShack.us

Notice the massive number of share upload and job request errors.

I'd really like to know if this is due to my mining software or the pool.

Something happend? My miner shows 0 accepted shares, my account page also

Edit:
Ok, it's a miner problem. New cgminer with diakgcn kernel shows only hashrate but don't submit work

Chrome:
SSL connection error
Unable to make a secure connection to the server. This may be a problem with the server, or it may be requiring a client authentication certificate that you don't have.
Error 107 (net::ERR_SSL_PROTOCOL_ERROR): SSL protocol error.

when I connect to https://btcguild.com/my_account.php
my firefox reports:
ssl_error_rx_record_too_long

Thanks!  I've been planning it for quite a few weeks, but you never know how a big move like this will work out in the real world.  All miners are on the new servers as of right now.  BTC shares that were submitted to the old server during the move have already been added back to the new server, and NMC shares will be added back in the next few minutes.  Only valid shares submitted during the move are being copied over (since those are all that matter for payout).

Payouts will be re-enabled in the next half hour.  Hall of Fame, performance charts, and auto payouts will kick back in around that time.  Unfortunately, the timezone issues mean the performance charts got really screwed up during the move, so they will be starting fresh.

EDIT/UPDATE:  Our bitcoind was updated during the move, and we are now voting in favor of BIP16.

"Time travelling" shares have been fixed.  Some discrepancies between the database server, pool server(s), and web server were creating interesting problems.  Most users have already gotten the DNS update and are now mining with the new servers.

The old pool will begin redirecting miners via proxy shortly, at which point I will prepare to update the new server with any shares that were submitted to the old server during the move.

Please read the post directly above yours.

Umm, the first miner has negative time since last share, it's submitting shares, and they are not being counted, for 4.5+ hours???

The move has started.  Other than the "missing shares" I talked about in the post above, some quirks (like Last Share being negative/in the future) may pop up during the move.  Like I said above though, NOTHING is being "lost" during the move.

New servers are installed and currently being configured.  Server move will likely happen in the next few hours.

As stated previously, the move will be mostly transparent, and go through the following steps:

1) Payouts will be disabled during the move to avoid anybody getting a double payment.
2) A snapshot of everybody's share counts is made, and copied to the new server.
3) When your DNS updates, you will see a few rejected shares and a longpoll disconnect (possibly some other error depending on your software)
4) When your DNS updates, you will notice your stats/earnings have lost shares (due to the new server running off the snapshot in #2)

5) Once the majority of the pool load has shifted to the new servers, the old server will begin proxying connections to the new servers.
6) At this point, I will run a script to calculate how many shares you submitted to the old server after the snapshot in #2 was made.
7) The shares you submitted to the old server during the move will be added to the new server, bringing you up to date.



I will post an update when the move begins, or if it is delayed until tomorrow morning due to insufficient time to make sure everything runs smooth.

I think your server is having issues.

[08/02/2012 10:31:37] Result: efa69eec accepted
[08/02/2012 10:31:49] LP: New work pushed
[08/02/2012 10:31:56] Result: f3437428 accepted
[08/02/2012 10:32:12] Warning: work queue empty, miner is idle
[08/02/2012 10:32:22] Result: 07ffacf2 rejected
[08/02/2012 10:32:27] Result: 5f685753 rejected
[08/02/2012 10:32:52] Disconnected from server
[08/02/2012 10:32:57] Result: 8b84cb2f rejected
[08/02/2012 10:32:58] Connected to server

This same setup works fine on deepbit.

Running a single 5870 at  950/300 with 11.6 drivers and 2.5 SDK. Cgminer 2.2.1 is pointed at btcguild via port 8332 ( I used the tutorial on btcguild.com). I am successfully submitting shares, just not what I should be.

Not sure if it makes any difference but, I'm also mining LTC on the cpu through port 9332. I have two cpu threads for the LTC miner and then I commit all but one of the threads for cgminer.

Let me know if you need any other information.

I have no comment on the guiminer issue, its affecting all pools and there is nothing I can do about it.

Regarding your high reject rates:  I need more information about your setup.  I'm still getting less than 0.1% rejects with cgminer.  If you're getting 20-25%, something is very wrong on your end.

When are you planning the swap? I'm tracking my shares in cgminer for the last few hours and I've had a very high reject rate for the past hour.

Also, any comment on the guiminer (poclbm) issue?

Edit: As of 2/5/12 (my time) I'm getting about 20-25% rejected shares. I'm using cgminer 2.2.1 set will all default settings. Is there any particular intensity or worksize that is best accepted? I've run BTCguild for a while before I switched to another pool then came back and previously I never had higher than 5% rejects and stales and orphans combined.

I am going to be attempting a seamless transfer where the DNS updates, and people are mining on both servers for a while.  The new server will have a copy of the shares database prior to the move.  After 6 hours, I will turn the current server into a proxy and send all connections to the new server.  At that point, I will run a script to calculate how many shares people submitted to the old server during the time both were running, and update your stats on the new server to reflect that.

Ideally the process will be:

1) You're mining on Server A (old server).
2) I push the DNS update for Server B to take over.
3) You still mine on Server A until your DNS updates.
4) You move to Server B (lets say after 45 minutes).  You will see a few rejects since you still some work from Server A.
5) You start mining on Server B, your stats will be missing those 45 minutes spent on Server A.
6) ~6 hours after the DNS updates, your stats on Server B are updated for the 45 minutes of shares submitted to Server A.


If all goes well, all you will see is a hiccup and some rejects when your DNS updates, and a longpoll disconnect/reconnect.  You'll be missing some stats on the new server, but they are not lost, they just won't be merged until Server A is no longer serving work to miners.

New servers ship out today, meaning they should be online by next weekend (February 10-12).  After the move the pool will be generating blocks that support BIP16.

If the roll-out of full validation is postponed and eleuthria - or any of the other pool owners - doesn't postpone it on their pool too, there's a rather large chance that they'll get stuck mining their own fork of the network that no-one else will accept. Since BTC Guild is PPS, that means that it'll keep paying out bitcoins for  shares but won't earn any block rewards to pay for those shares, leaving eleuthria rather badly out of pocket.

Once we do have full validation of BIP 16 there will of course be a similar problem in the other direction for pools that don't upgrade to a version that does the new validation, but for various technical reasons that's much lower risk.

Huh?  Lose money?  What?

I don't think you understand how this works.

Hmmm. Well, it looks like the original switch-on date of the 15th is going to get postponed, quite possibly even repeatedly, so I presume you'll be able to restart bitcoind with the appropriate options as and when necessary? Bearing in mind of course that you will lose money if you fail to postpone BIP 16 validation and your node does full validation of BIP 16 transactions in blocks before it should.