Topic: Phoenix - Efficient, fast, modular miner - page 9. (Read 760690 times)
Ok so I installed 1.64 (replacing 1.50) and my 5870s perform about 10 MH/s faster. However, my 5970 is about 10 MH/s slower per core, so I guess it's a wash. Anybody have any tips on parameters for a 5970? I'm currently using BFI_INT VECTORS FASTLOOP=FALSE AGGRESSION=11 WORKSIZE=256 -k phatk2 and getting about 390 MH/s per core at 910/200MHz.
RPCProtocol.py:
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).
Code:
@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))
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?
[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 :-(.
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 :-(.
In latest version of the miner - trunk, r116 I suddenly had problems connecting to slush pool. It happened during the night:
[28/09/2011 04:42:29] Result: e05b84c0 accepted
[28/09/2011 04:42:59] Warning: work queue empty, miner is idle
[28/09/2011 05:00:43] LP: New work pushed
[28/09/2011 05:00:51] Result: 3f3f23d6 accepted
[28/09/2011 05:00:52] Warning: work queue empty, miner is idle
[28/09/2011 05:00:53] Result: 33f0b535 accepted
[28/09/2011 05:16:10] LP: New work pushed
[28/09/2011 05:16:14] Result: 6ae50336 accepted
[28/09/2011 05:16:19] Warning: work queue empty, miner is idle
[28/09/2011 05:23:41] LP: New work pushed
[28/09/2011 05:24:22] Result: db505608 accepted
[28/09/2011 05:47:44] LP: New work pushed
[28/09/2011 05:52:37] LP: New work pushed
...
...
[28/09/2011 12:37:53] LP: New work pushed
[28/09/2011 12:41:14] LP: New work pushed
[395.96 Mhash/sec] [2939 Accepted] [2 Rejected] [RPC (+LP)]
The most strange thing is that it keeps accepting new pushes, is mining at [395.96 Mhash/sec] but does not submit any shares.
This is from one GPU, on another GPU it looked following:
[28/09/2011 04:43:39] Result: fb280402 accepted
[28/09/2011 04:43:48] Result: a12db3d3 accepted
[28/09/2011 04:43:56] Result: a4d132b6 accepted
[28/09/2011 04:44:30] Warning: work queue empty, miner is idle
[28/09/2011 05:00:43] LP: New work pushed
[28/09/2011 05:00:56] Warning: work queue empty, miner is idle
[28/09/2011 05:16:10] LP: New work pushed
[28/09/2011 05:16:23] Warning: work queue empty, miner is idle
[28/09/2011 05:23:41] LP: New work pushed
...
[28/09/2011 12:31:13] LP: New work pushed
[28/09/2011 12:31:26] Warning: work queue empty, miner is idle
[28/09/2011 12:33:55] LP: New work pushed
[28/09/2011 12:34:09] Warning: work queue empty, miner is idle
[28/09/2011 12:37:53] LP: New work pushed
[28/09/2011 12:38:06] Warning: work queue empty, miner is idle
[28/09/2011 12:41:14] LP: New work pushed
[28/09/2011 12:41:27] Warning: work queue empty, miner is idle
[0 Khash/sec] [2172 Accepted[28/09/2011 13:04:47]
This problem happened on all 9 GPUs. While previously, before upgrading to latest trunk, I was using phoenix for months without any problems.
It is possible that maybe around time [28/09/2011 04:44:30] there is some connection problem, while usually my internet connection is really good. But the most strange thing is that phoenix did not recover the connection.
[28/09/2011 04:42:29] Result: e05b84c0 accepted
[28/09/2011 04:42:59] Warning: work queue empty, miner is idle
[28/09/2011 05:00:43] LP: New work pushed
[28/09/2011 05:00:51] Result: 3f3f23d6 accepted
[28/09/2011 05:00:52] Warning: work queue empty, miner is idle
[28/09/2011 05:00:53] Result: 33f0b535 accepted
[28/09/2011 05:16:10] LP: New work pushed
[28/09/2011 05:16:14] Result: 6ae50336 accepted
[28/09/2011 05:16:19] Warning: work queue empty, miner is idle
[28/09/2011 05:23:41] LP: New work pushed
[28/09/2011 05:24:22] Result: db505608 accepted
[28/09/2011 05:47:44] LP: New work pushed
[28/09/2011 05:52:37] LP: New work pushed
...
...
[28/09/2011 12:37:53] LP: New work pushed
[28/09/2011 12:41:14] LP: New work pushed
[395.96 Mhash/sec] [2939 Accepted] [2 Rejected] [RPC (+LP)]
The most strange thing is that it keeps accepting new pushes, is mining at [395.96 Mhash/sec] but does not submit any shares.
This is from one GPU, on another GPU it looked following:
[28/09/2011 04:43:39] Result: fb280402 accepted
[28/09/2011 04:43:48] Result: a12db3d3 accepted
[28/09/2011 04:43:56] Result: a4d132b6 accepted
[28/09/2011 04:44:30] Warning: work queue empty, miner is idle
[28/09/2011 05:00:43] LP: New work pushed
[28/09/2011 05:00:56] Warning: work queue empty, miner is idle
[28/09/2011 05:16:10] LP: New work pushed
[28/09/2011 05:16:23] Warning: work queue empty, miner is idle
[28/09/2011 05:23:41] LP: New work pushed
...
[28/09/2011 12:31:13] LP: New work pushed
[28/09/2011 12:31:26] Warning: work queue empty, miner is idle
[28/09/2011 12:33:55] LP: New work pushed
[28/09/2011 12:34:09] Warning: work queue empty, miner is idle
[28/09/2011 12:37:53] LP: New work pushed
[28/09/2011 12:38:06] Warning: work queue empty, miner is idle
[28/09/2011 12:41:14] LP: New work pushed
[28/09/2011 12:41:27] Warning: work queue empty, miner is idle
[0 Khash/sec] [2172 Accepted[28/09/2011 13:04:47]
This problem happened on all 9 GPUs. While previously, before upgrading to latest trunk, I was using phoenix for months without any problems.
It is possible that maybe around time [28/09/2011 04:44:30] there is some connection problem, while usually my internet connection is really good. But the most strange thing is that phoenix did not recover the connection.
donated knickknack -phatk2
donated knicknack
After the error appears, posting the content of /var/log/Xorg.0.log would be useful.
Are you using LinuxCoin?
You might need to create a new xorg.conf file.
First back up you existing xorg.conf file:
Then tell the program aticonfig to create a new Xorg configuration file:
Then restart your computer.
Are you using LinuxCoin?
You might need to create a new xorg.conf file.
First back up you existing xorg.conf file:
Code:
sudo cp /etc/X11/xorg.conf /etc/X11/xorg.conf.bak
Then tell the program aticonfig to create a new Xorg configuration file:
Code:
sudo aticonfig --adapter=all --initial
Then restart your computer.
I just add a new VGA to a rig, now it has 5 vga.
When i try to start mining i have this problem:
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 141 (ATIFGLEXTENSION)
Minor opcode of failed request: 67 ()
Value in failed request: 0x17
Serial number of failed request: 18
Current serial number in output stream: 18
dont know why....
When i try to start mining i have this problem:
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 141 (ATIFGLEXTENSION)
Minor opcode of failed request: 67 ()
Value in failed request: 0x17
Serial number of failed request: 18
Current serial number in output stream: 18
dont know why....
Did you make a new Xorg.conf and reboot?
Will do now.
I just add a new VGA to a rig, now it has 5 vga.
When i try to start mining i have this problem:
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 141 (ATIFGLEXTENSION)
Minor opcode of failed request: 67 ()
Value in failed request: 0x17
Serial number of failed request: 18
Current serial number in output stream: 18
dont know why....
When i try to start mining i have this problem:
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 141 (ATIFGLEXTENSION)
Minor opcode of failed request: 67 ()
Value in failed request: 0x17
Serial number of failed request: 18
Current serial number in output stream: 18
dont know why....
Did you make a new Xorg.conf and reboot?
I just add a new VGA to a rig, now it has 5 vga.
When i try to start mining i have this problem:
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 141 (ATIFGLEXTENSION)
Minor opcode of failed request: 67 ()
Value in failed request: 0x17
Serial number of failed request: 18
Current serial number in output stream: 18
dont know why....
When i try to start mining i have this problem:
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 141 (ATIFGLEXTENSION)
Minor opcode of failed request: 67 ()
Value in failed request: 0x17
Serial number of failed request: 18
Current serial number in output stream: 18
dont know why....
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?
I've had the same, noticed it since the beta rpc code was removed.
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?
Right you are. I just looked at the source code and phoenix' phatk2 and cgminer's phatk appear to be almost the same.
Well I am really missing a way to change the aggression level on the fly with Phoenix, would be nice to have that.
Would you happen to know how to run/build cgminer with the phatk2 kernel? I'm getting ~1.5% extra performance with the phatk2 kernel compared to phatk (using Phoenix) using these options: VECTORS BFI_INT FASTLOOP=false WORKSIZE=256 AGGRESSION=12.
cgminer already comes with phatk2 Would you happen to know how to run/build cgminer with the phatk2 kernel? I'm getting ~1.5% extra performance with the phatk2 kernel compared to phatk (using Phoenix) using these options: VECTORS BFI_INT FASTLOOP=false WORKSIZE=256 AGGRESSION=12.
Well I am really missing a way to change the aggression level on the fly with Phoenix, would be nice to have that.
Would you happen to know how to run/build cgminer with the phatk2 kernel? I'm getting ~1.5% extra performance with the phatk2 kernel compared to phatk (using Phoenix) using these options: VECTORS BFI_INT FASTLOOP=false WORKSIZE=256 AGGRESSION=12.
Would you happen to know how to run/build cgminer with the phatk2 kernel? I'm getting ~1.5% extra performance with the phatk2 kernel compared to phatk (using Phoenix) using these options: VECTORS BFI_INT FASTLOOP=false WORKSIZE=256 AGGRESSION=12.
^ Thanks for the tip. Do you have reason to believe that with cgminer I will get above 222 Mhash/sec with my 5770? Cause if not, I'd rather not have to build cgminer with GPU support. It took a while to do with just CPU support. I didn't mean to say cgminer isn't as good as Phoenix, they're probably about the same since they use the same kernels.
same speed since the kernels are the samebut it has very nice options like changing settings while it's running instead of having to restart it
^ Thanks for the tip. Do you have reason to believe that with cgminer I will get above 222 Mhash/sec with my 5770? Cause if not, I'd rather not have to build cgminer with GPU support. It took a while to do with just CPU support. I didn't mean to say cgminer isn't as good as Phoenix, they're probably about the same since they use the same kernels.
Thanks for creating this miner! I started out with cgminer, which - admittedly - I didn't spend a lot of time configuring when I was only getting 180MH/s max.
try -w 256 -v 2 -I 8 Jump to: