[CLOSED] BTC Guild - Pays TxFees+NMC, Stratum, VarDiff, Private Servers

[m3ta]

CGminer is constantly throwing a Pool 0 not providing work fast enough.

[1714209688]

1714209688

[1714209688]

1714209688

[1714209688]

1714209688

[1714209688]

1714209688

[eleuthria]

Pushing a few updates to the pool today to help with the growth we're seeing due to the rally.  This will cause a few brief periods of idles, but should solve any other idles being caused by malicious/broken miners.

[CyberPhunk]

All three of my miners are mining away, submitting shares, but the stats are not updating, haven't for 15 minutes or so.

This related to the updates or is it some other issue?!?

*edit*

As soon as I posted this, they stopped. Oh, well

[eleuthria]

Everything should be going smooth again.  Any idle issues should be clearing up, I've added more detailed getwork/share submissions to the logs [something I used to do back with pushpool, not with poolserverj].  I've already temporarily banned a few workers who were operating under 10% efficiency while requesting multiple getworks per second.

I will not ban inefficient workers when they're only requesting a piece of work infrequently, so CPU miners don't need to worry.  These bans are targetting workers which are asking for abnormal amounts of work while returning very few valids.

[slush]

I do not have any plans to support I0C merged mining.  The fact that anybody has the slightest interest in I0C at this point is baffling.  It's got nothing to offer.  The only reason I implemented NMC merged mining was that NMC serves a purpose outside of being traded for BTC (even if most people don't utilize that purpose).  Nothing like that can be said of any other altcoin.  Piggybacking chains onto BTC when they are technically a competing chain is just stupid.

Where can I sign this?

[slush]

This will cause a few brief periods of idles, but should solve any other idles being caused by malicious/broken miners.

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).

[eleuthria]

This will cause a few brief periods of idles, but should solve any other idles being caused by malicious/broken miners.

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).

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.

[slush]

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

[eleuthria]

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

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.

[eleuthria]

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.

[CyberPhunk]

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.

Sounds good.

[eleuthria]

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.

[eleuthria]

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.

[DutchBrat]

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 !

[eleuthria]

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.

[ancow]

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.

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.

[eleuthria]

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.

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.

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.

[ancow]

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.

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.

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.

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

Code:

 cgminer version 2.1.2 - Started: [2012-01-15 22:25:51]
--------------------------------------------------------------------------------
 (5s):37.7 (avg):35.9 Mh/s | Q:12251  A:1322  R:10  HW:0  E:11%  U:0.49/m
 TQ: 1  ST: 2  SS: 1  DW: 2083  NB: 300  LW: 0  GF: 14  RF: 6
 Connected to http://btcguild.com:8332 with LP as user XXX
 Block: 000004979cede21724bfa72970fa1b35...  Started: [18:39:38]
--------------------------------------------------------------------------------

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.

[DutchBrat]

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  

[eleuthria]

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.