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

[runlinux]

Luke-Jr, you may want to update your first post and remove that generations dont work at Mt Gox.

[blumpkinpie76]

I assume that balances from 3 or Ti are yet to be paid? Just checking. I got both my US and EU balances, so I have faith. If they have been sent, I guess I need to take a second look at my received. Thank you!

Ti is still up on ghost.mining.eligius.st probably until Monday. There's a guy on IRC who has a bunch of supercomputer CPU miners that overloaded EU, and I want him to test on Ti to see how well the new software can handle it before unleashing it on Su. Once it's shutdown and the final block has 120 confirmations, I'll be sending any remaining balances via the usual sendmany.

Received my balance from Ti today. Thank you Luke-jr!

[Luke-Jr]

In addition, the Linux networking stack has been randomly choosing machines it doesn't allow to connect--  we get the SYN packet fine, but Linux silently discards it without passing it to pushpoold.

Turns out this is a known issue when net.ipv4.tcp_tw_recycle and NAT are combined. I have disabled it on the pool server, so it should be resolved now. Much thanks to mobiusl and everyone else who helped troubleshoot!

Also, I shutdown Eligius-Ti (formerly 3) last night, and its final payout went out this morning as a sendmany.

[iopq]

Any idea why the pool has missed its chance to pay me on the last three blocks?

Payouts are processed 50 BTC (+ txn fees) at a time, choosing the addresses which have been waiting the longest first. Since our last 3 blocks were rather long, the pool rewarded over 50 BTC per block, and there's a bit of a backlog. When we get to short blocks, it will catch up again.

should have done PPLNS, and not listened to polls 

[Stupidpal]

I absolutely love the stats page.

[Dargo]

Switched back to Eligius last night, and it has been SOLID! I noticed the stats page is off again, which is a bit of a bummer, but I'm still loving this pool. When the stats are working, it is really nice to be able to check my stats without logging in with my complicated-as-hell passwords.

[Yeti]

Any idea why the pool has missed its chance to pay me on the last three blocks?

Payouts are processed 50 BTC (+ txn fees) at a time, choosing the addresses which have been waiting the longest first. Since our last 3 blocks were rather long, the pool rewarded over 50 BTC per block, and there's a bit of a backlog. When we get to short blocks, it will catch up again.

should have done PPLNS, and not listened to polls  

Why? Seems to work out great now, server funds of over 500 BTC. That should last for a really long dry round of 70 hours!

I was with Eligius from the start of my mining career, only tried out BTC Guild during the instable period, but now I'm back and staying.

[anodyne]

In addition, the Linux networking stack has been randomly choosing machines it doesn't allow to connect--  we get the SYN packet fine, but Linux silently discards it without passing it to pushpoold.

Turns out this is a known issue when net.ipv4.tcp_tw_recycle and NAT are combined. I have disabled it on the pool server, so it should be resolved now. Much thanks to mobiusl and everyone else who helped troubleshoot!

Are the NAT issues something that explains why I had connection problems when I was connected over VPN (which I assume uses NAT rather than giving everyone a unique IP at the exit), or is it just something related to the server/hosting setup?

[Luke-Jr]

In addition, the Linux networking stack has been randomly choosing machines it doesn't allow to connect--  we get the SYN packet fine, but Linux silently discards it without passing it to pushpoold.

Turns out this is a known issue when net.ipv4.tcp_tw_recycle and NAT are combined. I have disabled it on the pool server, so it should be resolved now. Much thanks to mobiusl and everyone else who helped troubleshoot!

Are the NAT issues something that explains why I had connection problems when I was connected over VPN (which I assume uses NAT rather than giving everyone a unique IP at the exit), or is it just something related to the server/hosting setup?

It could be. The problem as I understand it, is that your miners are sending relative-to-an-unknown-value timestamps in the packets, and tcp_tw_recycle ignores ones with timestamps going backward in time (or something like that). So minerA and minerB have different relative-timestamps, but the earlier of the two gets ignored because of the later's packets...

[digger]

your pool is big.

But i can;t find the link of blocks statistics.

[twmz]

your pool is big.

But i can;t find the link of blocks statistics.

http://eligius.st/~artefact2/

[Luke-Jr]

But i can;t find the link of blocks statistics.

http://www.eligius.st/~luke-jr/raw/5/blocks/

[digger]

you pool has been included http://digbtc.com

[coblee]

Artefact2 already has something like it: http://pident.artefact2.com/

[Palmdetroit]

  bored

[DiabloD3]

bored

Palmdetroit, just because those tripleminer idiots put gigantic sig banners up doesn't mean you can. I want to ban them so much.

[anodyne]

In addition, the Linux networking stack has been randomly choosing machines it doesn't allow to connect--  we get the SYN packet fine, but Linux silently discards it without passing it to pushpoold.

Turns out this is a known issue when net.ipv4.tcp_tw_recycle and NAT are combined. I have disabled it on the pool server, so it should be resolved now. Much thanks to mobiusl and everyone else who helped troubleshoot!

Are the NAT issues something that explains why I had connection problems when I was connected over VPN (which I assume uses NAT rather than giving everyone a unique IP at the exit), or is it just something related to the server/hosting setup?

It could be. The problem as I understand it, is that your miners are sending relative-to-an-unknown-value timestamps in the packets, and tcp_tw_recycle ignores ones with timestamps going backward in time (or something like that). So minerA and minerB have different relative-timestamps, but the earlier of the two gets ignored because of the later's packets...

Has been running fine since your first post. It was an intermittent problem, though, so I guess it's still too early to be certain if it's something related or just good luck on my side.

Something else... I noticed to pool just finished a 250BTC round, so how about an addition to the stats pages that mentions that payments may take a few rounds when the pool has a backlog to process?

[Stupidpal]

In addition, the Linux networking stack has been randomly choosing machines it doesn't allow to connect--  we get the SYN packet fine, but Linux silently discards it without passing it to pushpoold.

Turns out this is a known issue when net.ipv4.tcp_tw_recycle and NAT are combined. I have disabled it on the pool server, so it should be resolved now. Much thanks to mobiusl and everyone else who helped troubleshoot!

Are the NAT issues something that explains why I had connection problems when I was connected over VPN (which I assume uses NAT rather than giving everyone a unique IP at the exit), or is it just something related to the server/hosting setup?

It could be. The problem as I understand it, is that your miners are sending relative-to-an-unknown-value timestamps in the packets, and tcp_tw_recycle ignores ones with timestamps going backward in time (or something like that). So minerA and minerB have different relative-timestamps, but the earlier of the two gets ignored because of the later's packets...

Has been running fine since your first post. It was an intermittent problem, though, so I guess it's still too early to be certain if it's something related or just good luck on my side.

Something else... I noticed to pool just finished a 250BTC round, so how about an addition to the stats pages that mentions that payments may take a few rounds when the pool has a backlog to process?

I thought blocks were always 50 BTC chunks.

[Yeti]

I thought blocks were always 50 BTC chunks.

They are. Generation is (right now anyways, until block 210000) 50 BTC plus the transaction fees. However, on long rounds Eligius sends out all the other rewards from its reserve in a sendmany(?) tx. Although I couldn't confirm that for the last block of the 22h round ... How is that done exactly?

[anodyne]

Blocks are 50BTC, but with the PPS system rounds can have higher rewards since the pool pays for the shares with coins it kept after short rounds. But automatic payments are still limited by the 50BTC that fit into generation, so after rounds where the value of shares exceeds that limit the pool has to queue the payments and fit them into future blocks.

The sendmany transactions were only for paying balances from the closed pools, so until there's a solution that takes cares of backlogs in a better way I think it would be appropriate to update the information about payments... at least as a precaution against the kind of people who feel they have to tediously express their opinions when they have to wait for something...