Bitcoin Forum
December 10, 2016, 05:01:19 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 88 89 ... 159 »
  Print  
Author Topic: [~1000 GH/sec] BTC Guild - 0% Fee Pool, LP, SSL, Full Precision, and More  (Read 359938 times)
Veldy
Member
**
Offline Offline

Activity: 98



View Profile
June 04, 2011, 08:13:39 AM
 #761

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.

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

Posts: 1481389279

View Profile Personal Message (Offline)

Ignore
1481389279
Reply with quote  #2

1481389279
Report to moderator
1481389279
Hero Member
*
Offline Offline

Posts: 1481389279

View Profile Personal Message (Offline)

Ignore
1481389279
Reply with quote  #2

1481389279
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481389279
Hero Member
*
Offline Offline

Posts: 1481389279

View Profile Personal Message (Offline)

Ignore
1481389279
Reply with quote  #2

1481389279
Report to moderator
1481389279
Hero Member
*
Offline Offline

Posts: 1481389279

View Profile Personal Message (Offline)

Ignore
1481389279
Reply with quote  #2

1481389279
Report to moderator
1481389279
Hero Member
*
Offline Offline

Posts: 1481389279

View Profile Personal Message (Offline)

Ignore
1481389279
Reply with quote  #2

1481389279
Report to moderator
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2100



View Profile
June 04, 2011, 08:39:46 AM
 #762

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  Undecided

Can you post the command sequence? Ta.

eleuthria
Legendary
*
Offline Offline

Activity: 1750


BTC Guild Owner


View Profile WWW
June 04, 2011, 09:16:57 AM
 #763

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

R.I.P. BTC Guild, 2011 - 2015.
BTC Guild Forum Thread
maykelmoya
Newbie
*
Offline Offline

Activity: 13


View Profile
June 04, 2011, 01:04:29 PM
 #764

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  Undecided

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

1D7oFWmoC6aEa6EdN9itmtuTDp9bcZDxEe, thanks.
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2100



View Profile
June 04, 2011, 02:06:03 PM
 #765


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
Member
**
Offline Offline

Activity: 98



View Profile
June 04, 2011, 03:23:08 PM
 #766


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.

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 04, 2011, 03:36:55 PM
 #767

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.

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

Activity: 2100



View Profile
June 04, 2011, 03:51:41 PM
 #768

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
Legendary
*
Offline Offline

Activity: 1750


BTC Guild Owner


View Profile WWW
June 04, 2011, 06:01:42 PM
 #769

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.

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

Activity: 98



View Profile
June 04, 2011, 06:02:02 PM
 #770

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

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

Activity: 1750


BTC Guild Owner


View Profile WWW
June 04, 2011, 06:09:42 PM
 #771

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

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

Activity: 224


View Profile
June 04, 2011, 06:12:23 PM
 #772

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

It's better to be pissed off, than to be pissed on.
BTC : 1UgM1rqL9mFtH4PHF8TgvAaceymaKmhmP         LTC : LgCGw2WrRphr94RYS1qXHj2PUuYrTap4vk
FC : 6jc9PEmqxpMSxydfepHtshE4f2jMom1dAJ
eleuthria
Legendary
*
Offline Offline

Activity: 1750


BTC Guild Owner


View Profile WWW
June 04, 2011, 06:26:23 PM
 #773

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

R.I.P. BTC Guild, 2011 - 2015.
BTC Guild Forum Thread
The Koolio
Hero Member
*****
Offline Offline

Activity: 560


Minds are like parachutes they work best when open


View Profile WWW
June 04, 2011, 06:38:09 PM
 #774

I hate these long as rounds! 4 hours Shocked

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.

1. Litecoin 2. Bitcoin 3. Any of the Anon coins
dingus
Full Member
***
Offline Offline

Activity: 126



View Profile
June 04, 2011, 06:40:40 PM
 #775

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

ding·us/ˈdiNGgəs/
Noun: Used to refer to something whose name the speaker cannot remember, is unsure of, or is humorously or euphemistically omitting
eleuthria
Legendary
*
Offline Offline

Activity: 1750


BTC Guild Owner


View Profile WWW
June 04, 2011, 07:10:00 PM
 #776

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.

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

Activity: 98



View Profile
June 04, 2011, 07:14:54 PM
 #777

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.

Quote
-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:
Quote
MachineCardPhoenix Options
Main Workstation - Win7 x64 Pro - Aero onRadeon 6970VECTORS BFI_INT FASTLOOP=true WORKSIZE=128 AGGRESSION=9 -a 8 -k poclbm
Dedicated Miner 1 - Win 7 x64 HomePrem - Aero offRadeon 5850DEVICE=0 VECTORS BFI_INT WORKSIZE=128 FASTLOOP=false AGGRESSION=12 -a 8 -k phatk
Dedicated Miner 2 - Vista 7 x64 Ultimate - Aero offRadeon 5850DEVICE=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 Smiley.  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. Smiley

So, I hope this may help some fellow miners out there and BTC Guild thread readers get the first heads up I guess Smiley  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.



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

Activity: 126



View Profile
June 04, 2011, 07:15:05 PM
 #778

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.

ding·us/ˈdiNGgəs/
Noun: Used to refer to something whose name the speaker cannot remember, is unsure of, or is humorously or euphemistically omitting
Veldy
Member
**
Offline Offline

Activity: 98



View Profile
June 04, 2011, 07:19:10 PM
 #779

I hate these long as rounds! 4 hours Shocked

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.

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

Activity: 84



View Profile
June 04, 2011, 07:50:49 PM
 #780

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

If you've found my post helpful, send me some bitcoins!
1FkGxXmesGbhoFewYGrtNEmifzwvNaNCXH
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 88 89 ... 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!