down?
feels down to me...
what's going on...
Topic: [~1000 GH/sec] BTC Guild - 0% Fee Pool, LP, SSL, Full Precision, and More - page 123. (Read 379078 times)
June 03, 2011, 06:00:09 PM
June 03, 2011, 05:59:51 PM
down?
June 03, 2011, 05:41:21 PM
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.
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.
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].
June 03, 2011, 05:29:25 PM
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.
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.
June 03, 2011, 05:17:55 PM
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 
]. 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.
]. 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.
June 03, 2011, 04:51:15 PM
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.
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
Stupid since the school is unlikely to have a significant GPU in any of it's machines, and bound to get caught. June 03, 2011, 04:45:28 PM
Very nice run for the pool here over the last couple hours. Looks like the luck is finally starting to turn.
June 03, 2011, 04:43:58 PM
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. 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.
June 03, 2011, 04:42:52 PM
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.
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.
June 03, 2011, 03:08:14 PM
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.
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.
June 03, 2011, 02:39:44 PM
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. June 03, 2011, 02:35:04 PM
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.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 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.
June 03, 2011, 02:30:07 PM
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.
June 03, 2011, 02:13:48 PM
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.
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.
June 03, 2011, 02:11:50 PM
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.
June 03, 2011, 02:09:38 PM
Parsing through about 2 million lines worth of logs right now after running a sample on the first 5 minutes. Will likely be banning some IPs based off what I saw in the 5 minutes (people with over 1000 requests for work but less than 10 results sent back, some with 0).
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.
Not a good idea... what if we have dynamic IPs from our ISP? Mine changes every few days... so I would loose my workers everytime my IP changed.
June 03, 2011, 02:05:43 PM
Parsing through about 2 million lines worth of logs right now after running a sample on the first 5 minutes. Will likely be banning some IPs based off what I saw in the 5 minutes (people with over 1000 requests for work but less than 10 results sent back, some with 0).
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.
June 03, 2011, 01:57:52 PM
Unless there are only a few (like 3 or 4) IPs doing this, writing a quick log parsing tool would probably be quicker than doing it by hand.
June 03, 2011, 01:53:50 PM
What is the problem to do this banning automatically? either using iptables or directly in the pool server daemon?
Doing it automatically will take more time to develop the code. I'd rather he fix the problem quickly, then go back and look for an elegant way to do it.
June 03, 2011, 01:34:14 PM
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.
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.
Jump to: