I did few pool restarts today because of fine tuning LP, you probably got some connection errors and rejects. Everything is stable now.
I also disabled LP for some miners (user agents) which didn't handle LP correctly. Namely Ufasoft miner, which don't follow LP specification. I reported it to ufasoft and he already fixed that in development version. So I'll enable LP for ufasoft soon again.
Topic: [4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool - page 975. (Read 4382653 times)
October 05, 2011, 06:03:11 PM
October 05, 2011, 02:35:46 PM
Hey slush ... after what seemed as few restarts on the 'beta' pool i'm now getting quite a few rejects ... while still getting accepts
Thanks, there was really small glitch on beta. It's fixed now.
October 05, 2011, 02:16:30 PM
Hey slush ... after what seemed as few restarts on the 'beta' pool i'm now getting quite a few rejects ... while still getting accepts
the same goes for my cgminer ...
are you aware of that?
Code:
[5.10.11 21:08:22] api.bitcoin.cz accepted block 7380 from Cayman (#1)
[5.10.11 21:08:34] api.bitcoin.cz accepted block 7381 from Cayman (#1)
[5.10.11 21:09:05] api.bitcoin.cz rejected block 20 from Cayman (#1)
[5.10.11 21:09:06] api.bitcoin.cz rejected block 21 from Cayman (#1)
[5.10.11 21:09:11] api.bitcoin.cz accepted block 7382 from Cayman (#1)
[5.10.11 21:09:24] api.bitcoin.cz accepted block 7383 from Cayman (#1)
[5.10.11 21:09:34] api.bitcoin.cz accepted block 7384 from Cayman (#1)
[5.10.11 21:09:36] api.bitcoin.cz accepted block 7385 from Cayman (#1)
[5.10.11 21:09:39] api.bitcoin.cz accepted block 7386 from Cayman (#1)
[5.10.11 21:10:06] api.bitcoin.cz rejected block 22 from Cayman (#1)
[5.10.11 21:10:12] api.bitcoin.cz accepted block 7387 from Cayman (#1)
[5.10.11 21:10:13] api.bitcoin.cz accepted block 7388 from Cayman (#1)
[5.10.11 21:10:36] api.bitcoin.cz rejected block 23 from Cayman (#1)
[5.10.11 21:11:18] api.bitcoin.cz accepted block 7389 from Cayman (#1)
[5.10.11 21:11:20] api.bitcoin.cz accepted block 7390 from Cayman (#1)
[5.10.11 21:11:36] api.bitcoin.cz rejected block 24 from Cayman (#1)
[5.10.11 21:11:52] api.bitcoin.cz accepted block 7391 from Cayman (#1)
[5.10.11 21:12:04] api.bitcoin.cz accepted block 7392 from Cayman (#1)
mhash: 399,3/397,8 | accept: 7392 | reject: 24 | hw error: 4
Code:
[2011-10-05 21:09:39.777347] Share c2ea6e52 rejected from GPU 0 thread 1
[2011-10-05 21:09:46.569505] Share 1e13455e accepted from GPU 0 thread 0
[2011-10-05 21:09:51.408267] Share 18927acb accepted from GPU 0 thread 1
[2011-10-05 21:10:01.744574] Share dbec8742 accepted from GPU 0 thread 1
[2011-10-05 21:10:08.810689] LONGPOLL detected new block on network, waiting on fresh work
[2011-10-05 21:10:10.067928] Share 85c6f20b rejected from GPU 0 thread 1
[2011-10-05 21:10:19.045439] Share 9ca6686c rejected from GPU 0 thread 1
[2011-10-05 21:10:22.067179] Share 0b7a6c8e accepted from GPU 0 thread 0
--- SNIP ---
[2011-10-05 21:14:27.277004] Share d3a0a91f accepted from GPU 0 thread 1
[2011-10-05 21:14:38.154782] LONGPOLL detected new block on network, waiting on fresh work
[2011-10-05 21:14:46.392136] Share 9525f355 rejected from GPU 0 thread 0
[2011-10-05 21:14:52.611063] Share c16f8599 rejected from GPU 0 thread 0
[2011-10-05 21:15:06.256101] Share bfb7882f accepted from GPU 0 thread 0
--- SNIP ---
A:1165 R:21
October 05, 2011, 01:20:34 PM
Recently I added important features to pool (long polling and ntime rolling), but support of those features is really weak in some old miners. If you see walls of rejected shares on your miners, please update them to latest version - some of you are using really old miners which does not correctly handle all pool features.
Note for Phoenix users: If you are already using latest Phoenix and you still see walls of rejected shares, you're probably affected by known bugs in Phoenix (see post above or in phoenix thread). Please downgrade to phoenix 1.5 or switch to another miner (I recommend poclbm or GUIminer with poclbm core).
Expected stale ratio is far under 1%. It also depends on connection quality and latency to pool servers. If you see higher stale ratio, please report it by PM or by email to [email protected]. I will need your worker login, exact version of miner and ideally copy of miner log (together with your timezone) to investigate that issue on my side.
Note for Phoenix users: If you are already using latest Phoenix and you still see walls of rejected shares, you're probably affected by known bugs in Phoenix (see post above or in phoenix thread). Please downgrade to phoenix 1.5 or switch to another miner (I recommend poclbm or GUIminer with poclbm core).
Expected stale ratio is far under 1%. It also depends on connection quality and latency to pool servers. If you see higher stale ratio, please report it by PM or by email to [email protected]. I will need your worker login, exact version of miner and ideally copy of miner log (together with your timezone) to investigate that issue on my side.
Thanks Slush
version 1.50 is still buggy but at least it's better
October 05, 2011, 12:14:03 PM
Recently I added important features to pool (long polling and ntime rolling), but support of those features is really weak in some old miners. If you see walls of rejected shares on your miners, please update them to latest version - some of you are using really old miners which does not correctly handle all pool features.
Note for Phoenix users: If you are already using latest Phoenix and you still see walls of rejected shares, you're probably affected by known bugs in Phoenix (see post above or in phoenix thread). Please downgrade to phoenix 1.5 or switch to another miner (I recommend poclbm or GUIminer with poclbm core).
Expected stale ratio is far under 1%. It also depends on connection quality and latency to pool servers. If you see higher stale ratio, please report it by PM or by email to [email protected]. I will need your worker login, exact version of miner and ideally copy of miner log (together with your timezone) to investigate that issue on my side.
Note for Phoenix users: If you are already using latest Phoenix and you still see walls of rejected shares, you're probably affected by known bugs in Phoenix (see post above or in phoenix thread). Please downgrade to phoenix 1.5 or switch to another miner (I recommend poclbm or GUIminer with poclbm core).
Expected stale ratio is far under 1%. It also depends on connection quality and latency to pool servers. If you see higher stale ratio, please report it by PM or by email to [email protected]. I will need your worker login, exact version of miner and ideally copy of miner log (together with your timezone) to investigate that issue on my side.
October 03, 2011, 07:30:14 PM
when will the :8331 backend be shutdown?
8331 will be still working, I'll be using those miners for stress-tests for new pool features which are coming. So if you want to help me with that, leave your miner(s) connected here.
Ill leave em all parked at :8331 then. running cgminer with failover to another pool if something happens so no worries here.
October 03, 2011, 07:09:41 PM
Sent! 
October 03, 2011, 06:58:18 PM
I'm sending a donation your way. I really really appreciate your help.
Thank you :-).
October 03, 2011, 06:52:06 PM
Is this pool located in the UK?
Yes, in London.
Quote
I don't know what is going on but I am being hammered with rejected shares, only in ten minutes I had more than 25 rejected.
It is probably because of failed LP broadcast. You've problem with LP connectioins (as described in phoenix forum thread). When LP connection fails, miner don't know about new bitcoin block and he's still submitting shares from old job, which leads in wall of rejected...
If you read my bug reports in phoenix thread, some phoenix instances have very weird connection problems. Unfortunately it is more than week when I report those issues to phoenix developers via PM and I still don't have any response. However I know there are some pool users affected by those bugs and I'm pretty sure that you are one of them.
Generally I have following advices:
1) Changing phoenix to something more stable, at least until they fixed those weird connection bugs. From my experience poclbm is much more stable and is following protocol standards much better than phoenix.
2) Disable LP for those workers on profile page and after few minutes restart miners. Your miners will work in the same way as on pool version without LP.
Quote
I swapped to deepbit as a test, been mining for an hour, I've only got one rejected so far.
There are small differences between my pool and deepbit implementation, which probably lead to this:
a) My pool is officially supporting miner extension "X-Roll-NTime", so miner can use one job up to one minute, because he can modify "ntime" parameter of job.
b) Pool is rejecting submits from jobs older than 5 minutes even when there wasn't new bitcoin block. I don't know how old jobs deepbit accepts, but this 5 minutes timeout (originally 60 second in X-Roll-NTime specs) is there because miners need to reload merkle tree time to time and 60 seconds are pretty good compromise.
Unfortunately one of phoenix bug is that he's sometimes reusing *very* old jobs for no reasons, so those shares are rejected. This was also reported and also without response...
Short summary: Turn off LP or change miner to poclbm, both ways will probably solve your issues.
Slush, let me start of with a huge Thank you, for the great writeup of explanation in this thread and in gui mining thread.
I've been using poclbm since day one of me mining, dating back quite a few months ago.
I am looking into problems reported for the model of my router and modem see if I cannot find something atleast in any forums for a fix or something.
As of 20 min ago, I'm back on guiminer v2011-08-24, 20 min of mining I haven't received one error or rejected, I will take your suggestion if errors occur again and disable LP.
I'm sending a donation your way. I really really appreciate your help.
Thank you.
October 03, 2011, 06:45:31 PM
when will the :8331 backend be shutdown? should I switch all mine back to :8332 in the next couple days?
8331 will be still working, I'll be using those miners for stress-tests for new pool features which are coming. So if you want to help me with that, leave your miner(s) connected here. Otherwise you can connect to "production" pool at 8332 at any time. At this moment, both "beta" and "production" are running same pool version...
October 03, 2011, 06:42:41 PM
Quote from: slush
I report those issues to phoenix developers via PM and I still don't have any response. However I know there are some pool users affected by those bugs and I'm pretty sure that you are one of them.
I'd like to be more specific. From all ~6000 connected miners only few (up to 20) of them have some troubles and _all_ of those are using phoenix. All other miners are performing better than without LP support. I wanted to fix phoenix before I enabled LP support on live pool, unfortunately because of missing interest from side of phoenix developers I decided to release new pool version and ask those affected users to change their miners. Phoenix is pretty good miner, but it has some really weird bugs which affect 0.1% of users and there's nothing what I can do for that on my side...
October 03, 2011, 06:38:57 PM
During this day I'm turning on Long polling and NTime rolling for all backends.
when will the :8331 backend be shutdown? should I switch all mine back to :8332 in the next couple days?
October 03, 2011, 06:34:20 PM
Is this pool located in the UK?
Yes, in London.
Quote
I don't know what is going on but I am being hammered with rejected shares, only in ten minutes I had more than 25 rejected.
It is probably because of failed LP broadcast. You've problem with LP connectioins (as described in phoenix forum thread). When LP connection fails, miner don't know about new bitcoin block and he's still submitting shares from old job, which leads in wall of rejected...
If you read my bug reports in phoenix thread, some phoenix instances have very weird connection problems. Unfortunately it is more than week when I report those issues to phoenix developers via PM and I still don't have any response. However I know there are some pool users affected by those bugs and I'm pretty sure that you are one of them.
Generally I have following advices:
1) Changing phoenix to something more stable, at least until they fixed those weird connection bugs. From my experience poclbm is much more stable and is following protocol standards much better than phoenix.
2) Disable LP for those workers on profile page and after few minutes restart miners. Your miners will work in the same way as on pool version without LP.
Quote
I swapped to deepbit as a test, been mining for an hour, I've only got one rejected so far.
There are small differences between my pool and deepbit implementation, which probably lead to this:
a) My pool is officially supporting miner extension "X-Roll-NTime", so miner can use one job up to one minute, because he can modify "ntime" parameter of job.
b) Pool is rejecting submits from jobs older than 5 minutes even when there wasn't new bitcoin block. I don't know how old jobs deepbit accepts, but this 5 minutes timeout (originally 60 second in X-Roll-NTime specs) is there because miners need to reload merkle tree time to time and 60 seconds are pretty good compromise.
Unfortunately one of phoenix bug is that he's sometimes reusing *very* old jobs for no reasons, so those shares are rejected. This was also reported and also without response...
Short summary: Turn off LP or change miner to poclbm, both ways will probably solve your issues.
October 03, 2011, 04:33:59 PM
Is this pool located in the UK?
I don't know what is going on but I am being hammered with rejected shares, only in ten minutes I had more than 25 rejected.
I swapped to deepbit as a test, been mining for an hour, I've only got one rejected so far.
I don't know what is going on but I am being hammered with rejected shares, only in ten minutes I had more than 25 rejected.
I swapped to deepbit as a test, been mining for an hour, I've only got one rejected so far.
October 03, 2011, 12:37:49 PM
During this day I'm turning on Long polling and NTime rolling for all backends. If you see any issues on your miners, you can manually turn off LP&NTime rolling on profile page for any worker. Pool needs some time (up to 30 minutes) to apply changed settings in pool core. If your miner have some problems with those features, you'll probably need to restart miner to stop using LP, too.
Don't forget to report this issue to [email protected]
I'll write official announcement with latest changes on pool later, this is just quick how-to for fixing miner issues.
Don't forget to report this issue to [email protected]
I'll write official announcement with latest changes on pool later, this is just quick how-to for fixing miner issues.
October 01, 2011, 04:43:00 AM
Before few minutes one balancer crashed for unknown reason. It is up and running again, I'm currently investigating what happen.
September 30, 2011, 07:06:15 AM
lol block num 0. I've got the same.
This small error in stats is fixed
. September 30, 2011, 04:03:14 AM
lol block num 0. I've got the same.
8209 2011-09-30 08:22:45 4:42:07 5528189 0.02003691 0 confirmed 1440.92 577.43
8209 2011-09-30 08:22:45 4:42:07 5528189 0.02003691 0 confirmed 1440.92 577.43
September 30, 2011, 03:35:43 AM
Hi Slash! what does it mean 
# Block found Duration Total shares Your reward Block # Validity
8209 2011-09-30 08:22:45 4:42:07 5528189 0.12766817 0 confirmed
# Block found Duration Total shares Your reward Block # Validity
8209 2011-09-30 08:22:45 4:42:07 5528189 0.12766817 0 confirmed
September 29, 2011, 02:25:07 PM
yep. its working again tx.
got microseconds patched in ... will let you know when/if it shows up again ...
tx. got microseconds patched in ... will let you know when/if it shows up again ...
Jump to: