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

Uh, looks like I need a new pool. My efficiency is always around 4-5% (using cgminer with one primary and two backup pools; the second backup pool doesn't offer merged mining).

i have BTCGuild as the main pool and Deepbit as the backup pool, NO merged mining there

Since with cgminer, merged mining and "normal" mining don't mix well, I'm using two cgminer instances, one for the normal "pools" and one for BTC guild.

Dutchbrat and ancow:  How many pools do you have setup as backups in cgminer?  Of those, how many have merged mining, and how many have merged mining for multiple coins [ix/i0/dvc]?  I'm not positive, but it could be that cgminer's reported efficiency is related to hording work from backup pools.  In that circumstance, your BTC Guild efficiency may be significantly higher.

These numbers are very surprising.  When running my cgminer on a partially loaded 6970 (going at ~300 MH/s) my efficiency stays over 90% for hours on end.  My ban on inefficient miners was going to be much lower (15% range).  It's quite hard to believe that cgminer is that horribly inefficient for some users.

Q: 910936 A:107987 R:109 E:12%

That's on 280 MHash

That is the efficiency on all of my miners

In the end I get the expected Accepted shares and a stale ratio of under 0.4% on avg so I'm a happy camper  

Very recent. Here's my current cgminer's header (timezone is UTC+1):

I assume it's because cgminer is pretty aggressive with keeping only up-to-date work and the constant longpolls each trigger 2 new getworks. (Although the latter can't be the sole culprit, since NB is only 300, which means 600 getworks due to longpolls.)

Edit: I just restarted cgminer, so we'll see what the efficiency is in a day or so, but less that 50% is quite normal here.

Is that a recent number (lots of issues today due to backend)?  I don't see how your efficiency could possible be -that- low unless you're under 10 MH/s.

With the amount of longpolls due to merged mining, my cgminer (~30-60MH/s) reports an efficiency of ~10%-20%. No changes to default queue size, etc.

We were down about 15 minutes (shouldn't have been 20).  One of my backend servers had to be taken down temporarily due to some issues with the ISP and a spam list reporting the IP as a Botnet C&C server.  Everything should be running as normal for now.

Looks like the pool is down, haven't been able to connect for over 20 mins on none of my miners.....

Pool is back up !

Now that everything is back up and running, I'm going to announce a few changes coming to BTC Guild in the coming weeks:

1) BTC Guild will be moving servers again, to a datacenter than can offer more redundancy to the network for higher uptime.  It will be in Illinois, directly on nLayer's network (not a sublease of a sublease of a leased datacenter).

2) This move should be seamless compared to previous moves.  The new server will be sync'ing with the current database before any DNS changes are made.  Ideally, you will see 1 longpoll disconnect, and 1-3 rejects (depending on how big of a work queue your miner stores up), once your DNS has grabbed the new IP address.

3) The pool software will be receiving a few tweaks to be more aggressively aware of botnets which have seen a resurgence since bitcoin went back above $3.  This change will automatically enforce bans for inefficient workers.  While there is some luck involved in finding a share from a getwork, efficiency should never be below 50% after a few dozen getworks have been processed, unless the miner is grabbing significantly more work than it can use.

4) Mining teams will become available.  Similar to what is seen on Deepbit, a Mining Team is not a way to alter your rewards, but instead a way to group up with friends or colleagues.  Teams will have a stats page visible showing the most efficient members, the fastest members, and the luckiest members.


Along with these changes, the site will see a few minor improvements to page load times.  There will also be some work done on the backend to prepare for allowing users to choose between PPS with a 5% fee and PPLNS with a 2% fee, giving users a choice between two fair payout systems, neither of which can be pool hopped.

Everything is back online.  I've disabled a few of the non-essential scripts [Hall of Fame, Pool Graph Logs] while everything settles back down.  Full functionality should be back within the hour.

Sounds good.

Pool server crashed [well, I put it out of its misery, it was going to on its own].  Hasn't had a proper reboot in over a month.  Everything should be back online shortly.

Just checked your pool stats, and we're within about 5% on getwork/s vs hash rate now.  Before these bans I was receiving over 600 getwork/s for roughly the same hash rate as your pool.

EDIT [since this post started a new page and not everybody goes back to catch up]:

The idles in the last 12-24 hours should be resolved at this time.  The recent rally brought back a lot of old time miners/new miners, some of which were either using broken setups or malicious setups, causing a nearly 50% increase in pool server load.  We haven't had this problem since changing from pushpool to poolserverj, so it was not caught before it became a problem.

As of this morning, pool load is back to normal levels, meaning the idles should be resolved.

Heh, few days ago I blocked one miner who performed over 100rq/s. People are insane.

I know cgminer is a bit aggressive, but the extra load it causes at an LP isn't nearly as bad as the load caused by either broken or malicious miners.  I've only banned 8 workers so far, and have dropped the amount of getworks the pool is responding to by close to 20%.  I used to have this process automated back with pushpool, but wasn't comfortable enough with Java to implement it into PoolServerJ until recently.

From my experience, cgminer is behaving in the worst possible way. It uses one longpolling connection just as an indicator for new block, then he triggers N getwork requests to the pool (where N = GPU count). With the rising popularity of cgminer, this is de-facto performing DDoS attack everytime the pool trigger LP broadcast. Unfortunately ckolivas don't see any issue in this...

Correct way is to use N longpolling connections or reuse one getwork between all GPUs (yes, it's possible, unfortunately developers are lazy).

Where can I sign this?