Bitcoin Forum
December 09, 2016, 12:03:21 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   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 90 ... 159 »
  Print  
Author Topic: [~1000 GH/sec] BTC Guild - 0% Fee Pool, LP, SSL, Full Precision, and More  (Read 359131 times)
eleuthria
Legendary
*
Offline Offline

Activity: 1750


BTC Guild Owner


View Profile WWW
June 04, 2011, 08:36:14 PM
 #781

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

It's a mix of two factors.  Miners which are requesting far too much work and returning almost nothing, and raw speed.  As best I can tell, and best on input from the IRC chat, bitcoind starts to bottleneck getwork requests when dealing with speeds in excess of 500GH.  This makes sense, since pushpool is just a relay (so it wouldn't be bottlenecking), CPU usage, RAM, and I/O are not hitting unreasonable levels (plenty of room left to grow).

I've done my internal testing of sharding workers between two bitcoind instances.  I am now deploying the 2nd bitcoind instance on the server and the new pushpool code.  It will likely go live in the next hour, met with a quick downtime of 30 seconds.  (I'll be blocking all 8332 traffic temporarily to avoid getting DDoS'd out like last time hopefully).

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

Posts: 1481285001

View Profile Personal Message (Offline)

Ignore
1481285001
Reply with quote  #2

1481285001
Report to moderator
Every time a block is mined, a certain amount of BTC (called the subsidy) is created out of thin air and given to the miner. The subsidy halves every four years and will reach 0 in about 130 years.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
russelljohnson
Member
**
Offline Offline

Activity: 84



View Profile
June 04, 2011, 08:45:48 PM
 #782

It's a mix of two factors.  Miners which are requesting far too much work and returning almost nothing, and raw speed.  As best I can tell, and best on input from the IRC chat, bitcoind starts to bottleneck getwork requests when dealing with speeds in excess of 500GH.  This makes sense, since pushpool is just a relay (so it wouldn't be bottlenecking), CPU usage, RAM, and I/O are not hitting unreasonable levels (plenty of room left to grow).

I've done my internal testing of sharding workers between two bitcoind instances.  I am now deploying the 2nd bitcoind instance on the server and the new pushpool code.  It will likely go live in the next hour, met with a quick downtime of 30 seconds.  (I'll be blocking all 8332 traffic temporarily to avoid getting DDoS'd out like last time hopefully).

Sweet. Keep us updated. Anything we need to do on our end?

If you've found my post helpful, send me some bitcoins!
1FkGxXmesGbhoFewYGrtNEmifzwvNaNCXH
Slasklitta
Jr. Member
*
Offline Offline

Activity: 53



View Profile WWW
June 04, 2011, 08:54:49 PM
 #783

I sometimes get 4 rejected shares in a row. Why is this? Haven't experienced this on any other pool

Mining at https://www.bitcoins.lc/ @ ~1,2GHash/s
Veldy
Member
**
Offline Offline

Activity: 98



View Profile
June 04, 2011, 08:57:20 PM
 #784

It's a mix of two factors.  Miners which are requesting far too much work and returning almost nothing, and raw speed.  As best I can tell, and best on input from the IRC chat, bitcoind starts to bottleneck getwork requests when dealing with speeds in excess of 500GH.  This makes sense, since pushpool is just a relay (so it wouldn't be bottlenecking), CPU usage, RAM, and I/O are not hitting unreasonable levels (plenty of room left to grow).

I've done my internal testing of sharding workers between two bitcoind instances.  I am now deploying the 2nd bitcoind instance on the server and the new pushpool code.  It will likely go live in the next hour, met with a quick downtime of 30 seconds.  (I'll be blocking all 8332 traffic temporarily to avoid getting DDoS'd out like last time hopefully).

Sweet. Keep us updated. Anything we need to do on our end?

Take out the -q 3 on phoenix Smiley


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, 09:07:31 PM
 #785

I sometimes get 4 rejected shares in a row. Why is this? Haven't experienced this on any other pool

Are you using Phoenix?  In any event, I have noticed that at times [on any pool, but definitely those that are close to their limit of keeping up], I will get a reject before the long polling message and one or two more right after (I guess I stare at the console a little too much :S).  I suspect new work is online at the pool BEFORE the long polling message makes it to clients and if the remaining work is small the miner may continue working on it and submit it until it has fresh work to do [why not, there is always a chance you might be paid for it].  I am not positive, but I think, at least in part, that Phoenix's higher stale rate may be due to it deciding to send what is likely a stale share since it hadn't yet received new work, but had received the long polling push and requested new work and there is no down side to sending it without fresh work to do.  I am guessing though; I haven't looked through the code (I am a C, C++, C# guy personally) and don't know Python.  I also have not asked in the Phoenix thread about this, but I probably should.  It just makes some sense to me that after a long poll push a miner would continue to work on stale work and even submit it until the fresh work arrives [which usually is fast enough to halt and dump the old work, but not always].

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, 09:39:24 PM
 #786

First phase of the update is complete.  There was a -very- short restart of pushpool (~3 seconds).  It is now partitioning work between two instances of bitcoind.  Currently all work is going to the main instance, I will be starting to move larger workers to the second instance shortly.  This will likely cause a few rejects if your worker gets moved between instances, since you will return a unit (or 2) of work to the new instance, but the work came from the old one.

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, 10:03:33 PM
 #787

may have been asked before, but will two instances of pheonix help with rejeced shares and disconnections? I have two running now, neither disconnect at the same time, both are pulling 220 hash.  Good for my mining or not?

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

Activity: 98



View Profile
June 04, 2011, 10:05:27 PM
 #788

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.

Well, I had such high hopes [even though I knew it was unlikely to amount to anything].  -a does not have any effect on mining that I was able to see.  Sorry for the long post that lead to ... nothing Sad

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

Activity: 224


View Profile
June 04, 2011, 10:12:04 PM
 #789

Don't know why, but still getting a lot of idles. They last like 10 seconds each, but they come up at least 3 times everyone minute on every miner. This has been happening for the last day now...

Now getting unable to connect with rpc thing too...

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

Activity: 98



View Profile
June 04, 2011, 10:16:30 PM
 #790

may have been asked before, but will two instances of pheonix help with rejeced shares and disconnections? I have two running now, neither disconnect at the same time, both are pulling 220 hash.  Good for my mining or not?

Are they working with the GPU?  I have done that accidentally before and did notice that the rates between the miners were roughly equal, but I killed it immediately.  It would be very interesting to hear what your results are however.  One thing that I would do is create another worker on the pool and assign one to each miner.  Many pool operators suggest one worker per miner instance period, while others indicate you can have several miners per worker (can only work with long polling or you would likely double your stale rate at the very least).  I have a hunch it would be more efficient to have one worker per miner.  Either way, it will allow you to see stats online and determine the effect as opposed to a single miner.  If they are even remotely close in performance, then you may have to run for several days know for sure [problem is that difficulty is going to jump perhaps in the next 46 hours at the current rate].

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

Activity: 560


Minds are like parachutes they work best when open


View Profile WWW
June 04, 2011, 10:25:20 PM
 #791

may have been asked before, but will two instances of pheonix help with rejeced shares and disconnections? I have two running now, neither disconnect at the same time, both are pulling 220 hash.  Good for my mining or not?

Are they working with the GPU?  I have done that accidentally before and did notice that the rates between the miners were roughly equal, but I killed it immediately.  It would be very interesting to hear what your results are however.  One thing that I would do is create another worker on the pool and assign one to each miner.  Many pool operators suggest one worker per miner instance period, while others indicate you can have several miners per worker (can only work with long polling or you would likely double your stale rate at the very least).  I have a hunch it would be more efficient to have one worker per miner.  Either way, it will allow you to see stats online and determine the effect as opposed to a single miner.  If they are even remotely close in performance, then you may have to run for several days know for sure [problem is that difficulty is going to jump perhaps in the next 46 hours at the current rate].

Ill try that out right away. I have a more powerful rig due next week so dont mind testing the theory

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

Activity: 224


View Profile
June 04, 2011, 11:43:16 PM
 #792

ARGGH why am I the only one that is getting this many idles... (I think?)
Had to switch to deepbit again.

It's better to be pissed off, than to be pissed on.
BTC : 1UgM1rqL9mFtH4PHF8TgvAaceymaKmhmP         LTC : LgCGw2WrRphr94RYS1qXHj2PUuYrTap4vk
FC : 6jc9PEmqxpMSxydfepHtshE4f2jMom1dAJ
The Koolio
Hero Member
*****
Offline Offline

Activity: 560


Minds are like parachutes they work best when open


View Profile WWW
June 04, 2011, 11:49:57 PM
 #793

My two miner test failed lol. Either the servers are playing up or my computer is messed. I got almost 10% stales... no point keeping them both running, ill just have to bite the bullet when it comes to idle time

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

Activity: 84



View Profile
June 04, 2011, 11:56:04 PM
 #794

server reset?

If you've found my post helpful, send me some bitcoins!
1FkGxXmesGbhoFewYGrtNEmifzwvNaNCXH
NetTecture
Full Member
***
Offline Offline

Activity: 140


View Profile
June 04, 2011, 11:59:42 PM
 #795

Note that your block 297 is stuck processing Wink
eleuthria
Legendary
*
Offline Offline

Activity: 1750


BTC Guild Owner


View Profile WWW
June 05, 2011, 12:00:55 AM
 #796

It may be too early to call the issue resolved...but it may be.  ArtForz noticed a limit on the connections backlog for being accepted in pushpool set to 100.  The server sometimes get hammered FAR faster than it can process 100 connections, and those connections were simply timing out (thus causing idles).  This explains why the idles were often centered around LP attempts.

This has been corrected, and after a brief (5 minutes) of the server locking up, it seems to be back on track.

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

Activity: 84



View Profile
June 05, 2011, 02:48:55 AM
 #797

Eleuthria, are you still working on the connection issues?

Still picking up idle messages from poclbm

If you've found my post helpful, send me some bitcoins!
1FkGxXmesGbhoFewYGrtNEmifzwvNaNCXH
The Koolio
Hero Member
*****
Offline Offline

Activity: 560


Minds are like parachutes they work best when open


View Profile WWW
June 05, 2011, 02:55:11 AM
 #798

Eleuthria, are you still working on the connection issues?

Still picking up idle messages from poclbm

I have a few too, but this time its once every 10 mins... Im fine with that

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

Activity: 98



View Profile
June 05, 2011, 03:05:17 AM
 #799

Eleuthria, are you still working on the connection issues?

Still picking up idle messages from poclbm

I have a few too, but this time its once every 10 mins... Im fine with that

I'm not,  That allows your GPU to go from 100% utilized to 0-1% utilized for a small period of time, however, that small period of time will cause significant temperature drops and then it will heat back up again when the connection is restored and work streams in.  The effect is fatigue wear and tear on your hardware that you do not want to be putting it through if you want it to last.  Constant load is FAR better than cycling.

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 05, 2011, 04:50:50 AM
 #800

Both the frequency and severity of the idles had decreased significantly over the last hour, but they are still poking around once in a while.  At 650 GH/sec+, it's becoming quite obvious that a single server is not only a liability, but a handicap.

I'm now working on setting up another server, and tying the two together so that stats, login credentials, and block allocations are properly split between them.  This one will probably still be in the US, but I'll be looking for one on the east coast to compliment our current Los Angeles server.  Once setup, I will include instructions on the website for pointing your miners towards the closer server if you are inclined to do so.

R.I.P. BTC Guild, 2011 - 2015.
BTC Guild Forum Thread
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 90 ... 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!