[OLD] Eligius: ASIC, no registration, no fee CPPSRB BTC + 105% PPS NMC, 877 #

[Nemesis]

Is the stats page down?

[opentoe]

There are issues. I have a few friends that mine here and all of them are disconnected now. They have temporarily switched to a pool that is up and running until Eligius gets back up. Good luck.

[pluMmet]

bfl miners a running great but my blades on getwork are crawling....

[wizkid057]

bfl miners a running great but my blades on getwork are crawling....

Youre supposed to use a stratum proxy with blades anyway. Using them directly to the pool wastes hashes

[huanix]

Pool seems to have gone down.. ? My computer room got REALLY quiet. Guess I should have set up fall back mining.

[GrapeApe]

Pool seems to have gone down.. ? My computer room got REALLY quiet. Guess I should have set up fall back mining.

Yeah everything is down from stats to mining here as well.

[daddyfatsax]

Pool seems to have gone down.. ? My computer room got REALLY quiet. Guess I should have set up fall back mining.

Yeah everything is down from stats to mining here as well.

Same here. All my workers are on my backup pool.

[wedgy2k]

keep getting stratum connection to pool interrupted

*edit
Stats down now too

Are the Data-centre gremlins resolved or ongoing?

[gadgetgeek]

I've been getting well over 1000x the amount of discards as I do accepted from the pool.  I have disabled it to see if my other two pools that are load balanced will settle out.  This issue has only been happening for the last week or a bit longer.  Before that, everything was rock solid.  Discards would be well below accepted.

Anyone else see the same thing?

Running BFGMiner 3.7.0 with proxy enabled.

[joeventura]

Besides stats not working... anyone else not get paid recently?  My screen says I was to be paid .7 btc... but under last payouts I show No recent data available.

Yes I was expecting a payment yesterday, still there, still accumulating but no payment

[opentoe]

Guys, I just posted over 40 minutes ago the pool is having problems. I have a few friends that love this pool and aren't able to mine here and are using another pool. God only knows why my friends call me and ask if I'm having problems. They all know I don't use this pool. They are all freaking out.

[CeeCee]

yep all down. we should wait for a statement from wizkid and meanwhile just use another pool.

[wizkid057]

Constant downtime.. constant stats issues.. constant delayed payouts..  Might be the time to switch to a pool with fees and avoid all of this.  

Actually pool downtime has been minimal. Stats is another issue.

A "pool with fees" doesnt guarantee anything better.

[GrapeApe]

Constant downtime.. constant stats issues.. constant delayed payouts..  Might be the time to switch to a pool with fees and avoid all of this.  

      All pools experience downtime hell everything in life does now that I think about it but we have very little downtime compared to some of the larger pools. They are constantly being hit with DDOS attacks. I'm here because  this pool has been very reliable and responsive. It doesn't really matter when the stats get frozen, it's actually a fail safe in place to prevent problems from certain outages and attacks. I have had no delayed payouts. You don't get paid as soon as you reach your mark, you are then entered into the payout queue.

Anyway all seems like it's back to normal again (quick turnaround THX!!!) and if you just use failover with a backup pool this really shouldn't be a big issue.

[pluMmet]

Well I've got my Blades on another getwork friendly pool now.

Like I said my BFL stuff is hashing away great with minepeon on Eligius right now... it never stopped.

[wizkid057]

Well I've got my Blades on another getwork friendly pool now.

Like I said my BFL stuff is hashing away great with minepeon on Eligius right now... it never stopped.

I'll just point out again, this time more bluntly, that pointing blades directly at a remote pool is stupid.

First, the blades do not process new work while waiting for responses from the remote host.  This leads to an actual pool-side hash rate decrease (the blades always report the same regardless of accepted/rejected shares).  This is exaggerated when the network or pool is under any real load, leading to more noticeable drops in hash rates.

Second, the blades to not honor work difficulty specifications by the pool.  So, any pool that serves work higher than difficulty 1 will cause you to submit 2x, 4x, 8x, or more shares to the pool than needed and the majority of them will get rejected for not meeting the target.  This puts unnecessary load on the pool.

Third, the blades do not honor the HTTP spec and instead use a broken partially working version that is NOT DESIGNED TO WORK WITH POOLS.  

Fourth, this is said in the documentation for the blades for all of the above reasons.

In short, DO NOT POINT ASICMINER BLADES DIRECTLY AT ANY REMOTE POOL'S GETWORK SERVERS.  Run a stratum proxy on your LAN, point your blades at the proxy and point the proxy at the pool.  Problem solved.  bfgminer also includes a proxy in the linux version now.

-wk

[wizkid057]

Greetings Eligius miners,

First, let me apologize for the stability issues with the pool server today.  This morning during some routine maintenance some core hardware at the data center we are using failed, knocking many systems offline, including the rack containing Eligius.  This hardware was able to be fully replaced within 25 minutes and all services resumed at that time.

The pool's current vardiff setup (starting with diff 2) caused some lag when everyone reconnected (and hadn't yet had their difficulties adjusted upward).  This subsided on its own after about 30 minutes.

A separate issue caused a few hosts used in our load balancing and DNS round robin to experience intermittent network connectivity, enough to auto-remove them from the DNS.  Once there were too few interfaces for inbound connections, the pool was not able to get data fast enough to sustain mining as normal.  This has been corrected and settings adjusted so that it doesn't happen again.

The stats issues are generally due to fail-safe events at inconvenient times.  For example, last night's was less than 20 minutes after I had gone to bed, not noticed until morning.  There are several events that trigger the failsafe events, the majority of which are corrected very easily.  I will be automating the user-intervention portion of some of these soon.

In any case, I am going to be taking the time to overhaul the entire networking setup for Eligius tonight and tomorrow.  That said, you may experience brief connection interruptions as make modifications.  I will try to keep them to a minimum, but some will be unavoidable.

Please make sure you have a fail-over pool configured in bfgminer/cgminer.  If your mining software doesn't support fail-over pools then use software that does or just ride it out.  I personally use Bitminter for fail-over, then solo if Eligius and Bitminter are down.

After these changes/upgrades are done I don't anticipate any further pool connectivity interruptions.

Thank you for mining Eligius!

-wk

[wizkid057]

I'll get a manual payout together this afternoon.

Going to have to push this back to tomorrow morning, got called away again this evening and I'm kind of beat.

[jtoomim]

Hey wizkid057,

Would it be possible to have the stats display per-worker revenue (in BTC, cumulatively)? I would like to be able to use one payment address, but still see at a glance which miners have paid for themselves and which ones have not. I recognize you're too busy to implement it now with the recent chaos. Would it be possible to make this work retroactively so that in a few weeks (when you have time) we can see the earnings that are being made now?

If you do this, I'll dump 50 mBTC into the 1Stats address.

Alternately, if you point me to the relevant section of code, I can try to construct a patch myself.

[Luke-Jr]

Hey wizkid057,

Would it be possible to have the stats display per-worker revenue (in BTC, cumulatively)? I would like to be able to use one payment address, but still see at a glance which miners have paid for themselves and which ones have not. I recognize you're too busy to implement it now with the recent chaos. Would it be possible to make this work retroactively so that in a few weeks (when you have time) we can see the earnings that are being made now?

If you do this, I'll dump 50 mBTC into the 1Stats address.

Alternately, if you point me to the relevant section of code, I can try to construct a patch myself.

Pretty sure what you're asking here is a major overhaul, and balances are not tracker per-worker.