What's wrong with that and why it should affect quality of his preinstalled hdds? There is no reason to build rigs into well looking boxes; design does not what improve your hashrate.

Nothing is perfect and LP don't lead to absolute zero of stale shares; there are still latencies in server broadcasts, on network level, miner have to refresh his job internally etc. I think 0.3% is the minimum which can be done with current infrastructure, so 0.6% isn't SO bad.

Btw I'm thinking that better number for showing LP effectivity should be (stale shares)/(new blocks notifications), which tell us in how many cases was the LP broadcast too late. It is more exact than (stale shares)/(submitted shares), because this number depends also on bitcoin network speed (difficulty and hashrate) and when new blocks are coming faster or slower than before, this number will be affected. What do you think, Tycho?

It's in (I think military) museum, but I never been here.

Hehe, everybody in Czech knows Pink tank #23. But it isn't on Smíchov for more than 15 years, they removed it long before I came to Prague. So no, I never seen it .

Btw it was done by David Černý, a little controversal artist . I like also his Dead Horse which is hanging 20 meters from my office. Both artworks are tightly related to Czech history and mentality.

...which will be also low for today, because we hit few extra long rounds.

Edit: Finally the day wasn't so bad, pool found 5 blocks in the row (firstly in history?) few minutes before midnight. Yes, that's the probability .

Yes, all those bugs are related to single thing, to the update of "last submit timestamp" for each worker, which is currently incorrect (it is only correct immediately after processing the last block); I'll fix that, it just need little workaround. All this is because I optimized data structures for writing instead of for reading  (as there are tens or hundreds of writes per second, but only few readings), so reading exact timestamp for every worker cannot be so "cheap" in all cases. I have to do some postprocessing (denormalization) on the dataset to allow fast reading of them. But this bug does not affect mining core and calculating rewards in any case.

Yes, this and "connected: No" in hall of fame are known bugs. I'll fix it soon, now I'd like to finish long polling and related updates.

Thanks for reporting; I found that one wallet had insufficient funds for paying tx fees. It is fixed now, payment should be processed withing one hour.

Btw insider look and friendly advice:

Please fix algorithm on your homepage for calculating hashspeed. The constructs like


when you have round with hundreds of thousands shares are strange and my eyes are bleeding. Did you ever seen something like

?

Also, there is not needed to perform two database calls, your current hashspeed can be done only with knowing of count of shares in statistics window.

My pool calculate hashspeed from submitted shares, not from requested getworks, of course.

Your reverse engineering failed. I publishly noted that there were bugs in getwork/s and hashrate/s meters. To explain that: I'm writing operational stats to database in sligly delayed fashion, so stats are queueing and then processed in batch (the delay is ~5 sec, so nothing dramatical). The bug was caused by race condition in writing actual stats queue to database, so in case of server overloading, more threads processed the same database write and the info about actually processed shares doubled/trippled/quadrupled. This affected only stats page, no calculating shares/score for users.

So when you overloaded the pool (thank you), you triggered this bug. It was fixed few days ago.

Well, it is little complicated under the hood. Server must remember jobs which served you, to be able to perform some checks on share submitting. As the server has limited memory for every worker jobs, with knowledge of user/password, the attacker can make your mining impossible by erasing your worker queue. Well, it is nothing to too much worry about, but posting your full worker credentials on the web isn't generally good idea.

There are some technical reasons why it isn't good idea. In some cases your miners might duplicate the effort (and from two same submitted shares, only one will be accounted). Simply - don't do that, really .

Please select one from supported miners (in your case, it will be probably jgarzik's CPU miner) and follow instructions in his forum thread. The link is on the pool homepage. If you will have any troubles with that, don't hesitate to ask more specific directly in that thread.

No, leave it as is. I had to restart bitcoin daemons on the server, so the stale shares were probably caused by short outage.

Yes, the difficulty was artifically pulled up by Mystery Miner operation, so when he disconnected his botnet, it is going back down. Also probably many users decided to not buy another rigs during previous difficulty window, because hashrate started to rise exponentially.

In long term, it will be the same. It depends only on your personality if you prefer steady payouts or gambling . I know that some people here were lucky and earned much more than expected (for example 7 blocks per day). But on the other hand, you can mine week or two without a block. Probability is a bitch .

With pool, you can be sure that you will have expected amount on your account every day; no more, no less.

I almost never mined solo; I did pool 14 days after I bought my first card. But during those 14 days I was on 60% of expected payout. Few days ago I checked my results on the pool. I found 80th block for the pool and my total reward was 4017 BTC, so it is really very constant.

Currently the poclbm does not drop job when share is found. Afaik the whole network stuff is in separate thread, so it should work 'asynchronous'. But I didn't do any debugging, maybe it is really handing somewhere. m0mchil performs new getwork before whole nonce space is crunched, so unless you have really crappy line, it should work fine.

Btw ongoing improvements in the pool will make network load waay lower than it is now. And I'm not talking only about long polling .

Well, with well written miner, there is no reason why cores should wait on submitting shares; it can be done fully in asynchronous way (just send, don't wait - at least in blocking state - to response). Maybe the feature request to the miner developers? Blocking getworks are another issue, but I'm working on it - its long polling and next stuff comming soon.

The higher difficulty for fast cards are good idea, it is already on my list for some time. It will definitely come, I have some algorithms to find 'idea' difficulty for given worker in my head; will see how it will work in real life . Keep in mind that higher difficulty does not mean only lower network overhead, but also higher variance in round rewards and maybe also some new kind of pool attacks, so it need some care to don't break anything.

LOL, you don't understand. I didn't apologize for anything. I was just constructive about your last change.


Oh, I didn't know that you banned me :-). Please, keep me banned, really.


No, nothing changed from my previous statements about efficiency of long ask rate. But that discussion is over, I hope.

And to be clear, I said that I 'quite like' the solution. Still think that long polling, which I'm testing on my pool (and is already in production on tycho's one, to be clear), is better way to go. But it's no offence.