Ok, userstats should be back in the API now.

I responded in your thread. My point still stands and is still valid unless there is something new and interesting that you've come up with that no one else has to reduce latency.

After I wrote that a bit later I realized it might have sounded accusatory or advasarial and I apologize for that.  It was not my intent, but by that time it was already out there and editing it would have been pointless.  However, the contention in the message still stands and I'm not seeing where there's a rebuttal in so far as providing anything to refute the fact that you simply aren't reporting the stale/invalid shares even though they exist. 

I said as much that it's great that you are paying for stales and being a PPS pool, it's a definite advantage - I have absolutely no argument with that.  But whether or not you report it is immaterial to the fact that you are paying for stales - you pay for them either way, so it is to your advantage to NOT report them to give the illusion that you have a better (lesser) reject rate than other pools. 

I'm not sure you understand how LP works when talking about stales in relation to LP.  It's completely immaterial how connected your bitcoind is or how quickly your bitcoind gets notified of a new block - your bitcoind and pushpool (if you are using pushpool or something else, it doesn't really matter) are a little microcosm of the larger network.  All that matters for LP and stales is when pushpoold is notified of a block change, the LP is pushed out and the workers receive new shares for the block bitcoind is currently on.  The Bitcoind -> Work Distribution Server interaction are all that matters.  Bitcoind is going to be doling out the getworks to your getwork server based on what it thinks is the current block.  Your bitcoind could be 10 blocks behind and that will not have an effect on your stale count because your getwork server is serving up what bitcoind thinks is the latest block and submitting it back, which bitcoind tests against what it thinks is the current block.  If your bitcoind is behind and you find a hash that fits, it will then submit it to the network and get an orphaned block because it was behind.

So again, I still content that you are either not reporting the actual number of stales or you've found some magical new method to a) reduce latency between your getwork server and bitcoind by a factor of two or three and more importantly b) found a really magical method to notify all miners of new work with less latency by several orders of magnitude.

Since you have no control of the links between your getwork server and the miners, and you have no control over the miners and their systems, it would really be a magical method to reduce your stale shares beyond possibly maybe 2% maximum at a theoretical limit.  If you gain control over those system, then yes you could reduce that further, but barring controlling the entire system, with the current GPU miners out there, you simply can't reduce it beyond that threshold because of built in problems with the protocol in general.

I apologize for the downtime.  I noticed a problem with the MySQL database and in the process of diagnosing it, I decided to reboot the server which turned out to be a bad idea.

After the server came back up, I continued diagnosing the problem and identified two separate issues causing slow queries on the DB.  I've completely fixed one I believe, the other one is related to the user stats in the API.

I need to do some code rewriting for that, as such, worker stats in the API (yeah, the same thing I just fixed earlier today, which is why the problem just showed up) are disabled until I get it rewritten.  Possibly tonight, but more likely tomorrow.

I apologize for the inconvenience... I guess the user stats hadn't been working since I made a change a few days ago and when I fixed the api to accommodate the change today the old method of calculating stats puts the new table under too big a strain.

I believe this is also the cause of the intermittent Can't connect to RPC errors some of you noticed as well, so this should eliminate that as well.  Three bugs fixed for the price of one!  Bonus... err wait..

The pool is having a hardware issue.  It will be back up in about 30 - 45 minutes while I replace the failed part.

Indeed.  Well, the "rejects" you see in the terminal aren't really rejected in the literal since.  They are accepted and found to be invalid for one reason or another and reported as rejected.  It's fairly easy to turn that off and just report accepted for every share, regardless of its' true disposition in finding a block.

They modify their getwork server to report less rejects/stales.  There's no mystery there. I can do the same here if it'll make you feel better, though.  I can, in fact, using their methods, give you 0 rejects.

They have the same reject rate as here, they just don't report it to you, so you will never know if you are having a problem or not and therefore causing a detriment to the pool as a whole.  On an individual level, it's not a big deal, but when you start getting a lot of miners, and if everyone has absolutely no idea if there's a problem, it can add up to a significant drain on the pools true hashing power (vs reported hashing power).  Unless they've done some mathematical gymnastics with stat reporting, their true hashrate is 1.5 - 3.5% lower than their reported hash rate.  That means you are losing out on 1.5 - 3.5% of your potential income vs variance when you make a decision to mine at a given pool.  (That is not to say your overall income is materially affected, only your decision making ability to assess whether one pool is better than another.  Although, if enough people have unreported problems it will also affect your overall income as well.  But you'll never know unless people self report a lower than expected income.)

They bill this as a "feature," and in so far as they pay you on stale shares it is definitely a bonus, but in reality it's basically dishonest math when measured against the accepted standard.  I've not found anywhere that they confirm or deny that they report stats based on stale shares as well.

Sure, I will add all those things this week.

Found the bug... sorry about that.  It should be fixed now.

Are you putting your key after the = ?

For which output?  What URL are you using?

Other than fixing the memory leak a few days ago, I haven't made any changes to the getwork servers at the moment, other than to put in some code for the new pooling methods.

Password cracking comes to mind.  Google Whitepixel for more information on that.

I'm not sure why that would be, it's kind of boggling.  Is anyone else experiencing this issue?

I will provide details once I release it to the public.

Yeah, once the Prop/PPS is working I will change the decay back to a shorter interval.

The PPS code got in the way of block processing.  Got it all straightened out and it's good to go now.  Hopefully I can test out the Prop processing tomorrow and at least bring that up for a live test.

All stats should be updating properly now and block processing should be fine for Scoring from here on out.  Estimated rewards are going to read lower than usual this block due to the block processing time being off vs. the number of shares.  Actual rewards are calculated directly out of the shares submitted, so the estimated rewards for this round are going to be off by about 30% at least for most people (unless you're pool hopping, then they'll read high instead of low).

I thought Macs "Just Work?"

PPS and Prop is on the way.  I hope to have some testing started this weekend (Sunday most likely) on the prop portion and then this week on PPS.

Current decay rate will have your shares decaying to 0 in about 4 hours give or take about 30 minutes, possibly more variance if the hashrate changes significantly.