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

[organofcorti]

Are we talking about the same thing? The SMPPS buffer? Which can be negative, and unless you're using a different definition of 'balance' is as likely to be negative as positive?

Yes, and as the creator of SMPPS, I know that the buffer in fact cannot be negative by definition... Either there are funds in it, or not. There can't be anti-funds in the pool's wallet any more than there can be anti-funds in your own.

OK then. How much does the pool owe its miners then, and what do you call that?

[Luke-Jr]

I'm surprised I'm the only one who wants to know, but what caused the charts to mess up yesterday?

Due to a minor glitch in the code I use to do manual payouts (sendmany), some addresses were over-paid. The safeguards in place in the coinbaser code kicked in and complained that those addresses' balances were taken negative, and refused to run. To get the coinbaser running again, I had to make a temporary copy of the database, and run it without that safeguard in place, updating the cache beyond the point where they were taken negative. However, when doing so, the updates created the JSON block statistics in the copied directory. Since this was missing, Artefact2's web graphs were missing the "total ever paid" information, and put the estimates at the zero-level instead. I moved the relevant file, so it now is drawing current data correctly, but unfortunately there is no easy way to modify the historical record it keeps. After that ~hour falls off the left side of the history, it should return completely to normal.

How much does the pool owe its miners then, and what do you call that?

The payout queue can be viewed at http://eligius.st/~twmz/

[Vbs]

If 1 bitcent and 1 anti-bitcent are destroyed in mutual annihilation how much energy is produced?

That's how MintChipCents are produced! Just add blood, sweat and tears to create even more!

[organofcorti]

How much does the pool owe its miners then, and what do you call that?

The payout queue can be viewed at http://eligius.st/~twmz/

Thank you, Luke-jr.

[gr0bi42]

Hi Luke-Jr,

something is wrong with the stats at Eligius. Since Apr 2 it's completely wired.

Also the "submitted shares" count looks wrong. Does Eligius loose shares, or it's just a problem with the stats?

Everything looks fine to me...

Hi,

once again. Still having problems with Eligius pool.

If I jump in (with 5GH) stats are not going up. Not after 15min, 30min... The 15min stat remains 0 or at maximux 50MH with 10 or 20 shares submitted.

Therefore I started mining with a new bitcoin address. I've submitted around 1000 shares. One day later the address is still unknow. The bitcoin address is correct. Just send 0.01 BTC to it from another PPS pool.

So whats going on... for me nothing looks fine.

Here's the link to Eligius with the new bitcoin address: http://eligius.st/~artefact2/7/1P7jUfXUEgk4oqXXxsQ2RAJsa9uBp1ChSA

[Luke-Jr]

Hi Luke-Jr,

something is wrong with the stats at Eligius. Since Apr 2 it's completely wired.

Also the "submitted shares" count looks wrong. Does Eligius loose shares, or it's just a problem with the stats?

Everything looks fine to me...

Hi,

once again. Still having problems with Eligius pool.

If I jump in (with 5GH) stats are not going up. Not after 15min, 30min... The 15min stat remains 0 or at maximux 50MH with 10 or 20 shares submitted.

Therefore I started mining with a new bitcoin address. I've submitted around 1000 shares. One day later the address is still unknow. The bitcoin address is correct. Just send 0.01 BTC to it from another PPS pool.

So whats going on... for me nothing looks fine.

Here's the link to Eligius with the new bitcoin address: http://eligius.st/~artefact2/7/1P7jUfXUEgk4oqXXxsQ2RAJsa9uBp1ChSA

You (or your miner) are sending it lowercase'd. Bitcoin addresses are case-sensitive, so the all-lowercase variant is invalid.

[gr0bi42]

Hi Luke-Jr,

something is wrong with the stats at Eligius. Since Apr 2 it's completely wired.

Also the "submitted shares" count looks wrong. Does Eligius loose shares, or it's just a problem with the stats?

Everything looks fine to me...

Hi,

once again. Still having problems with Eligius pool.

If I jump in (with 5GH) stats are not going up. Not after 15min, 30min... The 15min stat remains 0 or at maximux 50MH with 10 or 20 shares submitted.

Therefore I started mining with a new bitcoin address. I've submitted around 1000 shares. One day later the address is still unknow. The bitcoin address is correct. Just send 0.01 BTC to it from another PPS pool.

So whats going on... for me nothing looks fine.

Here's the link to Eligius with the new bitcoin address: http://eligius.st/~artefact2/7/1P7jUfXUEgk4oqXXxsQ2RAJsa9uBp1ChSA

You (or your miner) are sending it lowercase'd. Bitcoin addresses are case-sensitive, so the all-lowercase variant is invalid.

Fixed and working Thanks a lot.

[John (John K.)]

Pool down?

Status   Address   Latency   Uptime (API)
Network problem (timeout, unreachable)   ra.mining.eligius.st:8337   N/A   Downtime : 8 minutes

[Luke-Jr]

Eloipool locked up while I was AFK and nobody bothered to call - I guess with continuous uptime for 2 months we all just assumed it was stable

What happened in detail was, epoll returned that a socket was writable, but then actually trying to write to it blocked. This was a (miner-side) getmemorypool request, so I'm guessing maybe Python blocks until all the data is written, rather than just trying a single send(). To fix it, I set all the connection sockets to non-blocking, so they should never block under any circumstances.

While I was in that code, I also added an attempt to write immediately when Eloipool decides to send data (rather than waiting to check if the socket is readable). There's a chance this may improve longpoll response times slightly.

[John (John K.)]

Eloipool locked up while I was AFK and nobody bothered to call - I guess with continuous uptime for 2 months we all just assumed it was stable

What happened in detail was, epoll returned that a socket was writable, but then actually trying to write to it blocked. This was a (miner-side) getmemorypool request, so I'm guessing maybe Python blocks until all the data is written, rather than just trying a single send(). To fix it, I set all the connection sockets to non-blocking, so they should never block under any circumstances.

While I was in that code, I also added an attempt to write immediately when Eloipool decides to send data (rather than waiting to check if the socket is readable). There's a chance this may improve longpoll response times slightly.

My stales were slightly higher after the patch (0.6~ - 1.41~) though. I'm not sure if it's related to this but it occurred after the patch.

[gr0bi42]

@Luke-Jr

I see very high reject-rates with my ztex board on your pool.

Ztex-Quad (BTCMiner or cgminer): 4.53%
GPU (cgminer): 1.8%

To compare:

Deepbit:
Ztex-Quad: 0.18%
GPU: 0.21%

ABCPool:
Ztex-Quad: 0.22%
GPU: 0.29%

Any idea why?

[Luke-Jr]

@Luke-Jr

I see very high reject-rates with my ztex board on your pool.

Ztex-Quad (BTCMiner or cgminer): 4.53%
GPU (cgminer): 1.8%

To compare:

Deepbit:
Ztex-Quad: 0.18%
GPU: 0.21%

ABCPool:
Ztex-Quad: 0.22%
GPU: 0.29%

Any idea why?

What address?

[gr0bi42]

@Luke-Jr

I see very high reject-rates with my ztex board on your pool.

Ztex-Quad (BTCMiner or cgminer): 4.53%
GPU (cgminer): 1.8%

To compare:

Deepbit:
Ztex-Quad: 0.18%
GPU: 0.21%

ABCPool:
Ztex-Quad: 0.22%
GPU: 0.29%

Any idea why?

What address?

Send you a pm.

[Luke-Jr]

@Luke-Jr

I see very high reject-rates with my ztex board on your pool.

Ztex-Quad (BTCMiner or cgminer): 4.53%
GPU (cgminer): 1.8%

To compare:

Deepbit:
Ztex-Quad: 0.18%
GPU: 0.21%

ABCPool:
Ztex-Quad: 0.22%
GPU: 0.29%

Any idea why?

Looks like you're doing some kind of weird hopping. That might be related (in the sense that you may be spending more time mining Eligius when stales are more likely). You've also got a lot of duplicate shares. That's a bug in your miner software or FPGAs.

[John (John K.)]

Eloipool locked up while I was AFK and nobody bothered to call - I guess with continuous uptime for 2 months we all just assumed it was stable

What happened in detail was, epoll returned that a socket was writable, but then actually trying to write to it blocked. This was a (miner-side) getmemorypool request, so I'm guessing maybe Python blocks until all the data is written, rather than just trying a single send(). To fix it, I set all the connection sockets to non-blocking, so they should never block under any circumstances.

While I was in that code, I also added an attempt to write immediately when Eloipool decides to send data (rather than waiting to check if the socket is readable). There's a chance this may improve longpoll response times slightly.

My stales were slightly higher after the patch (0.6~ - 1.41~) though. I'm not sure if it's related to this but it occurred after the patch.

P.S.: The stales are back to normal (0.6~) lately.

[gr0bi42]

@Luke-Jr

I see very high reject-rates with my ztex board on your pool.

Ztex-Quad (BTCMiner or cgminer): 4.53%
GPU (cgminer): 1.8%

To compare:

Deepbit:
Ztex-Quad: 0.18%
GPU: 0.21%

ABCPool:
Ztex-Quad: 0.22%
GPU: 0.29%

Any idea why?

Looks like you're doing some kind of weird hopping. That might be related (in the sense that you may be spending more time mining Eligius when stales are more likely). You've also got a lot of duplicate shares. That's a bug in your miner software or FPGAs.

Made some further tests:

cgminer version: 2.4.1.
1 cgminer for GPU
1 cgminer for ZTEX

Pools tested: Eligius, ABCPool, pool.itzod.ru (small SMPPS pool).

Eligius: (pointed only the GPU cluster, no weird hopping!) 3 hour average: 7170 shares valid, 4 duplicates, 234 stales = 3.21% invalid shares.
ABCPool: (GPU and ZTEX cluster): 0.19% invalid shares
itzod.ru: (GPU and ZTEX cluster): 0.58% invalid shares

I get the duplicates only with Eligius. I experience around 2.5% invalid shares using Eligius, although I point only the GPU cluster.

Conclusion: it's better to mine on another pool for me. Eliguis is now a backup backup pool. Will check every while if things get better on Eligius.

[Luke-Jr]

@Luke-Jr

I see very high reject-rates with my ztex board on your pool.

Ztex-Quad (BTCMiner or cgminer): 4.53%
GPU (cgminer): 1.8%

To compare:

Deepbit:
Ztex-Quad: 0.18%
GPU: 0.21%

ABCPool:
Ztex-Quad: 0.22%
GPU: 0.29%

Any idea why?

Looks like you're doing some kind of weird hopping. That might be related (in the sense that you may be spending more time mining Eligius when stales are more likely). You've also got a lot of duplicate shares. That's a bug in your miner software or FPGAs.

Made some further tests:

cgminer version: 2.4.1.
1 cgminer for GPU
1 cgminer for ZTEX

Pools tested: Eligius, ABCPool, pool.itzod.ru (small SMPPS pool).

Eligius: (pointed only the GPU cluster, no weird hopping!) 3 hour average: 7170 shares valid, 4 duplicates, 234 stales = 3.21% invalid shares.
ABCPool: (GPU and ZTEX cluster): 0.19% invalid shares
itzod.ru: (GPU and ZTEX cluster): 0.58% invalid shares

I get the duplicates only with Eligius. I experience around 2.5% invalid shares using Eligius, although I point only the GPU cluster.

Conclusion: it's better to mine on another pool for me. Eliguis is now a backup backup pool. Will check every while if things get better on Eligius.

Why didn't you point the ZTEX cluster at Eligius too? Duplicates are a miner bug, so I'm going to have to guess that's a problem with your GPU(s) and/or cgminer's OpenCL driver.

As for the high stales, could you try pinging each of the 3 servers? There's another guy who also gets high stales with the same pings as me, so there's probably something going on, but I haven't been able to figure out what or why it only affects some miners (I consistently get well under 1% stale myself). If anyone with this issue persistent is willing to provide Linux SSH access to me for debugging for a few days (I can keep it mining on your address), I'd be interested in investigating it further...

[-ck]

I get the duplicates only with Eligius.

Duplicates are a miner bug, so I'm going to have to guess that's a problem with your GPU(s) and/or cgminer's OpenCL driver.

That conclusion does not compute.

[Luke-Jr]

On further thought, duplicates might also indicate network issues making cgminer think the first submission failed. It's possible these same network issues could add some unknown amount of latency to other submissions, making them stale. I wonder if the difference is IPv6 vs IPv4? Could you try mining on ipv4.mining.eligius.st, and report how that does? Another thing we could test is DNS timing: try ttltest.eligius.info and ttltest.eligi.us to check that.

[ddd1]

So username is my wallet?

I'm considering mining on this pool with cgminer, seems like the website is down so I'll try later.