Bitcoin Forum
December 08, 2016, 06:06:40 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 [49] 50 51 52 53 54 55 56 57 »
  Print  
Author Topic: Phoenix - Efficient, fast, modular miner  (Read 734945 times)
iopq
Hero Member
*****
Offline Offline

Activity: 644


View Profile
September 08, 2011, 12:56:59 AM
 #961

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

1481220400
Hero Member
*
Offline Offline

Posts: 1481220400

View Profile Personal Message (Offline)

Ignore
1481220400
Reply with quote  #2

1481220400
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481220400
Hero Member
*
Offline Offline

Posts: 1481220400

View Profile Personal Message (Offline)

Ignore
1481220400
Reply with quote  #2

1481220400
Report to moderator
1481220400
Hero Member
*
Offline Offline

Posts: 1481220400

View Profile Personal Message (Offline)

Ignore
1481220400
Reply with quote  #2

1481220400
Report to moderator
1481220400
Hero Member
*
Offline Offline

Posts: 1481220400

View Profile Personal Message (Offline)

Ignore
1481220400
Reply with quote  #2

1481220400
Report to moderator
runeks
Legendary
*
Offline Offline

Activity: 924



View Profile WWW
September 08, 2011, 10:37:20 AM
 #962

^ 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.
iopq
Hero Member
*****
Offline Offline

Activity: 644


View Profile
September 08, 2011, 04:01:52 PM
 #963

^ 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 same
but it has very nice options like changing settings while it's running instead of having to restart it

runeks
Legendary
*
Offline Offline

Activity: 924



View Profile WWW
September 08, 2011, 05:06:19 PM
 #964

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.
iopq
Hero Member
*****
Offline Offline

Activity: 644


View Profile
September 09, 2011, 01:33:29 AM
 #965

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

runeks
Legendary
*
Offline Offline

Activity: 924



View Profile WWW
September 11, 2011, 01:06:18 PM
 #966

Right you are. I just looked at the source code and phoenix' phatk2 and cgminer's phatk appear to be almost the same.
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
September 22, 2011, 12:10:29 PM
 #967

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?

MiningBuddy
Moderator
Legendary
*
Offline Offline

Activity: 1058


฿itcoin ฿itcoin ฿itcoin


View Profile
September 23, 2011, 02:57:27 AM
 #968

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.

oo-oo
Jr. Member
*
Offline Offline

Activity: 37


View Profile
September 24, 2011, 12:10:00 AM
 #969

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....
bcforum
Full Member
***
Offline Offline

Activity: 140


View Profile
September 24, 2011, 03:05:46 PM
 #970

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....

Did you make a new Xorg.conf and reboot?

If you found this post useful, feel free to share the wealth: 1E35gTBmJzPNJ3v72DX4wu4YtvHTWqNRbM
oo-oo
Jr. Member
*
Offline Offline

Activity: 37


View Profile
September 24, 2011, 04:28:16 PM
 #971

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....

Did you make a new Xorg.conf and reboot?


Will do now.
runeks
Legendary
*
Offline Offline

Activity: 924



View Profile WWW
September 24, 2011, 04:32:43 PM
 #972

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:

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.
Lord F(r)og
Donator
Sr. Member
*
Offline Offline

Activity: 477



View Profile
September 25, 2011, 06:11:54 PM
 #973

donated knicknack
Lord F(r)og
Donator
Sr. Member
*
Offline Offline

Activity: 477



View Profile
September 25, 2011, 06:29:51 PM
 #974

donated knickknack -phatk2
cosurgi
Sr. Member
****
Offline Offline

Activity: 298


View Profile
September 28, 2011, 12:14:25 PM
 #975

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.

slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
September 28, 2011, 08:44:05 PM
 #976

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 :-(.

slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
September 28, 2011, 09:16:10 PM
 #977

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...

slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
September 29, 2011, 12:52:37 AM
 #978

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?

slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
September 29, 2011, 01:49:00 AM
 #979

RPCProtocol.py:
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))

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).

Mousepotato
Hero Member
*****
Offline Offline

Activity: 896


Seal Cub Clubbing Club


View Profile
October 02, 2011, 03:12:24 AM
 #980

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.

Mousepotato
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 [49] 50 51 52 53 54 55 56 57 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!