Topic: [~1000 GH/sec] BTC Guild - 0% Fee Pool, LP, SSL, Full Precision, and More - page 121. (Read 379090 times)
June 04, 2011, 01:40:40 PM
Anyone else having trouble getting your pay out? When I click the pay out button the page just goes blank.
June 04, 2011, 01:38:09 PM
I hate these long as rounds! 4 hours 
on the other hand I finally forgave being tight.... Eleuthria you have an extra 2.5% coming from me now, and with another 4 x 5870's coming next week that should be quite a bit.
on the other hand I finally forgave being tight.... Eleuthria you have an extra 2.5% coming from me now, and with another 4 x 5870's coming next week that should be quite a bit.
June 04, 2011, 01:26:23 PM
What does -q 3 do? It dropped the hash rate of my best card by 5MH/s (that is a 1+% loss on that card, but seemingly made up by the lack of stale shares 
). Again, time will tell.
). Again, time will tell.-q shouldn't affect your hash rate much/at all. The -q argument tells phoenix to grab extra work, meaning a delay in receiving work from the server won't hit you as hard because your client has some extra work units already stored locally. This is also why it can increase stales, since the recent phoenix seems to (sometimes) keep working on its queue instead of flushing it after an LP.
Anything poclbm users can do?
Unfortunately poclbm doesn't have an argument of this nature.
June 04, 2011, 01:12:23 PM
What does -q 3 do? It dropped the hash rate of my best card by 5MH/s (that is a 1+% loss on that card, but seemingly made up by the lack of stale shares ). Again, time will tell.
). Again, time will tell.-q shouldn't affect your hash rate much/at all. The -q argument tells phoenix to grab extra work, meaning a delay in receiving work from the server won't hit you as hard because your client has some extra work units already stored locally. This is also why it can increase stales, since the recent phoenix seems to (sometimes) keep working on its queue instead of flushing it after an LP.
Anything poclbm users can do?
June 04, 2011, 01:09:42 PM
What does -q 3 do? It dropped the hash rate of my best card by 5MH/s (that is a 1+% loss on that card, but seemingly made up by the lack of stale shares ). Again, time will tell.
). Again, time will tell.-q shouldn't affect your hash rate much/at all. The -q argument tells phoenix to grab extra work, meaning a delay in receiving work from the server won't hit you as hard because your client has some extra work units already stored locally. This is also why it can increase stales, since the recent phoenix seems to (sometimes) keep working on its queue instead of flushing it after an LP.
June 04, 2011, 01:02:02 PM
In a pre-emptive attempt, since I know it's been going on for a few hours at least on a poclbm client:
Miner idles are a known issue. The problem is NOT hardware this time. CPU, RAM, and hard drive/database I/O are relatively stable and low. The bottleneck seems to be at the bitcoind level. Tomorrow morning (afternoon for some people), I will be implementing a load balancer for splitting workers among multiple bitcoind instances.
I know the new server was supposed to "fix" this, but I will remind everybody that the server size has more than doubled in the last week on the new server, and we're larger than any known pushpool server. Finding these bottlenecks is not as simple as reading logs or graphing top output.
If you're using phoenix to mine, a good way to protect yourself from idles idles is to add -q 3 on each worker. For extremely fast miners (> 600 MH/sec on one miner), -q 4 or -q 5 may be needed. This may increase your stale rate slightly during LPs, some people have been reporting phoenix doesn't properly flush it's queue in the latest version(s).
Miner idles are a known issue. The problem is NOT hardware this time. CPU, RAM, and hard drive/database I/O are relatively stable and low. The bottleneck seems to be at the bitcoind level. Tomorrow morning (afternoon for some people), I will be implementing a load balancer for splitting workers among multiple bitcoind instances.
I know the new server was supposed to "fix" this, but I will remind everybody that the server size has more than doubled in the last week on the new server, and we're larger than any known pushpool server. Finding these bottlenecks is not as simple as reading logs or graphing top output.
If you're using phoenix to mine, a good way to protect yourself from idles idles is to add -q 3 on each worker. For extremely fast miners (> 600 MH/sec on one miner), -q 4 or -q 5 may be needed. This may increase your stale rate slightly during LPs, some people have been reporting phoenix doesn't properly flush it's queue in the latest version(s).
I just moved my miners back over after a prolonged test of deepbit. I put -q 3 in, and while my sample rate is still very low, I am seeing almost 5%. However, it is stopping the idles, which at least is easier on the GPU (less fatigue stress of temperature cycling). Oddly, one miner has not had a stale share yet and it tends to be my worst offender, go figure. Honestly though, my sample size is not even 200 shares after all my miners combined [only running for a few minutes so far], so I will report back if there are issues.
What does -q 3 do? It dropped the hash rate of my best card by 5MH/s (that is a 1+% loss on that card, but seemingly made up by the lack of stale shares
). Again, time will tell.Any ETA on when you will get your load balancing in place with multiple back-end bitcond daemons?
[EDIT] - I see you just wrote that you were testing right while I was composing this message
June 04, 2011, 01:01:42 PM
Doing internal testing on the load balancing right now, update should be pushed out in a few hours, and I've taken notes from how quickly the server gets crushed by reconnect attempts during short downtimes.
June 04, 2011, 10:51:41 AM
Edit: better still how about tunnelling the workers in and shutting EVERYTHING else out?
Then people would have to foward ports and use a special client.
Why special client? Are there problems with RPC across TCP/SSH?
And how much more work is it than stopping miners etc all the time? We need to secure these pools, it is as obvious as the nose on your face. I think creighto says the enemy of the good is the perfect. Anything better than nothing.
The SSH CPU overhead of thousands of miners connected at once may be a lot. Ready to donate more?
BTW, SSH attempts can still be started and left to time out without sign-on. So, essentially the same attack vector [unintentional or intentional] still exists.
Yeah had thought that might be the case but was hoping not ... so what to do? Register IP's with pool, can't imagine that would be popular or that simple either.
My hunch is they DDOS in the hope of colliding with enough work packets that eventually they'll start hitting golden tickets .... if the pool and miners were connected across Tor they wouldn't even know which packets to aim at ... but back to the other overheads there like ssh. Tough one.
June 04, 2011, 10:36:55 AM
Edit: better still how about tunnelling the workers in and shutting EVERYTHING else out?
Then people would have to foward ports and use a special client.
Why special client? Are there problems with RPC across TCP/SSH?
And how much more work is it than stopping miners etc all the time? We need to secure these pools, it is as obvious as the nose on your face. I think creighto says the enemy of the good is the perfect. Anything better than nothing.
The SSH CPU overhead of thousands of miners connected at once may be a lot. Ready to donate more?
BTW, SSH attempts can still be started and left to time out without sign-on. So, essentially the same attack vector [unintentional or intentional] still exists.
June 04, 2011, 10:23:08 AM
I think all you've managed to do their is secure a link between two machines on your home network and poke out an IP link to the pool across the Internet. I don't think you've secured the link to the pool at all. For that I'm pretty sure you need to connect with a sshd on the other side.
The point is to get this guy access to port 8332 on the pool from a host behind a firewall that blocks access to port 8332, but allows ssh.
Having said that, I think that attempting to mine on an employers machine at an employers expense would be unethical, so I hope that is not the goal.
June 04, 2011, 09:06:03 AM
I think all you've managed to do their is secure a link between two machines on your home network and poke out an IP link to the pool across the Internet. I don't think you've secured the link to the pool at all. For that I'm pretty sure you need to connect with a sshd on the other side.
June 04, 2011, 08:04:29 AM
Just create your own SSH tunnel to a machine on your home network. Then setup a port forwarded [tunneled through SSH] to btcguild.com:8332 and make it localhost:8332. Point your miners at 127.0.0.1 instead of btcguild.com and you are ready to go. You don't need a service for this.
Is that feasible? That wouldn't be end-to-end though right, it needs to connect to a server on the other side for that?
Always have trouble wrapping my head around which way the tunnel is going on those remote port forwards
Can you post the command sequence? Ta.
pcHome runs the miner. pcInternet has access to internet and access to A's ssh. Would be something like:
Code:
foo@pcInternet$ ssh -fN -R 8332:btcguid.com:8332 pcHome
foo@pcHome$ ./minerd --url http://localhost:8332/ ...
foo@pcHome$ ./minerd --url http://localhost:8332/ ...
if you have access from pcHome to pcInternet's ssh you can set the tunnel up the other way
Code:
foo@pcHome$ ssh -fN -L 8332:btcguild:8332 pcInternet
foo@pcHome$ ./minerd --url http://localhost:8332/ ...
foo@pcHome$ ./minerd --url http://localhost:8332/ ...
June 04, 2011, 04:16:57 AM
In a pre-emptive attempt, since I know it's been going on for a few hours at least on a poclbm client:
Miner idles are a known issue. The problem is NOT hardware this time. CPU, RAM, and hard drive/database I/O are relatively stable and low. The bottleneck seems to be at the bitcoind level. Tomorrow morning (afternoon for some people), I will be implementing a load balancer for splitting workers among multiple bitcoind instances.
I know the new server was supposed to "fix" this, but I will remind everybody that the server size has more than doubled in the last week on the new server, and we're larger than any known pushpool server. Finding these bottlenecks is not as simple as reading logs or graphing top output.
If you're using phoenix to mine, a good way to protect yourself from idles idles is to add -q 3 on each worker. For extremely fast miners (> 600 MH/sec on one miner), -q 4 or -q 5 may be needed. This may increase your stale rate slightly during LPs, some people have been reporting phoenix doesn't properly flush it's queue in the latest version(s).
Miner idles are a known issue. The problem is NOT hardware this time. CPU, RAM, and hard drive/database I/O are relatively stable and low. The bottleneck seems to be at the bitcoind level. Tomorrow morning (afternoon for some people), I will be implementing a load balancer for splitting workers among multiple bitcoind instances.
I know the new server was supposed to "fix" this, but I will remind everybody that the server size has more than doubled in the last week on the new server, and we're larger than any known pushpool server. Finding these bottlenecks is not as simple as reading logs or graphing top output.
If you're using phoenix to mine, a good way to protect yourself from idles idles is to add -q 3 on each worker. For extremely fast miners (> 600 MH/sec on one miner), -q 4 or -q 5 may be needed. This may increase your stale rate slightly during LPs, some people have been reporting phoenix doesn't properly flush it's queue in the latest version(s).
June 04, 2011, 03:39:46 AM
Eleuthria,
I would be willing to donate a little more if we could indeed tunnel through SSH on the standard SSH port. That port is not blocked at my office firewall, and securing the traffic would be awesome. Right now, ports 8332 is blocked at work, and I was going to have to figure out a way of setting squid proxy on my co-located web server to get traffic to BTCGuild.
I would be willing to donate a little more if we could indeed tunnel through SSH on the standard SSH port. That port is not blocked at my office firewall, and securing the traffic would be awesome. Right now, ports 8332 is blocked at work, and I was going to have to figure out a way of setting squid proxy on my co-located web server to get traffic to BTCGuild.
Just create your own SSH tunnel to a machine on your home network. Then setup a port forwarded [tunneled through SSH] to btcguild.com:8332 and make it localhost:8332. Point your miners at 127.0.0.1 instead of btcguild.com and you are ready to go. You don't need a service for this.
Is that feasible? That wouldn't be end-to-end though right, it needs to connect to a server on the other side for that?
Always have trouble wrapping my head around which way the tunnel is going on those remote port forwards
Can you post the command sequence? Ta.
June 04, 2011, 03:13:39 AM
Eleuthria,
I would be willing to donate a little more if we could indeed tunnel through SSH on the standard SSH port. That port is not blocked at my office firewall, and securing the traffic would be awesome. Right now, ports 8332 is blocked at work, and I was going to have to figure out a way of setting squid proxy on my co-located web server to get traffic to BTCGuild.
I would be willing to donate a little more if we could indeed tunnel through SSH on the standard SSH port. That port is not blocked at my office firewall, and securing the traffic would be awesome. Right now, ports 8332 is blocked at work, and I was going to have to figure out a way of setting squid proxy on my co-located web server to get traffic to BTCGuild.
Just create your own SSH tunnel to a machine on your home network. Then setup a port forwarded [tunneled through SSH] to btcguild.com:8332 and make it localhost:8332. Point your miners at 127.0.0.1 instead of btcguild.com and you are ready to go. You don't need a service for this.
June 03, 2011, 08:57:20 PM
Eleuthria,
I would be willing to donate a little more if we could indeed tunnel through SSH on the standard SSH port. That port is not blocked at my office firewall, and securing the traffic would be awesome. Right now, ports 8332 is blocked at work, and I was going to have to figure out a way of setting squid proxy on my co-located web server to get traffic to BTCGuild.
I would be willing to donate a little more if we could indeed tunnel through SSH on the standard SSH port. That port is not blocked at my office firewall, and securing the traffic would be awesome. Right now, ports 8332 is blocked at work, and I was going to have to figure out a way of setting squid proxy on my co-located web server to get traffic to BTCGuild.
June 03, 2011, 08:31:06 PM
Edit: better still how about tunnelling the workers in and shutting EVERYTHING else out?
Then people would have to foward ports and use a special client.
Why special client? Are there problems with RPC across TCP/SSH?
And how much more work is it than stopping miners etc all the time? We need to secure these pools, it is as obvious as the nose on your face. I think creighto says the enemy of the good is the perfect. Anything better than nothing.
June 03, 2011, 08:21:22 PM
Edit: better still how about tunnelling the workers in and shutting EVERYTHING else out?
Then people would have to foward ports and use a special client.
June 03, 2011, 08:07:13 PM
What % of blocks found by btcguild have later turned out to be invalid? I need to know this so I can calculate a real figure of how much more you can expect to make with btcguild over deepbit.
In the long run, you will make 3% less at deepbit because that's how much they charge for fees. Anything else is inconclusive.eleuthria: Yes, the sample size is too small. Perhaps [Tycho] would be kind enough to share the stats from his pool?
[Tycho]: how many of your blocks have turned out to be invalid?
June 03, 2011, 07:54:07 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.
Do this.
Edit: better still how about tunnelling the workers in and shutting EVERYTHING else out?
Here,
Simplest implementation to secure mining traffic and make shutting out DDOS easier;
miners run something like this in a terminal
Code:
$ ssh -L 8332:btcguild.com:8332 username@shellserver
need username and passwords for ssh (do nothing else but login and connect to bitcoind_server on port 8332)
and they can run their miners using this
Code:
./poclbm.py -d1 --host=localhost --port=8332 --user=worker_name --pass=worker_password
(make sure no local bitcoind using 8332, e.g. solo mining, so could also change that but kept it simple to begin with).
Jump to: