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

[eleuthria]

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

[1714028969]

1714028969

[1714028969]

1714028969

[1714028969]

1714028969

[russelljohnson]

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?

[Slasklitta]

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

[Veldy]

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

[Veldy]

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

[eleuthria]

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.

[The Koolio]

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?

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

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

[IlbiStarz]

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

[Veldy]

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

[The Koolio]

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

[IlbiStarz]

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

[The Koolio]

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

[russelljohnson]

server reset?

[NetTecture]

Note that your block 297 is stuck processing

[eleuthria]

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.

[russelljohnson]

Eleuthria, are you still working on the connection issues?

Still picking up idle messages from poclbm

[The Koolio]

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

[Veldy]

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.

[eleuthria]

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.