Poolowner: please test cgminer, it is getting stuck often where it submits a share, loses communication, gets communication, submits a share and loses communication again in a seemingly never-ending loop

I have experienced this also, during this process, the invalid submissions go sky high.

I've tested your pool with poclbm and DiabloMiner and both have problems staying connected, while phoenix, on the same rig, works ok.

What is different between your pool and most others?

Thanks for letting us know about this. We did heavy modifications of pushpool to obtain low stale rates. We've only tested these mods with Phoenix, that's why we recommend it on our site. It now appears that some other clients may experience problems.

I looked through the Diablo code, and I'm fairly certain this is caused by ABCPool timing out the LP connection with a '200 OK' after 50 seconds to get rid of disconnected clients. Most pools don't do this, but it is one of the reasons ABCPool can keep the stalerate low. Phoenix handles this excellently by silently reconnecting; just what we want. Diablominer might expect a different response than 200 OK. I've posted the issue in their forum.

Quote

poclbm keeps disconnecting, I don't have a log, but I can give one if you need it.

Guiminers sad thing for last few hours.Nvidia 260GTX (216) : Shares 44 accepted, 33 stale/invalid .. I know its nonsense to use nvidia card like this but its still small income for me as electric bil isnt issue

Edit:Reason seems to be "Phoenix" it gives out 48.2 mhash and with OpenCL miner i got only 45-47 but it gives out less invalid/stales! I tested this with my older GT 220 too and same results, lot of invalid/stales with Phoenix only.

Edit2:Wrong alert, its gives again hellish amount of stales/invalid even with opencl. Im moving my nvidia based miners to another pool and keep just ati 5770 with your as its onlyone has low amount of stale/invalid.

UPDATE: We are currently investigating the high invalid counts for non-Phoenix clients.

Going through the logs, the high invalid rate is for the most part due to 'invalid-time' submissions. We were seeing some of these before, that's why a few days back we added the

Code:

'X-Roll-NTime: N'

HTTP header to all getworks. This header indicates explicitly that time-rolling is not allowed. It seems that some clients are taking the presence of this header as a sign to enable time-rolling instead of disabling it. That's why we've just turned the header off again. At first glance it seems to have eliminated the bulk of time-invalid submissions.

UPDATE: We are currently investigating the high invalid counts for non-Phoenix clients.

Going through the logs, the high invalid rate is for the most part due to 'invalid-time' submissions. We were seeing some of these before, that's why a few days back we added the

Code:

'X-Roll-NTime: N'

HTTP header to all getworks. This header indicates explicitly that time-rolling is not allowed. It seems that some clients are taking the presence of this header as a sign to enable time-rolling instead of disabling it. That's why we've just turned the header off again. At first glance it seems to have eliminated the bulk of time-invalid submissions.

I think 50 seconds is too little given that you need to communicate a new block every 10 minutes on average.Did you try a very short keep-alive, like a couple of minutes so that the socket gets closed faster if the client pc does not answer fast enough?

I think 50 seconds is too little given that you need to communicate a new block every 10 minutes on average.Did you try a very short keep-alive, like a couple of minutes so that the socket gets closed faster if the client pc does not answer fast enough?

...Using cgminer, cgminer isnt even reporting back invalids. Is it even possible for me to generate that many shares in about 1 hour?

The same problem with cgminer 1.5.6:

I think cgminer is retrying all shares that it thinks it previously failed to submit. It does not report them as invalid yet, because it has not yet given up on them. When i look through the logs, I see you submitting boatloads of 'unknown-work' shares, each for a different block. These are all very, very old shares that cgminer is constantly re-submitting. The original submission attempt might have even been successful. I suspect cgminer wants to see a certain kind of error message before it gives up, and that ABCPool is sending a different one. Each resubmission counts as one invalid share, although in most cases it's the same shares over and over again.

In the next release of our backend the error messages have been changed so they look more like those of the original pushpool. We are still testing this version, and expect to have it ready in a few days.

I think the share count may be off...Mining here since not even 2 days and it shows almost 180.000 shares,I have ~2GH/s and I doubt that I generate that many shares

Also I have a lot of connection problems today Miner is idle, sometimes I lose the connectionand I produce some rejects which say:[21/08/2011 02:45:56] Server gave new work; passing to WorkQueue[21/08/2011 02:46:03] TypeError in RPC sendResult callback[21/08/2011 02:46:03] Result 000000001a948ef9... rejected[21/08/2011 02:46:05] TypeError in RPC sendResult callback[21/08/2011 02:46:05] Result 0000000077394270... rejected

That was right now, while I am posting.Sometimes it runs fine for hours then it starts again.

As mentioned earlier, certain clients are submitting huge numbers of invalid shares while the incompatibility of certain mining clients remains. As this practically means these clients are DOSsing our servers, we are forced to start blocking their respective users in order to ensure service quality for those that are submitting normally.

1. Users that submit more invalid shares than valid (valid + stale) shares (ie. >50% of total is invalid) will be blocked on IP-basis.2. You will only be blocked after submitting at least 1000 shares (ie. it is no problem if you start with submitting 42 invalid shares)3. Blocked users will not be able to continue mining4. Blocked users can still withdraw their funds.

If you are blocked, you may request an unblock by sending us a PM explaining what steps you have taken to mitigate the problem.

Some tips:We noticed that especially the cgminer client sends a lot of invalid shares. If you are using this client, switching to another client will probably solve the invalid-shares issue.

You guys dont pay out the full 8 decimal places? I received 0.2btc with 0.2 set as the minimum.

With automatic payout we pay out in rounded figures, and the unrounded part remains as balance on your account. That way we keep your wallet a bit cleaner. This is how it works exactly:If your balance exceeds the minimum amount set by you, we pay out in increments of that minimum amount. So if you would have had 0.51234BTC, we would have paid 0.4BTC and the remaining balance would be 0.11229BTC (because of the 0.00005 tx fee)

This means your remaining balance is still in 8 decimals; we just subtract the amount that has been payed out. By paying out using these rounded numbers it is easier to gauge your earnings from your transaction overview in the bitcoin client. If you want to withdraw your full balance you may initiate a manual cash out at any time. Manual cashouts are always for the full remaining balance.