This is just telling you that miner cannot reach any of configured pools, which is pretty normal if your network connection is down...

No, pool was up all the time. Connectivity issue?

I'm quite surprised that it doesn't work for you. I'll test it on my machine soon...

Yes, Sierrachart uses Chartbooks ("*.cht" fileformat) for storing labels, drawings etc. It's independent on data source or chart type. And yes, OP is still up to date.

There's history playback in Sierrachart (Ctrl+R) and you can record it using many tools like FastStone Capture (I have good experience with it, however it costs $20).

Sorry for no response to your discussion, I was away for few days. The work on new pool core is a bit more complicated that I originally expected, so I'll implement double geometric method even on current pool core. You can expect it in few days, together with notifications about dead workers.

Hello jproulx,

I see that pool banned some IPs which you were used. It's because pool detected getwork flooding from such addresses. I'm wondering if there's some bug in cgminer, because in recent days I had some similar cases and all those users were using cgminer.

How big is your mining rig? Afaik you generate around 2Ghash, but those IPs were performing hundreds of getworks/s (total pool performance is around 500gw/s).  I know that ckolivas probably hates pool operators, because cgminer is very aggressive and it overload servers even in normal run, but this looks like a bug.

(repost from pool thread)

This is very interesting, but some other people come from other pools to my pool exactly because they have no 100% cpu bug with me :-). I mean - there's probably some strange issue inside guiminer which can be triggered by something like faster/slower responses etc (I mean some strange race condition or so). I didn't changed mining part since March 16 and I even cannot imagine how can I affect this bug by any change inside the pool...

This is very interesting, but some other people come from other pools to my pool exactly because they have no 100% cpu bug with me :-). I mean - there's probably some strange issue inside guiminer which can be triggered by anything like faster/slower responses etc. I didn't changed mining part since March 16 and I even cannot imagine how can I affect this bug by change inside the pool...

I also received notification from server provider that they're changing edge router which suddenly failed (both 10G cards, what a chance?). Traffic is now going over backup router, but I expect some routing issues during the maintenance.

Some kind of attacks are pretty common and all major pool operators have a lot of experience in fighting them :-).

I'm solving the issue, looks like another attack.

Heh, both bad luck and good luck cannot last forever :-). But we're still on 103% of monthly luck...

We discussed switch to double geometric back on November during Prague conference - and you know that it's not *that* simple as it sounds. I played with dgm method a bit, but it is making pool architecture too complicated.

Today I blocked some suspicious IPs. Let me know if you cannot reach the pool and you're not  a russian script kiddie.

I don't know GUIminer configuration format, but there's new parameter in poclbm miner - see "poclbm.py --help"

If GUIminer already included latest poclbm, which is optimizing mining over Tor, then everything what you need is to use host "pool57wkuu5yuhzb.onion" and configure poclbm to use proxy on 127.0.0.1:9050 (local Tor socks proxy).

There was middle-sized coordinated attack against the pool. It took me few minutes to locate source of flooding, so pool was down for a moment. I'm sorry for connection issues.

I'm aware of issue with processing blocks and payouts, I'll fix it within few hours..

Edit: It's fixed now, all pending payouts were sent.

rapeghost & all others - I'd like to thank you for all your support, both financial and moral. 3000 BTC is really lot of money for me, but this helps me to pass on :-).