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

eleuthria

http://forum.bitcoin.org/index.php?topic=24448.0 - do you know about this?

are you servers protected against botnet account/mining?

Uhm ... your rewards already have the donations taken out.

(0.00102531 + 0.00002629) * 0.025 = 0.00002629 ... magic, it is the donation

(0.02543637 + 0.99359215) * 0.025 = 0.02547571125 ... magic, very very close to the donation and the result of rounding to 8 decimal places summed up over all your earnings ... in your favor I might add

Did I miss something? BTC Guild is deducting more than my set donation amount.

Donation is set to 2.5%

Estimated Rewards    0.00102531       Estimated reward from current round.
Estimated Donation    0.00002629    

2.564%

Donations Given    0.02543637    
Confirmed Rewards    0.99359215

2.56%

I'll monitor this thread closely and see how things play out.  I really want to land on BTC Guild as home.

I haven't been able to mine on any BTC Guild server for any length of time before I am alerted to GPU utilization cycling and find idle messages in phoenix.  When I watch the output of phoenix for a bit, I see failure to connect to RPC server [or similar] for a second or two or three+ and then work comes down and away it goes [but the network connection text does not remain displayed in the shell due to escape characters output by phoenix which remove it ... piping output to a file will clearly show it].  I see the problem and I connect to another .. USCentral, USEast, NL2, ... and it happens with them all within a short period of time it happens again [usually within an hour regardless of the server and whether it is in Europe or North America, often enough that I rarely miss it and leave it connected while away]. When it starts, it almost always is not just a one time blip, it happens not once, but many times and for quite some time (enough that I can sit and watch it looking for a pattern, checking connections via ping, traceroute and other tools and closely observer the miner output).  Graphs look terrible for the GPUs.  Phoenix tends to lock up after awhile of this happening [well, it usually responds to Ctrl-C and politely says "bye", but it will look like it is mining at 0MH/s ... not obvious at a glance, but the GPU graphs are a dead give away.  This miner halt is probably a fault in the miner software triggered by the conditions described, although I have had it happen with poclbm before too (it just shows an exception and stops, but doesn't close .. usually long polling parsing or communication loss during long poll).  When things are good, no matter which server I mine, my stales are high [for me], on all miners I usually exceed 1% sometimes 1.5% even after a couple thousand shares [still a small sample, I know].  I am using deepbit currently and running for some time now, every miner is between 6000 to 7350 shares and the stale rates are low, 0.27% for my 6970 (stock with core clock pushed to 930MHz) and between 0.50%-0.63% with my 5850s (each pushed slightly differently with the core clock and all at 700MHz for the memory clock). This is using Phoenix 1.50 (with the kernel patch to phatk and poclbm, but using phatk with all cards now).  So, that is three to five times more stales with any BTC Guild server.   Is this because it is push pool?  I am probably getting a slightly lower hash rate with my 6970 since it is faster [so processes it's work queue more quickly so is less likely to get caught with finished work which will be sent regardless of a long poll presumably because there is always a chance it might be accepted and the work was done ... why not send it] and perhaps also because the aggression is a little lower (9 instead of 12 for the dedicated miners) and fastloop is on [which adds about 5MH/s actually] ... this on a machine that is continuously used for other things while mining is going on.

I keep popping back over and testing the waters in the pool, but it rarely lasts long before I decide to leave for a bit and watch here and wait.  Obviously not everybody is having this [or if they are, perhaps are not noticing it], which is good, but it is clearly pool related; whether network [don't think so in most cases], over loaded server [likely the case in many cases] or the software used [the most likely of all cases].  I will keep on testing and I suspect, eventually land here [unless difficulty gets high enough that I end mining before then as my hardware build out is finished].

I've got a good idea of the problem.  There will be a quick restart on US Central (~0.5 seconds) in the next few hours to run a potential fix.

I switched to US East and now am not having as much trouble so I think there is something hinky going on with US Central.

Still getting a lot of disconnects and miner idle warnings on US Central. 

Yes.  It should be delivered today or tomorrow if its on time.  But that still means that we are 2-3 weeks away from it being deployed live.

Are you still going to have that one new US server delivered, setup, and mailed out to a colocation facility?

The patched bitcoind did not contain a special command that I added to the old bitcoind (listgenerations rather than listtransactions).  This meant when US West solved a round, the pool couldn't match it to a block, so it just kept going with a new round, causing a backlog of a few blocks.  The way the pools synchronize the rounds means that it simply shifted the order of the block finds around.

I'm preparing to consolidate some of our servers this weekend.  EU (DE) is our strongest server by far, and was able to handle 1 TH/sec with the current bitcoind patch before it began having idle miner errors.  I have ordered a second server with the same specs which will come online tonight or tomorrow.  It will replace NL1 and NL2.  DNS records will be swapped over a few hours in advance so the vast majority of miners should never notice the switch.

I'm trying to locate a carbon copy of the specs (or as close as I can get) in the US to do a similar consolidation.

Why does it look like we are solving blocks out of order?

Hello,

i get negative Shares (Stales) at the moment:
-188 (-1)

update: working fine again, thx

Yeah, I mine on USEast and have been having a ton of problems this morning.

Been having tons of problems this morning, raning from API timeouts to idle minders etc. But it seems to refresh itself at certain times.

Eleuthera will fix it when he wakes up, he sleeps little enough as it is

Eleuthria that is... sorry hehehe

Do you have an ETA? The average response time rose to 21 seconds for an API query.

i get a ton of miner idles...
when mining other pools, this is not the case.
i'm using phoenix1.5


anyone with the same problem?

I don't think its better. It's worse for me now. (us central)

Getting a lot of "Upstream RPC errors" and "Warning: work queue empty, miner is idle" error messages.

Also my workers (using phoenix) used to be steady 402-404 Mhash now all of them are fluctuating and dipping to around 393 Mhash then going back up to the 400 range.

My network connection is fine. I use a monitoring service and my packet loss history looks fine.

WTF is going on?

Not sure if it's because the upgrade, but I think my speeds are better now, for no other obvious reason (except maybe random fluxuation).


EDIT: was likely just standard variance.

Each new name sucks equity and quality out of the crumbling baby bell.  Somehow, this has something to do with bitcoins   Oh yes, every one of them is worth more than QWest ... and CenturyLink :p 

Soon to be CenturyLink.