bit pit - (LP, ESMPPS, 8-decimal payout, SSL, API, 0% fee, Almost 0% Stales!)

[zoro]

could you add also nest to
"Shares this round:"   
the stale shares?
this could be a promotion
best xPPS pool!

[1713551859]

1713551859

[1713551859]

1713551859

[irosaurus]

I don't think that everything works fine, my actual stale rate is 1,4%. A week ago, I even had a stale rate of nearly 3%! I guess you still have to work on improving the stale rate

cheers iro

[1bitc0inplz]

I don't think that everything works fine, my actual stale rate is 1,4%. A week ago, I even had a stale rate of nearly 3%! I guess you still have to work on improving the stale rate

cheers iro

That is actually far greater than our median stale rate. We'd love to know a little bit more about your particular setup, including your hash rate, geo-locality, and what miner you use.

We'd love to work with you to isolate the particular cause of your high stale rate.

[Stupidpal]

Amazing pool. Keep up the good work!

[lebuen]

I actually also get >5% stales using the latest poclbm by luke-jr, catalyst 11.6, sdk 2.4, ubuntu 11.04.

Code:

pool.bitp.it:8334 24/07/2011 17:00:42, 67d07587, _rejected_                      48 (Eff:6.73)]
pool.bitp.it:8334 24/07/2011 17:00:50, 79461648, _rejected_                      48 (Eff:6.73)]
pool.bitp.it:8334 24/07/2011 17:06:20, e6223209, _rejected_                      53 (Eff:6.57)]
pool.bitp.it:8334 24/07/2011 17:06:22, baf86b5c, _rejected_                      53 (Eff:6.57)]
pool.bitp.it:8334 24/07/2011 17:06:30, 9b851437, _rejected_                      53 (Eff:6.57)]
pool.bitp.it:8334 24/07/2011 17:06:43, e89b8378, _rejected_                      53 (Eff:6.57)]
pool.bitp.it:8334 24/07/2011 17:06:48, abcbd49d, _rejected_                      53 (Eff:6.57)]
pool.bitp.it:8334 24/07/2011 17:06:55, c97f1d85, _rejected_                      53 (Eff:6.57)]
pool.bitp.it:8334 24/07/2011 17:06:55, 7a1160f0, _rejected_
pool.bitp.it:8334 24/07/2011 17:07:08, 331832ab, _rejected_                      53 (Eff:6.57)]
pool.bitp.it:8334 24/07/2011 17:08:10, b15d15dd, _rejected_                      54 (Eff:6.52)]
pool.bitp.it:8334 24/07/2011 17:08:14, f6cf105d, _rejected_                      54 (Eff:6.52)]
pool.bitp.it:8334 24/07/2011 17:08:19, 586a7649, _rejected_                      54 (Eff:6.52)]
pool.bitp.it:8334 24/07/2011 17:08:20, 96eb1868, _rejected_                      54 (Eff:6.52)]
pool.bitp.it:8334 24/07/2011 17:24:13, long poll: IO error                       67 (Eff:6.52)]
pool.bitp.it:8334 24/07/2011 17:24:14, LP connected to pool.bitp.it:8334         67 (Eff:6.52)]
pool.bitp.it:8334 24/07/2011 17:29:32, long poll: new block 0000082b53a84405     71 (Eff:6.49)]
pool.bitp.it:8334 24/07/2011 17:31:36, long poll: new block 00000133afb8a04d     73 (Eff:6.42)]
pool.bitp.it:8334 24/07/2011 17:47:50, 13c9b852, _rejected_                      86 (Eff:6.40)]
pool.bitp.it:8334 24/07/2011 17:52:53, 7b4be65c, _rejected_                      90 (Eff:6.32)]
pool.bitp.it:8334 24/07/2011 17:52:54, d97349df, _rejected_                      90 (Eff:6.32)]
pool.bitp.it:8334 24/07/2011 17:53:01, 26d6fe5c, _rejected_                      90 (Eff:6.32)]
pool.bitp.it:8334 24/07/2011 18:01:41, bdad71cf, _rejected_                      97 (Eff:6.28)]
pool.bitp.it:8334 24/07/2011 18:02:56, a9e1406a, _rejected_                      98 (Eff:6.24)]
pool.bitp.it:8334 24/07/2011 18:03:02, bb5ed498, _rejected_                      98 (Eff:6.24)]
pool.bitp.it:8334 24/07/2011 18:03:05, bb716a04, _rejected_                      98 (Eff:6.24)]
pool.bitp.it:8334 24/07/2011 18:06:31, dd738ad8, _rejected_                      101 (Eff:6.17)]
pool.bitp.it:8334 24/07/2011 18:06:33, 48a73be3, _rejected_                      101 (Eff:6.17)]
pool.bitp.it:8334 24/07/2011 18:06:51, ae570e72, _rejected_                      101 (Eff:6.17)]
pool.bitp.it:8334 24/07/2011 18:11:48, af734db8, _rejected_                      105 (Eff:6.21)]
pool.bitp.it:8334 24/07/2011 18:11:50, bc0b4856, _rejected_                      105 (Eff:6.21)]
pool.bitp.it:8334 24/07/2011 18:14:21, d1c9c700, ERROR (will resend)             107 (Eff:6.13)]
pool.bitp.it:8334 24/07/2011 18:21:59, 1586401f, _rejected_                      113 (Eff:6.13)]
pool.bitp.it:8334 24/07/2011 18:22:01, c3ea8f62, _rejected_                      113 (Eff:6.13)]
pool.bitp.it:8334 24/07/2011 18:22:08, 6c63d1bb, _rejected_                      113 (Eff:6.13)]
pool.bitp.it:8334 24/07/2011 18:31:37, long poll: IO error                       121 (Eff:6.15)]
pool.bitp.it:8334 24/07/2011 18:31:38, LP connected to pool.bitp.it:8334         121 (Eff:6.15)]
pool.bitp.it:8334 24/07/2011 18:35:08, long poll: new block 000004a6b287b636     124 (Eff:6.14)]
pool.bitp.it:8334 [373.537 MH/s (~396 MH/s Eff:6.92)] [Rej: 42/812 (5.17%)] [GW: 125 (Eff:6.16)]

[lowentropy]

I actually also get >5% stales using the latest poclbm by luke-jr, catalyst 11.6, sdk 2.4, ubuntu 11.04.

Yikes! That's not good...
I guess that's what we'll be working on today, then.

[lowentropy]

If any miner or proxy operator out there has a LOT of requests to us from the same IP (like more than 30 per second), or wants to set up such a proxy, please just let us know first so we can work out priority access. Otherwise, our proxy will likely drop your connections. If you suspect this is already happening to you, please PM me or email support with your IP.

[zoro]

what about dynamic IPs?
parhaps you should increase the limit to (lets say) 50?!
i have 25 GPUs with same dynamic IP, i think i am reaching the limit?

[lowentropy]

what about dynamic IPs?
parhaps you should increase the limit to (lets say) 50?!

Thank you for the suggestion, I've done so. Still though: if anyone really needs more than this, we can handle that, you just need to let us know.

[digger]

you pool been added to http://digbtc.com

[lowentropy]

you pool been added to http://digbtc.com

Neat, thanks!

Our name is actually "bitpit", is it possible to change that? No big deal either way.

[digger]

you pool been added to http://digbtc.com

Neat, thanks!

Our name is actually "bitpit", is it possible to change that? No big deal either way.

done!

[zoro]

first block with ESMPPS and "Estimated Reward" never goes to "Unconfirmed Reward"!
also the "buffered" btcs from previous round are not visible!

[1bitc0inplz]

first block with ESMPPS and "Estimated Reward" never goes to "Unconfirmed Reward"!
also the "buffered" btcs from previous round are not visible!

In ESMPPS there will not be a "unconfirmed" status. Once the final Prop block is confirmed, we will actually remove that field. There will just be Estimated and Confirmed. In ESMPPS your balance doesn't move from estimated to confirmed on blocks being found, as we will pay out even on invalid blocks. When the next ESMPPS block is confirmed, and thusly the pool receives income, we will move an appropriate amount of BTC from your estimated reward and instantly move it to confirmed.

Since we just switched over last night, there are obviously things we are still working on exposing. The buffer is one of them.

[zoro]

really nice job my friends! thanks for quick replies!
i will just sit on my "throne"   waiting for all those changes and upgrades  

[Sukrim]

During a discussion with various pool operators we also figured out a somewhat bulletproof way to detect (and ban) withholders, so they won't ruin the party either.

Care/dare to elaborate on this?

My approach would be to send out the winning shares to all or a part of your miners again and either "cheat" (?) them and declare the resulting solution as stale or pay them PPS for that "useless" one. Then ban or monitor closely everyone who did NOT submit an answer to this share, preferrably with a big fat warning in the account overview or even a temp-/permaban. It's probably better to sacrifice some hash rate than risking withholders.

In the long run you (as every *PPS operator) should lobby for oblivious shares though, and maybe even a general overhaul of how mining is done and work is being handed out.

[1bitc0inplz]

We just noticed that after our last prop block was confirmed we appear to have a slight UI bug were estimated rewards are displaying as 0. We are working to correct this issue ASAP. Everyone's estimated rewards is still there in the DB, and being updating appropriately.

We apologize for this display error, and hope everyone understands as we work to resolve this.

[1bitc0inplz]

Ok, everything is back to normal. Sorry to the hiccup.

[lowentropy]

We just noticed that after our last prop block was confirmed we appear to have a slight UI bug were estimated rewards are displaying as 0. We are working to correct this issue ASAP. Everyone's estimated rewards is still there in the DB, and being updating appropriately.

We apologize for this display error, and hope everyone understands as we work to resolve this.

This issue is fixed now, everybody's estimated reward should be displayed correctly now. Sorry about that guys 

[Stupidpal]

The site is giving me a 504 error right now.