Topic: [~1000 GH/sec] BTC Guild - 0% Fee Pool, LP, SSL, Full Precision, and More - page 120. (Read 379078 times)

Note that your block 297 is stuck processing

server reset?

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

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

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

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

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

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?

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.

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

Take out the -q 3 on phoenix

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

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

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

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

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.

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

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.


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:

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.

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