[~1000 GH/sec] BTC Guild - 0% Fee Pool, LP, SSL, Full Precision, and More

[Veldy]

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.

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.

[marcus_of_augustus]

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.

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.

[eleuthria]

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

[maykelmoya]

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

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

[marcus_of_augustus]

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.

[Veldy]

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.

[Veldy]

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.

[marcus_of_augustus]

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.

[eleuthria]

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.

[Veldy]

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

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

[eleuthria]

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.

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

[IlbiStarz]

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.

-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?

[eleuthria]

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.

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

[The Koolio]

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.

[dingus]

Anyone else having trouble getting your pay out? When I click the pay out button the page just goes blank.

[eleuthria]

Anyone else having trouble getting your pay out? When I click the pay out button the page just goes blank.

Send me a PM with your username, I'll take a look at what's happening.

[Veldy]

This entire post has to do with Phoenix 1.48 for what it is worth and with the poclbm and phatk kernels shipped with it.

I found that -q 3 (or 2 or 4) produced extremely high stale rates and there were still network disconnections causing the GPU to idle.  Howevever, with Phoenix, I did discover something that seems to be helping [probably with any pool].  People should experiment with setting this and see how their results change once the pool is stable.

-a (average samples) - Sets the number of samples to use for hashrate averaging. Default is 10. You might want to lower this for longer kernel execution times. (high aggression)

My original thought was that this would just affect the display of the hash rate in the miner.  Indeed, that may be all it does.  However, it occurred to me that perhaps some of the code is written in such a way that tracking the data and calculating this value may be just enough to effect performance [why offer the option otherwise ... almost seems silly].  So, I gave it a shot. 

I will know in a bit if it helps with stale/rejected shares or not [or perhaps solve rates?]. 

Here is what I have:

Machine	Card	Phoenix Options
Main Workstation - Win7 x64 Pro - Aero on	Radeon 6970	VECTORS BFI_INT FASTLOOP=true WORKSIZE=128 AGGRESSION=9 -a 8 -k poclbm
Dedicated Miner 1 - Win 7 x64 HomePrem - Aero off	Radeon 5850	DEVICE=0 VECTORS BFI_INT WORKSIZE=128 FASTLOOP=false AGGRESSION=12 -a 8 -k phatk
Dedicated Miner 2 - Vista 7 x64 Ultimate - Aero off	Radeon 5850	DEVICE=0 VECTORS BFI_INT WORKSIZE=128 FASTLOOP=false AGGRESSION=12 -a 8 -k phatk

Catalyst 11.5 drivers ONLY without Stream SDK installed [so, it is using 2.4 as supplied by the driver package].

Phoenix has been a stale nightmare for my 6970 and I have been using poclbm.exe to mine with [since the rates are the same as with phoenix and phatk doesn't help the 6970 yet].  My 5850s have averaged with poclbm.exe about 0.5% stale rates, however, with phoenix, the rate would over time go between 0.7% and 1.0% in several thousand shares.  Switch to the phatk kernel in phoenix increased the MH/s rate by about 3.4% ... so now the stale rates are more than offset.  Since I put -a 8 n there, not a single stale.  Having said that, there have been very few long polling pushes since I started the test.  My real question is what is the most appropriate value for this additional setting.  I used 8 as a conservative start to see if there was an effect, but I am not sure how far it should be pushed.  It may also be different with my 6970 since it is both different hardware, faster, lower aggression and using FASTLOOP.  I will report back in a few hours.

So far, extremely good results against deepbit.net (the most similar to BTC Guild from a mining perspective I think), although again, the sample size is still very small and I have not many long polling requests yet. Not a single rejected/stale share in over 1000 shares submitted [between my miners].  I anticipate similar results with BTC Guild ... but right now I can't test these settings adequately here, but I will be back soon .  It may very well turn out that -a does absolutely nothing to affect stale shares [which I suspect is probably the case], but so far, it seems otherwise.

When the pool issues are resolved with BTC Guild such that I don't get any more idles or disconnects [need both to test this] and when I have taken a large enough sample on my current test, I will jump on back to BTC Guild and do an extended run, compare ... and stay ... tweaking as necessary.

So, I hope this may help some fellow miners out there and BTC Guild thread readers get the first heads up I guess   For what it is worth, it didn't seem to impact the results with -q 3 (tried -q 2 and  -q 4 and -q 3 was the best of the poor options) meaning that things did not get worse than they were with -q 3, but it was impossible to really know what was really happening due to occasional network disconnects.

[dingus]

Anyone else having trouble getting your pay out? When I click the pay out button the page just goes blank.

Send me a PM with your username, I'll take a look at what's happening.

I just checked it again and it seemed to work. The coins have now showed up in my wallet.

[Veldy]

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.

If it helps any, I think the current and previous block have turned out to be quite difficult for most pools ... just received a long pull, so maybe easier blocks are on the way.

[russelljohnson]

Are the connection errors due to attacks or due to big increase of hashing power on the pool? both?