[~1000 GH/sec] BTC Guild - 0% Fee Pool, LP, SSL, Full Precision, and More

[SteveB]

Great! I look forward to seeing those features.
The hide workers thing sounds good. How about being able to rename workers?

[eleuthria]

Great! I look forward to seeing those features.
The hide workers thing sounds good. How about being able to rename workers?

Will do.  Current list of improvements to be implemented tonight (PST time zone, so morning for some of you):
  1) Hide Workers
  2) Rename workers
  3) Reset worker password
  4) Optional email field for password recovery [and eventually for idle miner warnings]
  5) Optional SMS # field [will be used for password recovery and idle miner warnings once implemented]
  6) Personal block statistics included in the block listing [shares and reward]
  7) API settings to set what information the API reports

[SteveB]

Will do.  Current list of improvements to be implemented tonight (PST time zone, so morning for some of you):
  1) Hide Workers
  2) Rename workers
  3) Reset worker password
  4) Optional email field for password recovery [and eventually for idle miner warnings]
  5) Optional SMS # field [will be used for password recovery and idle miner warnings once implemented]
  6) Personal block statistics included in the block listing [shares and reward]
  7) API settings to set what information the API reports

Wow! Perfect.
With all those features, this pool will be the best of all the pools out there! 

[eleuthria]

Just posting in anticipation for those who just experienced miner idles:  Added another index to the shares database to speed up the calculation of worker hash speeds (was taking way longer than it should), which caused new work to be slowed for about 90 seconds.  It cut the time it took to calculate hash speeds down to less than 1/20th what it used to be, which will be noticeable as more and more workers enter the pool.

[Nythain]

Thanks for that update. Just came here to look into that little hiccup actually.

[Nythain]

Wow one hell of a long round. Over 12 hours now. Hopefully we get a karmic streak of awesome luck for a bit after this one.

[eleuthria]

Wow one hell of a long round. Over 12 hours now. Hopefully we get a karmic streak of awesome luck for a bit after this one.

Not that long actually.  At current difficulty with the pool hashrate rounds should AVERAGE around 16 hours (due to that 50% difficulty spike the other day).  This round (AVERAGE) would be slightly higher since the pool was not running at the current speed this whole round.  The pool is only currently operating at 11.7 gHash.  It's been creeping up all day though, so rounds should get faster and faster.

UPDATE:  Average speed has gone up another 400 mHash since the above figures were posted!

[BitLex]

testing on HD5570 XP64 Cat10.12 SDK2.2 phoenix-1.4

Code:

[11/05/2011 00:07:53] Result: b814a20a rejected
[78.23 Mhash/sec] [84 Accepted] [23 Rejected] [RPC (+LP)]Unhandled error in Defe
rred:
Unhandled Error
Traceback (most recent call last):
Failure: twisted.web._newclient.ResponseFailed: [<twisted.python.failure.Failure
 <class 'twisted.internet.error.ConnectionLost'>>]
[11/05/2011 00:08:52] Result: bdc42770 rejected
[11/05/2011 00:09:45] Result: 68ccac6a rejected
[11/05/2011 00:11:19] Result: dee1d595 rejected
[11/05/2011 00:12:57] Result: 4e9e8b9e rejected
[11/05/2011 00:13:24] Result: 16aeaea8 rejected
[11/05/2011 00:13:29] Result: fce777d3 rejected
[11/05/2011 00:14:03] Result: a6d73144 rejected
[76.15 Mhash/sec] [84 Accepted] [30 Rejected] [RPC (+LP)]

besides the error, 30% of rejected shares is quite high, i've never experienced anything that bad,
any idea about that?.

[Nicksasa]

testing on HD5570 XP64 Cat10.12 SDK2.2 phoenix-1.4

Code:

[11/05/2011 00:07:53] Result: b814a20a rejected
[78.23 Mhash/sec] [84 Accepted] [23 Rejected] [RPC (+LP)]Unhandled error in Defe
rred:
Unhandled Error
Traceback (most recent call last):
Failure: twisted.web._newclient.ResponseFailed: [<twisted.python.failure.Failure
 <class 'twisted.internet.error.ConnectionLost'>>]
[11/05/2011 00:08:52] Result: bdc42770 rejected
[11/05/2011 00:09:45] Result: 68ccac6a rejected
[11/05/2011 00:11:19] Result: dee1d595 rejected
[11/05/2011 00:12:57] Result: 4e9e8b9e rejected
[11/05/2011 00:13:24] Result: 16aeaea8 rejected
[11/05/2011 00:13:29] Result: fce777d3 rejected
[11/05/2011 00:14:03] Result: a6d73144 rejected
[76.15 Mhash/sec] [84 Accepted] [30 Rejected] [RPC (+LP)]

besides the error, 30% of rejected shares is quite high, i've never experienced anything that bad,
any idea about that?.

It's not the pool's fault, i'm at 3700 accepted shares and only 17 rejected using phoenix 1.46.

[BitLex]

well, it's no problem at all on other pools  

Code:

[76.92 Mhash/sec] [508 Accepted] [0 Rejected]

same miner, same settings, different pool (in this case deepbit)

[eleuthria]

I will be home and ready to resume looking into any pool issues that rise.

The high rejection rate is VERY odd, it looks like there was a spike in rejected shares about 20 minutes ago (all my miners jumped about 15 rejects recently), as well as a communication error.

I'd recommend resetting your worker stats and/or restarting your worker just to get a fresh count.  Until the spike, my 12 workers were averaging 0.29% rejected/invalid shares over the past 8 hours.

BitLex: What settings are you using on phoenix (queue size, worksize, etc)?

[BitLex]

well, restarting my worker was the first thing i did when i noticed that error and all shares after got rejected,
it didnt help though, new shares also got rejected (all of them), so i stopped the miner again,
then posted (actually i just wanted to post that error, then i noticed the rejects i haven't looked at before).

anyway, i might have been a victim of that spike then (just started testing ~2hours before),
will test later again.

Code:

WORKSIZE=128 VECTORS AGGRESSION=6 BFI_INT

[eleuthria]

well, restarting my worker was the first thing i did when i noticed that error and all shares after got rejected,
it didnt help though, new shares also got rejected (all of them), so i stopped the miner again,
then posted (actually i just wanted to post that error, then i noticed the rejects i haven't looked at before).

anyway, i might have been a victim of that spike then (just started testing ~2hours before),
will test later again.

Code:

WORKSIZE=128 VECTORS AGGRESSION=6 BFI_INT

Can you send me a PM with the worker name you used?  I'll take a look at the shares log to find out why the server was rejecting them all.

[Miner-TE]

Yeah, I found a block.       Which one?

[eleuthria]

Yeah, I found a block.       Which one?

You found the most recent one.  I'll follow deepbit's format of bolding the blocks found by you when I add personal statistics to the block listing.  Should be up in the next hour or so!  Looks like the server itself is running great (no crashes in the last 14 hours).  Haven't had any new miner idles/RPC comm errors since the issue which BitLex mentioned.

[eleuthria]

A few of the new features were added to the website, but meanwhile the pool is getting crashed during a user authentication again.  Just added a massive amount of debug lines (it's quite beautiful to see the spam of log strings) to pinpoint exactly where it crashes next time, because the backtrace wasn't being particularly useful.

Currently added:
  Hide Workers (and Reveal)
  Block Statistics include your share count, reward, and donation amount


Almost finished:
  Worker password reset
  Worker rename

[eleuthria]

The bug causing all these crashes has finally been identified.  Pool will be resuming in approximately 10 minutes and should not be seeing any more crashes related to the problem.

[shat]

I just attached one of my rigs to your pool, ~ 800Mhash/s and it ran fine for about 5 minutes and now I'm getting connection issues : Problems communicating with bitcoin RPC

[shat]

eleuthria:

Additionally, I am showing I am pushing out 624Mhash/s right now and your site is only showing me: 62.04 mH/sec on 1 worker and 81.13 mH/sec   on the other.

Ideas?

[eleuthria]

The crash should now be fixed!  All my time working in PHP/MySQL the past few years, I forgot some very basic memory management in good old C.  The crash was caused when somebody forgot to send a password with their worker.  Because I added a function to combine the password with the salt, and then hash it, I was trying to work in unallocated memory (the password was a NULL value).

Running in a debugger for the next hour and a half to make sure it got caught (I can only test it so many dozens of ways).  If it looks stable again, the pool will be down for about 3 seconds in an hour when I switch it out of gdb and run it through the auto-restart script.