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

isn't time to sacrifice a goat or something...

nice --  3337687  shares and still no block

look what i did overnight lol

   Blocks Found       1

GO POOL!

This has been solved. Apparently, the answer was not to upgrade but to downgrade my miner. I was on either phoenix revision 111 or 112.


I reverted to 110 as well and so far have not seen disconnects for an hour.

thank you for the update, Eleutheria.

and to the rest: we sit here and argue and then the pool op says, yep, there were botnets and i am fixing it.

for those of you who are so quick to judge ~ remember that there may be problems that manifest faster for some people because of differential network effects from different routing architectures between BTCGuild servers and wherever we happen to be.

Problems communicating with bitcoin RPC 0 2 isn't going to cause you much harm unless it ends up happening just before a long poll causing a stale.  It simply means poclbm tried to talk to the server and it didn't get a proper response, and tries again shortly after.  poclbm grabs work in advance, so you're still hashing away until the idle shows up (meaning it couldn't get new work in advance and eventually ran out).


I just re-routed a couple new botnets that showed up on both US Central and US East which were adding about 15,000 long poll connections worth of overhead/stress per server, so the comm errors should start to go away.  I'm also getting ready to re-implement my inefficient miner auto-ban for miners that are requesting tons of work but sending back only a tiny amount of shares.

In the eight hours or so since my previous post on this, I've gotten about 14 comms problem errors with BTCG, doesn't seem related to LP since only in one instance did any LP msg occur within 30 sec of the problem.



In comparison, during the same time frame, on my other pool, running the same settings except the backup and card of course.

Occurred at the same time so it's probably related. Didn't happen near the BTCG error times so it eliminates potential Internet problems on my side.

p.s. using guiminer & poclbm

p.p.s. I suppose I should be glad I'm not getting idle warnings, but I'm wondering if that would lead to rejected shares or stales.

I'm constantly getting idle's and "problem communicating with bitcoin RPC" errors. My network and computer setup is perfect, I know this for a fact. Also, when I switch to DeepBit I never have these issues.

Sorry BTC Guild, but it looks like we're parting ways for now. I'd rather pay 3% and not have to worry about if my miners are actually active or not. (or if your servers are actually up)

You do know everyone get idleminers ?

I get them on every single pool, Im not sure how often you get them but I also get them due to longpolls ~3times an hour, no matter which pool I mine at.

If you get these miner idles for every single longpoll which would be about every 8mins, there is probably something else going on.

No. It was quite clear what he said. He said, "all I can say is go elsewhere". I had stated that all BTC Guild servers were tried in my earlier posts.

Anyway, I tried the new 2.1 Phatk kernel tonight (via Phoenix) and still get the idles.

05:56:22 on miner BC2-0 LP: New work pushed.
05:56:22 on miner BC2-1 LP: New work pushed.
05:56:22 on miner BC2-2 LP: New work pushed.
05:56:22 on miner BC2-3 LP: New work pushed.
05:56:32 on miner BC2-0 LP: Warning: Work queue empty, miner is idle.
05:56:32 on miner BC2-1 LP: Warning: Work queue empty, miner is idle.

BC2-2 and BC 2-3 did not show a miner idle message.

I get the warnings 10 seconds after the LP.

Hopefully this will help someone figure it out.

Switched back over to Deepbit and no more errors. FML

Here is an exact quote of his post (Eleuthria - 2 pages back):

sharky:  All I can say is it's nothing I can do to fix it.  When idles do pop up, its because pushpool/bitcoind are generating a ton of work after an LP.  Normally an idle only shows up when two blocks are found rapidly on the network, and two long polls go out less than a minute apart.  Even in those cases, they normally don't show up.  Like I said, I have 4 miners split 2 per server, and have not had one idle today.

If you're getting them regularly, all I can say is go elsewhere.  I can't fix a problem that seems to be only be affecting you.  If the problem was with our servers at least 1/8th the users would be experiencing it, since the pools are roughly split up to be 1/8th the total load per internal server.

Sharky Im not sure what the issue is but maybe Eleuthria can figure it out. I must note eleuthria mean you should go mine at another pool, he meant you should try a different server on btcguild to see if it sorts out the idle issues.

I'm glad to see more people bring up the idles. I posted on this a few days ago and was basically told it was on my end despite using the exact same mining software/arguments on another pool and not getting the idles on the other pool.

Maybe now that it is getting more attention something will be done about it, or at least an investigation as to why it is happening.

What I noticed was that the idle messages came immediately after a Long Poll message.

Maybe it is a Guiminer ==> Phoenix ==> Phatk issue with BTC Guild only? I don't seem to see anyone using Poclbm having this issue on BTC Guild.

(Edit: Hmm. Looks like it is not Guiminer. I saw a post above that looks like it was run from cmd line. So maybe a Phoenix Phatk issue with BTC Guild)

I'm really bummed about it because I want to use BTC Guild. The pool op said the problem was on my end and suggested I mine elsewhere. I was even donating 2.5%.  

I just checked my logs as a result of the posts talking about idling/disconnects and realize I am having similar problems. I know that I've gotten slightly below expected returns on BTCG but chalked that up to my donation and the wild luck swings. I guess I don't refresh the stats page enough to see the problem.

Seems like I get  "Problems communicating with bitcoin RPC 0 2" at least 2~3 times an hour. Since I run workers on different pools, it is quite obvious it's not my internet connection acting up, there other pool doesn't have a single communication error in the 12 hours or so of log that I scanned through.

I've switched the BTCG server I'm using and going to see if that makes a difference.

It seems that the part you are interested in is the -q (queue) size. You setted it to 3 now ... try to increase it but keep in mind that the pool server will check if the result the miner submitted is actually a result of a work requested by that miner. I think is better to ask the pool owner how many requests the server records per miner. (If the server checks only at the last getwork request the -q configuration is useless).


Try to use some software to monitor the health of your card and some software to monitor the http traffic miners do.

BTW, another interesting thing is that weird network behavior with the mining server correlates well with freezes of the card (it is a 5830). IE long periods at Zero increase the likelihood that the card will freeze the OS. 

so what would you suggest, other than the following (I am using Phoenix 1.50):

${HOMEDIR}/phoenix-1.50/phoenix.py -u http://${MINERUSER}:${MINERPASS}@${$MINERSERV} -q 3 -k phatk VECTORS BFI_INT AGGRESSION=12 WORKSIZE=128 DEVICE=${1}

where $MINERSERV is either uswest or uscentral.

Both miners on Xubuntu boxen, one is catalyst 11.5, the other is 11.6; both use APP SDK 2.4. (that shouldn't affect the behavior that is occurring today with BTCGuild)

NVM ... Just looked at poolpush server code ... it seems that you can't buffer requests (will fail the submission of the result).

If they are NAT'ed ... you DON'T need a proxy!

That usually means connection problem (big latency).
Looking to your signature (2 workers = 600+Mhs) make me think you have 2 powerful miners ... so you need o good network latency or configure better your miners (try to get more work doing more getwork requests and buffer them).

Ciao

I switched one of my miners to uscentral, and shares are being accepted again -- the reason my shares dropped today was NOT due to difficulty increase, but to the fact that uswest was only accepting shares from one of my miners regularly (they are all NAt'd behind one IP).
Okay, okay, so I need to use a proxy, right? I just have never experienced this kind of drastic timeout with BTC for quite a while.