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

Looking for input from current or potential miners on BTC Guild regarding a redesign of the website.  While I've grown very fond of the interface (very compact, lots of information with reasonable distribution/sorting to make it easy to find), it certainly looks a bit dated .  I have some templates lying around for my now defunct VPS hosting service, which could be adapted to a more modern and fluid interface.

Of course, this would be a pretty big change in appearance, and one of the downsides to a more fluid interface is that it becomes harder to condense a lot of information as opposed to the current minimalistic approach.

I'm going to play around with it this next week while I continue monitoring the pool, and throw up a dummy site over the weekend before opening a poll to see if miners would like to see time spent on it.  For those that were around for GPUMAX, the template is not the same, but shares many similar styles.

Lol, I was about to say I noticed something like this yesterday, but then I saw you posted on 20..

I started around Diff=80000.  ASICMINER's currently deployed units alone are roughly 4 times larger than the entire network was back then .  I remember my farm of 5870s being 5 GH/s, which was a HUGE farm for the time.  I was the #1 hasher on BTC Guild for a while, and it took months to knock me out of the top 25 .

One of the stratum servers had a small issue sometime during the night.  It looks like most users were not heavily affected thanks to round robin DNS pointing them to a different server after a few failures.  The problem has been fixed and everything is working smoothly again.

Your pool hash rate is at or near what the network hash rate was when I started mining.  That's got to be some kind of milestone.
Sam

Heh Im using git 4 dec and there is a commit about  TCP_KEEPALIVE 5 dec... I will try this, sorry should have checked first, done a couple  since the beginning. 

My common response to what appear to be a very local problem (no widespread reports) is the following:

1) If using slush's proxy, consider updating it if you have not done so recently.
2) If using cgminer/bfgminer, consider updating it if you have not done so recently.
3) Try switching from one server to another (stratum.btcguild.com -> de.btcguild.com or vice versa).

So far at least one of those 3 steps tends to solve it for everybody .

Yes, has been so for a long time, but dont seem to affect the shares, benchmarked it against my fpgas  just wanted to look at it more in detail now with the RR dns. More log:

2013-02-21 01:05:40,078 INFO stats stats.print_stats # 1 peers connected, state changed 1 times
2013-02-21 01:05:40,078 INFO proxy mining_proxy.on_connect # Connected to Stratum pool at stratum.btcguild.com:3333
2013-02-21 01:05:40,078 INFO proxy mining_proxy.on_connect # Subscribing for mining jobs
2013-02-21 01:05:40,213 INFO proxy client_service.handle_event # Setting new difficulty: 1
2013-02-21 01:05:40,213 INFO proxy client_service.handle_event # New job 7139 for prevhash f68c7fc9, clean_jobs=False
2013-02-21 01:07:40,216 ERROR proxy client_service.on_timeout # Connection to upstream pool timed out
2013-02-21 01:07:40,217 INFO proxy mining_proxy.on_disconnect # Disconnected from Stratum pool at stratum.btcguild.com:3333
2013-02-21 01:07:40,217 INFO stats stats.print_stats # 0 peers connected, state changed 1 times
2013-02-21 01:07:43,028 INFO stats stats.print_stats # 1 peers connected, state changed 1 times
2013-02-21 01:07:43,028 INFO proxy mining_proxy.on_connect # Connected to Stratum pool at stratum.btcguild.com:3333
2013-02-21 01:07:43,029 INFO proxy mining_proxy.on_connect # Subscribing for mining jobs
2013-02-21 01:07:43,162 INFO proxy client_service.handle_event # Setting new difficulty: 1
2013-02-21 01:07:43,163 INFO proxy client_service.handle_event # New job 4304 for prevhash f68c7fc9, clean_jobs=False
2013-02-21 01:09:43,164 ERROR proxy client_service.on_timeout # Connection to upstream pool timed out
2013-02-21 01:09:43,165 INFO proxy mining_proxy.on_disconnect # Disconnected from Stratum pool at stratum.btcguild.com:3333
2013-02-21 01:09:43,165 INFO stats stats.print_stats # 0 peers connected, state changed 1 times

Regarding the fpgaproxy, now got very low stales again. The log file from the proxy look as it should, before during the dupe creeps it stacked the submissions, now its much more flow. Maybe a different server now or it was just the network problems Slush mentioned. In fact seems like the best explanation, thanks slush. I dont worry about it for now, if I see it again I will look closer. But normally I reset the proxies once a month, they are really working well. Thanks again! slush 

And also big thanks to you eleuthria, things are really working well, knowing that you are on-top of things and make thing better in steps has made me mining here for a long time now.

Not sure if anybody noticed, but OVH (quite a big european provider) has network issues today, which affected half of the european internet, because OVH's internal traffic is re-routed over other companies.

Higher difficulty should not impact stale rates in the long term.  Since a higher difficulty means more time between submissions, you're less likely to submit a stale.  However, when you DO submit a stale, it counts as more stales.  

IE:  At diff 1, you might submit average 1 stale per 5 longpolls.  So after 160 longpolls you have ~32 stales.  At diff 32, you are 1/32 as likely to submit a stale, but you will still average ~1 per 160 longpolls, which counts as 32.

For the dupes, I've found that many FPGAs submit dupes quite often, but it's not that they've done the same work twice, they've simply submitted the result twice, so your effective hash rate is not changed as a result.  My ztex singles have very high (~8%) dupe submissions when using btcminer, cgminer, or most versions of bfgminer (one version doesn't have the problem), but their effective speed is exactly what it should be on the pool website [within the expected variance for an hour long average].


As for the time out problem, is this a frequent problem?  I've not had any issues with my miners, and have not seen any pool wide problems.

I run two stratum proxies (slush) , the two mentioned above.  One consolidates gpus from cgminer and the other as a frontend for btcminer.
Everything works fine and the stales is normally very low.  They seem to work a little different tough, with cgminer (I guess) the proxy forwards vardifff so it ends at 32, wich causes one new connection per two min.
2013-02-20 23:40:30,192 ERROR proxy client_service.on_timeout # Connection to upstream pool timed out

Now with RR dns this gives different servers. Shouldnt be a problem, but what is the timeout limit for the stratum connection ?

For btcminer it seems as the vardiff wasnt forwared in the same way.  But with the new implemented minimum diff I could force it to 32 (before 8.) and  got less stales from that, but now it seems as the dupes are creeping slowly up. I will reset it again and check further.

I've been asked a few times by email (ever since ASICMINER and other users came) about plans for PPLNS shifts, now that they've gone from ~1 hour to ~30 minutes each.  The time it takes for a PPLNS shift to complete is not very important.  The N value is currently 30 million, which is ~8 times higher than the current difficulty, meaning an average shift will receive ~8 blocks worth of payments.  The very high value for 'N' was to reduce per-shift variance.  Higher 'N' values have virtually no effect on 24 hour/7 day/30 day variance, but many users would hate to see a share receive no payment at all, so a high 'N' value makes the odds of a shift receiving 0 payments very low.

However, there will be an increase to the 'N' value as difficulty rises.  I'm currently anticipating increasing N from 30 million to 60 million in March, based on current network speed projections.  I will update again before the change is implemented.  Again, this would have very little affect on overall earnings, aside from smoothing out individual shift variance, and hopefully reducing the odds of a shift receiving 0 blocks.

Sorry I didn't mention DE.  If you are connected through de.btcguild.com:8332 or de.btcguild.com:3333, you do not need to make any changes.  These only affect the US servers.

I use "de.btcguild.com:8332" do i have to change to "stratum.btcguild.com:3333" also???

Switched mine over to stratum.btcguild.com now so two less.

I am continuing to work on shifting servers around in the background, and adding new IPs to the round robin DNS entries for Stratum.  Users should not be affected by any of these changes (no old servers are turning off yet).  This process is almost complete, which should eliminate the ability for a DDoS to take down all servers for extended lengths of time.  The servers are being relocated to different providers all over the country, some of which have policies which should prevent one of the more common DDoS attack vectors (many-many gbps UDP floods).

No amount of protection can eliminate the DDoS threat (at least without spending every dime the pool makes and possibly more), but by spreading the servers out, the hope is that future attacks can not take out all servers simultaneously, and that I will be able to modify the DNS entries to help mitigate attacks as they happen.


One note to Stratum users:  If you are currently mining on 50.31.149.57 (this used to be the redirect URL if you connected to btcguild.com:8332), please change your miner over to stratum.btcguild.com:3333 .  The 50.31.149.57 server will be turned off once the active connection count drops under 50, or by February 28th, whichever happens first.

Not sure about that side of interface, I was using slush proxy since it is handy, but I think it was behaving somehow like that, multiple disconnections/re-connections. Again, maybe it is a coincidence, but I thought is worth to ask.. I have proxy logs saved for just in case.

Glad it's working so great for you!  Of course one rejected would increase your reject rate infinity% compared to the current value .  But most miners (good FPGA drivers/not running insane intensity) the target acceptance rate is 99.90%+.  The newer Stratum servers have helped as well, with a faster production of work after a new block is detected (higher ghz processors in the new servers).

This is why I mine at BTCGuild:

Summary of runtime statistics:
                    
 [2013-02-19 18:23:13] Started at [2013-02-18 22:13:11]                    
 [2013-02-19 18:23:13] Pool: http://stratum.btcguild.com:3333                    
 [2013-02-19 18:23:13] Runtime: 20 hrs : 10 mins : 1 secs                    
 [2013-02-19 18:23:13] Average hashrate: 350.8 Megahash/s                    
 [2013-02-19 18:23:13] Solved blocks: 0                    
 [2013-02-19 18:23:13] Best share difficulty: 3.55K                    
 [2013-02-19 18:23:13] Queued work requests: 2642                    
 [2013-02-19 18:23:13] Share submissions: 5983                    
 [2013-02-19 18:23:13] Accepted shares: 5983                    
 [2013-02-19 18:23:13] Rejected shares: 0                    
 [2013-02-19 18:23:13] Accepted difficulty shares: 5983                    
 [2013-02-19 18:23:13] Rejected difficulty shares: 0                    
 [2013-02-19 18:23:13] Reject ratio: 0.0%                    
 [2013-02-19 18:23:13] Hardware errors: 0                    
 [2013-02-19 18:23:13] Efficiency (accepted / queued): 226%                    
 [2013-02-19 18:23:13] Utility (accepted shares / min): 4.94/min                    
 [2013-02-19 18:23:13] Work Utility (diff1 shares solved / min): 4.94/min
                    
 [2013-02-19 18:23:13] Discarded work due to new blocks: 5062                    
 [2013-02-19 18:23:13] Stale submissions discarded due to new blocks: 0                    
 [2013-02-19 18:23:13] Unable to get work from server occasions: 0                    
 [2013-02-19 18:23:13] Work items generated locally: 14930                    
 [2013-02-19 18:23:13] Submitting work remotely delay occasions: 0                    
 [2013-02-19 18:23:13] New blocks detected on network: 131
                    
 [2013-02-19 18:23:13] Summary of per device statistics:
                    
 [2013-02-19 18:23:13] GPU0                | (5s):0.000 (avg):350.8Mh/s | A:5983 R:0 HW:0 U:4.9/m I: 8                    

The botnet detection would cause you to see constant disconnects whenever you authorized a banned worker.  It is quite obvious if it's affecting you.  I'd try reconnecting and seeing if you're still noticing any kind of drop.  The only reason I can see for a drop is if your miner didn't reconnect promptly (since hash rates displayed are an hour long average, it takes a while for the ESTIMATED HASH RATE to become accurate again).