Bitcoin Forum
November 14, 2024, 08:54:05 PM *
News: Check out the artwork 1Dq created to commemorate this forum's 15th anniversary
 
   Home   Help Search Login Register More  
Pages: [1] 2 »  All
  Print  
Author Topic: How to Avoid DDoS and Other Downtime  (Read 5579 times)
Meatball (OP)
Sr. Member
****
Offline Offline

Activity: 378
Merit: 250



View Profile
June 13, 2011, 08:35:56 PM
 #1

I'm seeing more and more posts about people freaking out that their favorite pool x got hit with to Denial of Service attack or was down and they lost hours of mining.  There's not a whole lot you can do about the DoS attacks and as some pools get larger, there's people that will attempt to knock the pool's hashing power offline and give them a better shot at finding blocks.  Yeah, it sucks, but that's the way it is.

While the pool operators are doing their best to keep their pools up and running, there's a simple thing that you can do to stop your clients from losing any mining time when the pools get attacked, set up two "miners" for every GPU/CPU.

All you need to do is to set up and run a secondary miner object for each GPU/CPU with a lower "aggression" and point it to either another pool (preferably a smaller one that won't be a target) or to a local bitcoin server so you can solo mine when your primary pool is offline.

For example, I use GUIMiner/Poclbm for most of my mining and I set up two miners for my GPU's.  On one of my GPU's, a 6950, I have one miner pointing to my primary pool I mine for, and another miner, using the same 6950, pointing to my local bitcoin client/server.  I set the primary miner with the flag '-f 1' and the secondary miner with the flag '-f 15'.  I start both and let them run at the same time.  The primary miner runs at just about full speed (~ 369 MH/s), while the secondary miner runs at very low speed (~1 MH/sec).  If there's any connection problems with the primary '-f 1' miner, the secondary '-f 15' miner ramps right up and starts hammering away full speed at solo mining.

There's no reason you couldn't set up your secondary miner to point to another pool, and even a third or fourth miner for the same GPU for even more fallback options.  I know the other miners like Phoenix and Diablo have 'aggression' flags that will do pretty much the same thing at the -f flag with GUIMiner/Poclbm and with a bit of experimentation you can get things set up to fail over easily.

I'm pretty sure one of the reasons folks are doing DoS attacks is to kill a portion of the network power and give better odds in finding a block.  If everyone would just set up their miners to have 2 or 3 fallback options the network power would hardly skip a beat, even if the bigger pools get knocked offline.

Seriously, spend the time to set up secondary/tertiary miners for each of your GPU/CPU's, you won't be sorry.
TheShoura
Member
**
Offline Offline

Activity: 98
Merit: 10

Testing


View Profile
June 13, 2011, 08:52:15 PM
 #2

This is very, very helpful and I am going to try this asap

thank you Smiley


Do I need to make two different directories, or can i just launch the same executable twice (refering to GUI miner, it saves its config in %appdata% directory so if i edit one GUIminer, they all get affected for now)


If you would like to send me a tip: 1HVGGWGWgHkyh9K8sntkZmXoiopX8Bsvv8

Security: 8452BCD9
ALWAYS gpg ident the person you're about to exchange with!
Meatball (OP)
Sr. Member
****
Offline Offline

Activity: 378
Merit: 250



View Profile
June 13, 2011, 08:55:20 PM
 #3

No need to launch GUIMiner twice.  Sorry if I didn't clarify.

In the same GUIMiner window just hit "File -> New OpenCL Miner" and create a secondary miner.  You can then set that miner to use the same GPU/CPU and just point it to a differnent pool/local server and give it the higher -f flag.  Start both up and you're good to go...
TheShoura
Member
**
Offline Offline

Activity: 98
Merit: 10

Testing


View Profile
June 13, 2011, 08:56:11 PM
 #4

No need to launch GUIMiner twice.  Sorry if I didn't clarify.

In the same GUIMiner window just hit "File -> New OpenCL Miner" and create a secondary miner.  You can then tell that miner to use the same GPU/CPU and just point it to a differnent pool/local server and give it the higher -f flag.  Start both up and you're good to go...

Ahhhhh brilliant! Thank you! I'll try to remember to tip you on my next pool cash out, this is really awesome advice man, thank you!

If you would like to send me a tip: 1HVGGWGWgHkyh9K8sntkZmXoiopX8Bsvv8

Security: 8452BCD9
ALWAYS gpg ident the person you're about to exchange with!
Meatball (OP)
Sr. Member
****
Offline Offline

Activity: 378
Merit: 250



View Profile
June 13, 2011, 08:58:10 PM
 #5

Ah, no worries.  Happy to do it.  I'd bet if everyone set up secondary miners that mined solo, DDoS attacks would probably ease up because there'd be no drop in total network power even if a pool goes down.
mjsbuddha
Sr. Member
****
Offline Offline

Activity: 336
Merit: 250


yung lean


View Profile
June 13, 2011, 09:06:17 PM
 #6

When I do this it seems I lose about 10% total hash rate. Thats the only reason I don't.
TheShoura
Member
**
Offline Offline

Activity: 98
Merit: 10

Testing


View Profile
June 13, 2011, 09:07:37 PM
 #7

When I do this it seems I lose about 10% total hash rate. Thats the only reason I don't.

I've lost quite a bit of hash time due to downtime.... If I can tweak this enough to avoid downtime all together, I think I will

If you would like to send me a tip: 1HVGGWGWgHkyh9K8sntkZmXoiopX8Bsvv8

Security: 8452BCD9
ALWAYS gpg ident the person you're about to exchange with!
Meatball (OP)
Sr. Member
****
Offline Offline

Activity: 378
Merit: 250



View Profile
June 13, 2011, 09:11:43 PM
 #8

When I do this it seems I lose about 10% total hash rate. Thats the only reason I don't.

Yeah, you'll lose a bit because the secondary miner is set with a lower aggression rate, but with the -f 1 / -f 15 I usually don't lose more than a few MH/sec.  My 6950 drops from ~369 to ~363.  On another machine I have 5830's on I drop from ~ 299 MH/sec to 295 MH/sec when 'failed over' to the secondary.

I'd much rather lose a few percentage points on my secondary miner when it ramps up than lose 100% of the mining when my primary is down.

You could set both primary and secondary miners to say -f 1 and it'd split the mining equally between the both of them and still have full power to one of them if the other goes down.  Of course, then you're splitting your mining, so, it's a judgement call.

Experiment with two miners and different aggression rates, you can start/stop the miner to simulate one of them going down and compare what you'd get at different rates.
supa
Copper Member
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
June 13, 2011, 09:17:24 PM
 #9


Don't like the Flexible Proxy Project?

I haven't used it, but it seems a bit more elegant than running 99 miners on 99 pools to dodge downtime....

I use a C++ proxy that I should eventually release.
mjsbuddha
Sr. Member
****
Offline Offline

Activity: 336
Merit: 250


yung lean


View Profile
June 13, 2011, 09:22:05 PM
 #10

I go from about 330mhash a core to 310mhash. Unless my miners are down for 2 hours a day, I'm losing money by doing this. I agree that this isnt really much of a solution. Thy should build failover control into guiminer or something.
kcobra
Member
**
Offline Offline

Activity: 87
Merit: 10


View Profile
June 13, 2011, 09:22:58 PM
 #11

I tried this with phoenix and the phatk kernel. Gave the primary miner an aggression value of 11 and the secondary miner an aggression of 1. This worked fun until I took down the primary miner. The mh/s on the secondary miner only jumped from ~1 mh/s to ~15 mh/s. It should have jumped to ~300 mh/s.

I can set the aggression the same on both the primary and secondary and then they both run ~150 mh/s. I don't want to do that though as it makes my rigs a bit less stable.
Meatball (OP)
Sr. Member
****
Offline Offline

Activity: 378
Merit: 250



View Profile
June 13, 2011, 09:29:03 PM
 #12


Don't like the Flexible Proxy Project?

I haven't used it, but it seems a bit more elegant than running 99 miners on 99 pools to dodge downtime....

I use a C++ proxy that I should eventually release.


Proxies are definitely a viable alternative, but might be a bit complicated to set up for some folks.  I run 20 different miners across 6 machines and it hasn't been a huge burden.  Once the secondary miners are set up you don't have to do anything, so it's an extra couple of minutes to get them going, but then you're set.

I go from about 330mhash a core to 310mhash. Unless my miners are down for 2 hours a day, I'm losing money by doing this. I agree that this isnt really much of a solution. Thy should build failover control into guiminer or something.

I agree on the built-in failover control , that would be the best option of all.  I'm not sure I follow you on the losing 20 MH/sec though.  Are you losing that from your primary miner when the secondary is running?  Or is that the secondary going full out when the primary is down?  

I tried this with phoenix and the phatk kernel. Gave the primary miner an aggression value of 11 and the secondary miner an aggression of 1. This worked fun until I took down the primary miner. The mh/s on the secondary miner only jumped from ~1 mh/s to ~15 mh/s. It should have jumped to ~300 mh/s.

I can set the aggression the same on both the primary and secondary and then they both run ~150 mh/s. I don't want to do that though as it makes my rigs a bit less stable.

I gave up on using phoenix/phatk because I was actually getting better numbers using poclbm no matter what I tried.  Try tweaking the secondary miner a bit though and run it with a higher number.  You might find a balance that works.
supa
Copper Member
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
June 13, 2011, 09:35:46 PM
 #13


Don't like the Flexible Proxy Project?

I haven't used it, but it seems a bit more elegant than running 99 miners on 99 pools to dodge downtime....

I use a C++ proxy that I should eventually release.


Proxies are definitely a viable alternative, but might be a bit complicated to set up for some folks.  I run 20 different miners across 6 machines and it hasn't been a huge burden.  Once the secondary miners are set up you don't have to do anything, so it's an extra couple of minutes to get them going, but then you're set.

Some folks need to get on the ball, then! Wink

There's also a modified poclbm that has a fallback option floating around somewhere.

It's good to hear you are having luck with your improvised system, but there is clearly a need for a better solution.
mjsbuddha
Sr. Member
****
Offline Offline

Activity: 336
Merit: 250


yung lean


View Profile
June 13, 2011, 09:39:42 PM
 #14

The proxy is still a single point of failure. It just moves it from the pool to the proxy server.
Freakin
Full Member
***
Offline Offline

Activity: 154
Merit: 100


View Profile
June 13, 2011, 10:14:06 PM
 #15

The proxy is still a single point of failure. It just moves it from the pool to the proxy server.

How many threads have you seen about people's proxies going down?  How many for pools being DDOSed?

The proxy is much more reliable than the frequently crashing/DDOSed pools.
supa
Copper Member
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
June 13, 2011, 11:12:15 PM
 #16

The proxy is still a single point of failure. It just moves it from the pool to the proxy server.

How many threads have you seen about people's proxies going down?  How many for pools being DDOSed?

The proxy is much more reliable than the frequently crashing/DDOSed pools.

No point arguing, besides...  I've seen the light.

This guy is completely right.  I can't believe how silly I'm being.  I mean... I use Linux and several boxes for everything, but all of that is "single points of failure."

What if someone hax0rs my kernels?  I should totally start mixing Windows and MacOS boxes into my miner pool to avoid that single point of failure.  While I'm at it, I think I'm going to order a couple of T1s that are provided by several different service providers.  And ATI cards - crap, the drivers are a single point of failure.  I'm going to have to make large NVIDIA farms just to be redundant for my boxes!

And my name servers.  I only have 2 and they're both from the same provider!  Oh shiii-!  What if that goes down?  I'm going to need to convince all of the pool operators to join an MPLS cloud.

Wait... the MPLS requires internet to be functioning....  F#@#!  I'm going to have to call Al Gore and see if we can reinvent the internet as an alternate path to my pools!
nomnomnom
Sr. Member
****
Offline Offline

Activity: 313
Merit: 250



View Profile
June 13, 2011, 11:27:55 PM
 #17

Hello,


Don't like the Flexible Proxy Project?

I haven't used it, but it seems a bit more elegant than running 99 miners on 99 pools to dodge downtime....

I use a C++ proxy that I should eventually release.


Proxies are definitely a viable alternative, but might be a bit complicated to set up for some folks.  I run 20 different miners across 6 machines and it hasn't been a huge burden.  Once the secondary miners are set up you don't have to do anything, so it's an extra couple of minutes to get them going, but then you're set.

Some folks need to get on the ball, then! Wink

There's also a modified poclbm that has a fallback option floating around somewhere.

It's good to hear you are having luck with your improvised system, but there is clearly a need for a better solution.


I guess you mean this poclbm with backup options -> https://github.com/kylegibson/poclbm
Seems to do what it should, but I don't like poclbm, have a lot of "miner is idle" with it Sad

If you could release your c++ proxy that would be great, I assume this doesn't need mysql?
Pretty sure that people would be willing to donate you something for that.
I Was thinking about this flexible miner proxy, but maybe its not so a great idea to
run mysql server on a usb-stick Cheesy
mjsbuddha
Sr. Member
****
Offline Offline

Activity: 336
Merit: 250


yung lean


View Profile
June 13, 2011, 11:59:49 PM
 #18

The proxy is still a single point of failure. It just moves it from the pool to the proxy server.

How many threads have you seen about people's proxies going down?  How many for pools being DDOSed?

The proxy is much more reliable than the frequently crashing/DDOSed pools.

No point arguing, besides...  I've seen the light.

This guy is completely right.  I can't believe how silly I'm being.  I mean... I use Linux and several boxes for everything, but all of that is "single points of failure."

What if someone hax0rs my kernels?  I should totally start mixing Windows and MacOS boxes into my miner pool to avoid that single point of failure.  While I'm at it, I think I'm going to order a couple of T1s that are provided by several different service providers.  And ATI cards - crap, the drivers are a single point of failure.  I'm going to have to make large NVIDIA farms just to be redundant for my boxes!

And my name servers.  I only have 2 and they're both from the same provider!  Oh shiii-!  What if that goes down?  I'm going to need to convince all of the pool operators to join an MPLS cloud.

Wait... the MPLS requires internet to be functioning....  F#@#!  I'm going to have to call Al Gore and see if we can reinvent the internet as an alternate path to my pools!


Well I don't have 2 T1's but I do have a failover connection Tongue I guess I just take my money making more seriously then most.
V2-V3
Full Member
***
Offline Offline

Activity: 227
Merit: 100



View Profile
June 14, 2011, 03:30:30 AM
 #19

The hash rate may not be as good with the aggro method bit its a trade off between bigger pools w/ more frequent payouts vs mining on smaller pools

jondecker76
Full Member
***
Offline Offline

Activity: 238
Merit: 100


View Profile
June 14, 2011, 03:39:47 AM
 #20

Please see my post here, http://forum.bitcoin.org/index.php?topic=16548.0

I'm working on an automated solution to this exact thing and will need testers soon!

RollerBot Advanced Trading Platform
https://bitcointalk.org/index.php?topic=447727.0
BTC Donations for development: 1H36oTJsi3adFh68wwzz95tPP2xoAoTmhC
Pages: [1] 2 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!