Phoenix - Efficient, fast, modular miner

[iopq]

^ 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]

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]

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]

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

[slush]

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]

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]

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]

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?

[oo-oo]

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]

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]

donated knicknack

[Lord F(r)og]

donated knickknack -phatk2

[cosurgi]

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]

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]

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]

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]

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]

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.

[ssateneth]

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.

Where did you find phoenix 1.64? Latest that's publicly out is 1.6.2.

[generalfault]

Is there any way to get immediate data out of a Phoenix instance - for example, the hashrate, the results accepted / rejected, and the last status message / timestamp?

Or, since I'm not a Linux god (my Unix skills come from being a Mac OS X guru) - is there any funky file type I can use that I can send the stdout from Phoenix to, and be able to read it from Ruby, but can be 'trimmed' on regular occasions (i.e. removing the old entries), or one that can be set to a specific size which it won't grow any larger than? Sort of like a FIFO but allowing, say, 32K of log text to build up before dropping the first bytes in?

So, I liked that question for some reason. (most likly cause I had a similar problem.)
Here is a little perl script:

Code:

#!/usr/bin/perl

my @s;
$/ = "\b";
while(<>){
        next if(! m/^\[/);
        chomp;
        print "$_\n";
        if(push(@s,$_) > 20 or m/(Result|New Work)/ ){
                open(FH,">>","out.log"); 
                print FH join("\n",@s)."\n";
                close FH;
                @s = ();
                }
        }

you'd just pipe the output of phoenix into it:
./phoenix blah blah blah |./logger

It spools up to 20 lines and writes them out to out.log

if you are parsing out.log then you'd just:
mv out.log out.log.parsing
<parse the out.log.parsing file>
rm out.log.parsing

and a new out.log will be created.