Bitcoin Forum
December 03, 2016, 05:55:12 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 [37] 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 ... 159 »
  Print  
Author Topic: [~1000 GH/sec] BTC Guild - 0% Fee Pool, LP, SSL, Full Precision, and More  (Read 358612 times)
CubedRoot
Sr. Member
****
Offline Offline

Activity: 295


View Profile
June 03, 2011, 07:11:50 PM
 #721

How about deny everything and have people enter their worker IPs when they setup workers.  Then just open up the source IP for each worker.

+1 Simpel and effective

HEh... see my post above yours.... not simple if your ISP gives you dynamic IPs that change every few days.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480787712
Hero Member
*
Offline Offline

Posts: 1480787712

View Profile Personal Message (Offline)

Ignore
1480787712
Reply with quote  #2

1480787712
Report to moderator
1480787712
Hero Member
*
Offline Offline

Posts: 1480787712

View Profile Personal Message (Offline)

Ignore
1480787712
Reply with quote  #2

1480787712
Report to moderator
1480787712
Hero Member
*
Offline Offline

Posts: 1480787712

View Profile Personal Message (Offline)

Ignore
1480787712
Reply with quote  #2

1480787712
Report to moderator
DeiBellum
Newbie
*
Offline Offline

Activity: 22


View Profile
June 03, 2011, 07:13:48 PM
 #722

Cubed Root has it right on.

Most ISPs use a Dynamic IP system for all the routers on their network. They can change frequently and would leave people SOL once their's changed.


I think the best long term solution would be to have an automatic firewall tool. Some templates I would recommend would be fail2ban or denyhosts. These both use "After X attempts and Y failures" approach and is something that I could see being adapted for the mining server.

If you like what I have posted please donate Smiley
1J5cNFGrTZPAWXhGDDkESWRQwtR5k5KbLw
bitcoindaddy
Hero Member
*****
Offline Offline

Activity: 481


View Profile
June 03, 2011, 07:30:07 PM
 #723

I think eleuthria has gotten things under control again. My hash rate (on the website) has gone back up and the total GHash rate of btcguild is skyrocketing.
Carnth
Hero Member
*****
Offline Offline

Activity: 634



View Profile
June 03, 2011, 07:35:04 PM
 #724

What is the problem to do this banning automatically? either using iptables or directly in the pool server daemon?

Count number of requested shares, returned .. if exceeds some maxima, ban the IP for 10 minutes.

Doing this by "hand" from logs is tedious work which will not adapt to other DDoSers.

I don't think you realize that this is the first time this has happened to this pool.
I very sure eleuthria will do exactly what you suggest to take care of any future problems.

Again everyone.... You patience during these growing pains is appreciated. Eleuthria is working his ass off trying to make this the best pool there is.
Carnth
Hero Member
*****
Offline Offline

Activity: 634



View Profile
June 03, 2011, 07:39:44 PM
 #725

How about deny everything and have people enter their worker IPs when they setup workers.  Then just open up the source IP for each worker.
Although this would solve problems for the pool servers, we "the masses" are not very good at doing this. I'm sure most people who are mining right now know their way around an IP address. But the "average" person doesn't. Plus then you have to deal with dynamic IPs and the whole thing gets way to complicated.
eleuthria
Legendary
*
Offline Offline

Activity: 1750


BTC Guild Owner


View Profile WWW
June 03, 2011, 08:08:14 PM
 #726

Part of the problem has been identified and corrected, related to the update pushed yesterday (index was in reversed order, causing MySQL to lock a much larger portion of the table than needed when doing an update).

This has been corrected, and the frequency of idles has plummeted already.  There is still the problem of some miners, which I previously called an attack.  It is POSSIBLE these are not actual hostile attacks, and rather a number of misconfigured miners, or miners operating at queue depth that is calling for an absurd amount of work.

I am working on an automated rule for adding these overly aggressive requests to IPtables to filter the traffic out.

As of right now, the idles seem to center around long polls, which are hitting the server with over 5,000 getwork requests in a single second due to the miners flushing their queues and grabbing work.  At this time, it looks like that will cause idles for some users, and the bottleneck appears to be bitcoind.  I am working on a modification to pushpool which will load balance between different bitcoind instances.

R.I.P. BTC Guild, 2011 - 2015.
BTC Guild Forum Thread
eleuthria
Legendary
*
Offline Offline

Activity: 1750


BTC Guild Owner


View Profile WWW
June 03, 2011, 09:42:52 PM
 #727

Just putting this out there as a public service announcement:

If you're going to install miners on a school network in Missouri, don't screw up the settings.  Sending 101,000 work requests and only returning 91 is not the most efficient way to steal resources from systems funded taxpayers.

R.I.P. BTC Guild, 2011 - 2015.
BTC Guild Forum Thread
SgtSpike
Legendary
*
Offline Offline

Activity: 1344



View Profile
June 03, 2011, 09:43:58 PM
 #728

Just putting this out there as a public service announcement:

If you're going to install miners on a school network in Missouri, don't screw up the settings.  Sending 101,000 work requests and only returning 91 is not the most efficient way to steal resources from systems funded taxpayers.
Lol, win.
btcboston
Member
**
Offline Offline

Activity: 99


View Profile
June 03, 2011, 09:45:28 PM
 #729

Very nice run for the pool here over the last couple hours.  Looks like the luck is finally starting to turn.

Veldy
Member
**
Offline Offline

Activity: 98



View Profile
June 03, 2011, 09:51:15 PM
 #730

Just putting this out there as a public service announcement:

If you're going to install miners on a school network in Missouri, don't screw up the settings.  Sending 101,000 work requests and only returning 91 is not the most efficient way to steal resources from systems funded taxpayers.

Accidentally DOSd by some kid(s) at a school  Cheesy  Stupid since the school is unlikely to have a significant GPU in any of it's machines, and bound to get caught.

If you have found my post helpful, please donate what you feel it is worth: 18vaZ4K62WiL6W2Qoj9AE1cerfCHRaUW4x
Veldy
Member
**
Offline Offline

Activity: 98



View Profile
June 03, 2011, 10:17:55 PM
 #731

I am still seeing several idle times, often as long as 20 seconds.  Oddly, I saw most of them on only one miner [the only one not on wireless  Huh].  I have a rock solid wireless network with QoS and WISH setup for allowing port 8332 proper priority.  But 20 seconds at a time idled isn't so hot.  Most were only a second or two, but several were longer.  I didn't mine very long ... just testing the waters before I took a dip again.  I have been rock solid elsewhere with ~0.5% stale on all miners and no more than one or two idle timeouts that I logged in 12 hours and they were so short as to be meaningless.

Thoughts?  I know you have been working on this and good job thus far getting things up and running pretty solidly again.  Unfortunately, I don't think your work is quite over yet.

If you have found my post helpful, please donate what you feel it is worth: 18vaZ4K62WiL6W2Qoj9AE1cerfCHRaUW4x
Genrobo
Newbie
*
Offline Offline

Activity: 28


View Profile
June 03, 2011, 10:29:25 PM
 #732

Just putting this out there as a public service announcement:

If you're going to install miners on a school network in Missouri, don't screw up the settings.  Sending 101,000 work requests and only returning 91 is not the most efficient way to steal resources from systems funded taxpayers.

Now, if it wasn't an intentional attack...
You may consider leaving them unblocked...
But if I was the pool operator, I'd go ahead and ban that IP range.
That's just me though.  Cool

17YwW6cuSbXLT8cvvdAcfy1iHyPkhVE7CG
Donations welcome, not required.
I'll be honest, any donations aren't used for a good cause, they go directly to booze, food, herbal substances Wink, and computer hardware.
I will squander the money, but hell, at least you know one person is having a good time.
Veldy
Member
**
Offline Offline

Activity: 98



View Profile
June 03, 2011, 10:41:21 PM
 #733

Just putting this out there as a public service announcement:

If you're going to install miners on a school network in Missouri, don't screw up the settings.  Sending 101,000 work requests and only returning 91 is not the most efficient way to steal resources from systems funded taxpayers.

Now, if it wasn't an intentional attack...
You may consider leaving them unblocked...
But if I was the pool operator, I'd go ahead and ban that IP range.
That's just me though.  Cool

Slippery slope.  Probably better to script getworks to accepted shares [and duration between said getworks and accepted shares] and if the threshold is triggered, fire off an entry in the firewall to ban them ... thus, this scenario where rapid getworks were occurring, but almost no work actually was generated would be avoided after a little bit. Unfortunately, it probably represents large CPU mining pools and it could essentially exclude them].

If you have found my post helpful, please donate what you feel it is worth: 18vaZ4K62WiL6W2Qoj9AE1cerfCHRaUW4x
brunoshady
Sr. Member
****
Offline Offline

Activity: 264

Dubs Get


View Profile
June 03, 2011, 10:59:51 PM
 #734

down?
russelljohnson
Member
**
Offline Offline

Activity: 84



View Profile
June 03, 2011, 11:00:09 PM
 #735

down?

feels down to me...

what's going on...

If you've found my post helpful, send me some bitcoins!
1FkGxXmesGbhoFewYGrtNEmifzwvNaNCXH
brunoshady
Sr. Member
****
Offline Offline

Activity: 264

Dubs Get


View Profile
June 03, 2011, 11:10:58 PM
 #736

2 miners/workers of the same pool in the same GPU can work better than just one?
brunoshady
Sr. Member
****
Offline Offline

Activity: 264

Dubs Get


View Profile
June 03, 2011, 11:17:28 PM
 #737

any chance to delete workers?

=/
eleuthria
Legendary
*
Offline Offline

Activity: 1750


BTC Guild Owner


View Profile WWW
June 03, 2011, 11:28:33 PM
 #738

Server is back up, logs were tweaked to automate some of this process.  Restarting pushpool involved a fairly long period of idles/connection errors due to the absolute flood of reconnects miners attempted for every milisecond that it was offline apparently (no reconnect delay).  Took a while to settle down, but now that it has things are going good.

Some miners -may- have lost their long poll connection, so restarting a miner briefly could fix the issue if you're not seeing any LPs issued.

R.I.P. BTC Guild, 2011 - 2015.
BTC Guild Forum Thread
russelljohnson
Member
**
Offline Offline

Activity: 84



View Profile
June 03, 2011, 11:32:49 PM
 #739

Server is back up, logs were tweaked to automate some of this process.  Restarting pushpool involved a fairly long period of idles/connection errors due to the absolute flood of reconnects miners attempted for every milisecond that it was offline apparently (no reconnect delay).  Took a while to settle down, but now that it has things are going good.

Some miners -may- have lost their long poll connection, so restarting a miner briefly could fix the issue if you're not seeing any LPs issued.

thanks eleuthria. everything looking good now.

If you've found my post helpful, send me some bitcoins!
1FkGxXmesGbhoFewYGrtNEmifzwvNaNCXH
Soros Shorts
Donator
Legendary
*
Offline Offline

Activity: 1455



View Profile
June 03, 2011, 11:39:19 PM
 #740

My BTC Guild miners did not pick up the following 2 new blocks that were picked up by miners connected to other pools:

03/06/2011 19:10:35, long poll: new block 000002a2a5aaadae
03/06/2011 19:14:59, long poll: new block 00001239399053ae

Time zone is ET. While this was happening the pool was happily accepting a bunch of (possibly stale) work.

Was this just me or did everyone else on BTC Guild miss these 2 blocks?
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 [37] 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 ... 159 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!