This looks like problem of phoenix which I described above. From logs I see that wast majority of your shares are accepted, which does not fit your observation. Btw can you please try poclbm if you'll see the same problems?


This does not matter, submitting shares isn't related to "full" Bitcoin difficulty.

Heh, yesterday I forgot to allow maintenance script for processing blocks after some tweaks. I repair it yesterday, too, so only one block was affected. However nothing happen, everything is fine now.

pekv2: What's your login name? I don't see 'pekv' or similar in connected workers. If your workers are connected again and you don't see any troubles now, it's OK. I restarted beta backend many times in last three hours because of some minor tweaks. I don't see any issues on my side at this moment.

cosurgi: nice :-). I have overnight 103 rejected  / 34030 accepted, which is 0.3% rejected shares (poclbm). Of course it also depends on connection quality and my ADSL is pretty crappy...

I see that some people on beta testing are using older miners even without Long Polling support. Please update to latest miner version to enable new features...

I'm not regular guiminer user, maybe you're right. But there should be also console view showing raw miner output, including stales. But that's thin ice for me, I didn't tried it...

Menu -> View -> Summary :-)

Notice to miners: I tested beta version heavily with poclbm, diablo, phoenix and cgminer. There is only one known issue with phoenix (latest SVN version) as is described also in previous post:

Phoenix is very sensitive to some conditions and may print many 'rejected' although those shares are perfectly valid and accepted by pool. I have such problem on one my machine and also one other user confirmed this. On the other hand, I know about many phoenix instances which run without any problem.

I'm trying to discuss that issue with developers, but currently I'm waiting to their response. If you see higher stale ratio on your phoenix, please check number of accepted shares on your profile page before you'll report that problem.

Beta testers wanted!

I'm proud to announce public beta of long polling and ntime rolling on my pool. This update should lower stale ratio and reduce network overhead for your miners.

Because all of that code is pretty fresh and isn't tested under heavy load, I don't want to turn it on for everybody right now. It is also impossible to carefully test all miner versions and other special tools which some of you are using. Now you have a chance to test your miners and report any problems to me (please contact me directly to info@bitcoin.cz instead of writing to forum to keep this thread sane).

Beta version is running on one backend only, so it can become quite unresponsive in case of big interest. I recommend you to connect only one GPU core to test. Also keep on mind that it's beta and backend might be restarted few times to fix some minor issues.

If you're interested to help me with testing, connect your miner to api.bitcoin.cz, port 8331 (not api2.bitcoin.cz!). Of course all submited shares are calculated to your reward, beta environment is *not* a standalone pool.

RobertRibbeck: How many stales did you receive?

I also reported to phoenix developers that phoenix is very unstable on some conditions. It has probably too short network timeout, so phoenix prints 'rejected' although pool accept that share without any problem. It is case of one my miner, where phoenix reports almost 10% stale, but I in fact all of them are accepted. Network latency was 60ms + pool response time under 10ms in case of debugging... I still don't have any response from developers about this issue, but I'm almost sure that phoenix is just too much sensitive to network quality.

I don't understand. Do you see some problems on your side? Higher stale ratio? What miner, what username/worker login, please?

Hello,

today I upgraded pool backends, maybe you noticed few extra "rejected" shares because of restarts. Now everything runs smoothly again.

Thanks to this update, you can now connect as many miners to one "worker account" as you wish; I finally reworked pool core so this stupid rule isn't needed anymore.

Hi, I upgraded (after long time) phoenix to lastest SVN and now I see many idling messages (one per, say, 30 second). Is latest phoenix more sensitive to network latency? Older phoenix and other miners don't have such problem. Actually I think it is a bug, because I see many times "idling" message and then "accepted" in the same second, which looks weird. Any idea?

Yes, I checked pool status, but everything looks good and it's just unlucky round. Still not the worst round of pool history, but we aren't on the end yet .

I see your point and I thought about something like this. Unfortunately SierraChart isn't so much flexible - it is streaming quotes from current file pointer and rewriting history in this stream will break charts :-(.

Sorry for big OT, but just shortly; you can use SierraChart for MtGox feed even with expired trial. SC (after trial expiration) restricts only features which are not used by Mtgox feed.

And coinfreak - app looks nice, I'll try it :-)

Does telnet service provide also historical quotes?

In sierrachart feed I'm using bitcoincharts only for historical data (except using "-w" option to disable websocket), but delaying makes big problem - once bridge download historical data (delayed) and then start streaming quotes using websocket (realtime), there remain 15min gap without quotes in datafile, forever. And currently I'm thinking about some clean solution...

Hello, there's no reason to have 85% rejected, of course it isn't normal and there must be something specific in your config. Please send me your miner settings to email together with your pool login.

For example yesterday one guy contacted me because he had very high rejected ratio. Then we found that he was using wrong domain on his side for some miners (api1.bitcoin.cz instead api.bitcoin.cz or api2. bitcoin.cz). So there might be some stupid mistake, too.

I understand, unfortunately this looks like a problem of data source (mtgox).

Thanks for your support, catfish! Mining two blocks so fast as one miner is realy lucky. For example, one of my card didn't find a block since January and then found some blocks in a row with current difficulty. It was really weird :-).

About namecoin - I'm following their project and it would be great to support them with merged mining. It can earn few bucks for pool users on top of their actual income, so let's see what happen.