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. |
|
|
|
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 info@bitcoin.cz. 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. |
|
|
|
I'm sending a donation your way. I really really appreciate your help.
Thank you :-). |
|
|
|
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... |
|
|
|
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... |
|
|
|
Is this pool located in the UK?
Yes, in London. 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. 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. |
|
|
|
Could someone please explain to me what means? Connection for long polling was interrupted for some reason. There are many reasons, usually pool or some router on the way don't handle long living connections properly. Because you sent me full log in PM, I know that's not an issue of my pool, but something on your side is closing connections. From my experience some modems don't handle long living connections properly, maybe something like might be your case... |
|
|
|
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 info@bitcoin.czI'll write official announcement with latest changes on pool later, this is just quick how-to for fixing miner issues. |
|
|
|
|
I like this neat idea. Is there a chance that somebody write patch for official client?
|
|
|
|
Unfortunately it doesn't work for me (Ubuntu, sdk 2.1, ati 5970): miner@miner1:~/vanitygen$ ./oclvanitygen -d3 1
WARNING: Built with OpenSSL 0.9.8o 01 Jun 2010
WARNING: Use OpenSSL 1.0.0d+ for best performance
Difficulty: 1
Compiling kernel, can take minutes...done!
WARNING: AMD BFI_INT patching failed
Match idx: 0
CPU hash: 5a6de23e99d7d70d986fc0daad500c39af74af20
GPU hash: 1db6a03acbf6e04f0425be28ff3dcebbc46911e9
Found delta: 655355 Start delta: 1
[1.92 Mkey/s][total 655360] Match idx: 0
CPU hash: e3efc75d73fd9934403f2ee1c1fc42bcaaacce0a
GPU hash: a8b1a2db739c394901453baa2b5a61ec6775b99b
Found delta: 655355 Start delta: 1
Match idx: 0
I tried many parameters like -V -S etc, but without success :-(. |
|
|
|
|
Before few minutes one balancer crashed for unknown reason. It is up and running again, I'm currently investigating what happen.
|
|
|
|
lol block num 0. I've got the same.
This small error in stats is fixed  . |
|
|
|
btw. beta broken? or is it just me?
yes, it should be back in 5 minutes (DNS timeout). |
|
|
|
|
FoxMURDER: That looks fine; it is probably one line per your core, right? There might be very short delay in longpolling broadcast and cgminer probably handle it in this way. Too bad that cgminer does not show also miliseconds, because that delay is definitely smaller than one full second as is recorded in your log (from my logs I see that all broadcasts were finished in 68 miliseconds after new block was accepted for this particular block).
|
|
|
|
although cgminer reported longpoll/new work three times at 9:40 at the same second (forgot to SS it  ) ... it seem like some kind of glitch, because there were just one block at that time ... Interesting. Is that 9:40 CET? From logs at 11a:47 UTC I see that server broadcasted block only once to you (worker "hacked" looks like cgminer). Can you please copy log or make a screenshot next time? Thanks! |
|
|
|
RPCProtocol.py: @defer.inlineCallbacks
def call(self, method, params=[]):
"""Call the specified remote function."""
_start = time.time()
print "Start submitting"
body = json.dumps({'method': method, 'params': params, 'id': 1})
response = yield self.agent.request('POST',
self.root.url,
Headers({
'Authorization': [self.root.auth],
'User-Agent': [self.root.version],
'Content-Type': ['application/json']
}), StringBodyProducer(body))
print "\nTime %.03f" % (time.time() - _start)
d = defer.Deferred()
response.deliverBody(BodyLoader(d))
data = yield d
result = self.parse(data)
defer.returnValue((response.headers, result))
I found something. It looks that agent is doing something nasty, because "Time: xxx" prints really weird numbers (6-14 seconds to perform request). No difference what pool I'm trying, I see very similar numbers for my pool and deepbit. This might explain both submitting stale shares after LP announcement and idling messages... I added similar logging of request time to poclbm and also tried to perform getwork request using wget and simple twisted code using twisted.internet.protocol.ClientFactory and all those methods are giving me response times in tens or hundreds miliseconds, which looks fine. So there must be something wrong in the way how agent handle connection. Btw I'm using twisted 11.0.0 on this machine. Edit: OK, last observation for today: I found it spends many seconds between "yield self.agent.request" and " def cbConnected(proto)" in client3420.py, even when this connection is marked as permanent, so it should not spend so much time for connecting on every request. I saw also some retries of requests during debugging, although there's not obvious reason for that (connection was stable all the time and response times were fine). |
|
|
|
First issue:
[28/09/2011 20:29:29] LP: New work pushed
[28/09/2011 20:29:38] Result 0000000064aec14a... rejected
a) That rejected share is calculated from previous block (I compared it with logs from pool). How does it come that miner submit a share 10 seconds after longpoll notification?
Now I tested latest phoenix on my miners against deepbit and can confirm this problem there, too. Phoenix is submitting shares from old jobs even if he already know about new block. Race condition somewhere? |
|
|
|
|
Another issue: I see that some users (which claimed they're using latest phoenix without mods) are submitting shares from 10 minutes old jobs! Is there any mechanism in phoenix to stop using very old jobs? Thanks to LP specification from deepbit miners should ask for new job every 60 seconds to work on updated merkle treee...
|
|
|
|
|
Hello phoenix developers,
I'm fine tuning longpolling on my pool right now and I have many major issues with your miner, which blocks me from releasing longpolling for users. Can you please take a look? I sent you some PMs days ago, unfortunately without any response.
One is issue described above by cosurgi + two others:
First issue:
[28/09/2011 20:29:29] LP: New work pushed
[28/09/2011 20:29:29] Server gave new work; passing to WorkQueue
[28/09/2011 20:29:29] New block (WorkQueue)
[28/09/2011 20:29:34] Server gave new work; passing to WorkQueue
[28/09/2011 20:29:34] Currenty on block: 147283
[28/09/2011 20:29:38] Result 0000000064aec14a... rejected
a) That rejected share is calculated from previous block (I compared it with logs from pool). How does it come that miner submit a share 10 seconds after longpoll notification?
b) Why there's "server gave new work" 5 seconds after LP push when ntime rolling is enabled? It should use still that one work, only increasing ntime, isn't it?
Second issue:
On some computers phoenix has problem with network layer. I didn't find any key, because those computers which I debugged have pretty good connection, so "crappy line" isn't probably an issue (I'm talking abou 60ms roundtrip to pool server + <10 ms server response). On those machines phoenix:
a) Print idling message pretty often, but it's very common to have "idle" message and then "accepted" in the same second. How can miner generate a share when he's idling?
b) Print "rejected", but I see that this share was initially accepted by pool. Long description: Phoenix probably don't process correctly server response (which confirms accepthing that share), so he try to re-submit share, which is rejected by pool as duplicate, which is then printed to console output. It's not hard to have 40% "rejected" shares on console, but 99% of them are accepted by pool. This confuse users.
Those issues are related to last phoenix version and they're pretty serious. I used previous version (i think 1.50) without any problems for months, but it looks that you changed networking code. It's weird that latest phoenix is working for some users without any problems, but my miner have significant problems with that and I know about some other people reporting similar behaviour, too. I'll try to help you, just tell me what to send you. You can provide me some version with added debugging symbols or whatever. I tried to understand source codes. Although I'm familiar with Twisted, I didn't understand phoenix sources too much to fix those problems by self :-(.
|
|
|
|
RobertRibbeck - There's no difference in score using multiple worker accounts or using all miners on one account. Your round reward will be still the same. Is there any limit to the number of miners I can put on a single worker There's not any hard limit, however when I detect some botnet activity, I'll suspend that account as I did many times before. |
|
|
|
|
Show Posts
