Phoenix - Efficient, fast, modular miner

[owowo]

for me (6850) 1.6 is faster than 1.5, about 30 Mh/s more. )

[pandemic]

for me (6850) 1.6 is faster than 1.5, about 30 Mh/s more. )

Running a 5830, it's about 2-3mh/s slower. Not a lot but still enough to be odd in my mind.

[Diapolo]

Hey, I don't usually thread bump, but my question went completely overlooked.
I was wondering if someone could explain to me the difference between VECTORS and VECTORS2 from the Phatk2 kernel?  From my understanding of past readings, they were originally supposed to be the same.  But I'm finding that VECTORS works faster than VECTORS2 and, obviously, VECTORS4 with my HD5450.

The VECTORS command line = VECTORS2 processing, two hashes processed per iteration.
There is no parsing of a "VECTORS2" command line, if you are typing that, then both vectors options are disabled.

    VECTORS = KernelOption(
        'VECTORS', bool, default=False, advanced=True,
        help='Enable vector support in the kernel?')
    VECTORS4 = KernelOption(
        'VECTORS4', bool, default=False, advanced=True,
        help='Enable vector uint4 support in the kernel?')

VECTORS = VECTORS2

I made that change when I added phatk 2.2 to Phoenix in order to be consistent with previous versions.

I beg to differ Jedi95:
VECTORS = ~14.32 MHash/Sec
VECTORS2 = ~11.97 MHash/Sec
None = ~11.97

So it would appear that the VECTORS2 command option has been removed and VECTORS4 has been left.  So adding VECTORS2 = VECTORS might not be such a bad idea to keep the command line options open.  Either that, or the phatk 2.2 isn't actually being used.

Ok, basically what is happening is that when you specify VECTORS2 it ends up not using vectors at all since VECTORS2 is not recognized. The point I was trying to make was that VECTORS in the included phatk2 kernel functions just like VECTORS2 in the unmodified phatk 2.2 kernel.

Perhaps it would be a good idea for me to change it so that entering VECTORS or VECTORS2 will do the same thing.

I introduced the VECTORS2 option for phatk in my mod ... made more sense than only VECTORS with the addition of VECTORS4! I guess that could be the starting point of the confusion!

Dia

[BkkCoins]

I'm having a problem with Phoenix 1.48 (phatk kernel). I'm running 2 5830s at 970 and 1020. They seem stable and produce a decent hash rate. This in on Ubuntu with AMD 2.4 and 11.6 driver.

Every so often, maybe 6 hours or 12 hours, long but irregular intervals, they will just stop doing hashing.
They don't crash but they both report 0 kHash rate and just sit there. I can Ctrl-C them and start them again and they will continue fine doing hashing. But why?

Is there some place to see a log message of why they stop, or maybe enable debug output. I think it's shortly after a "idel miner" warning usually, so maybe it doesn't resume from idle under some conditions? Just guessing.

I though of adding a cron to restart things every few hours but it would be better to know why and fix it.

[bcforum]

I'm having a problem with Phoenix 1.48 (phatk kernel). I'm running 2 5830s at 970 and 1020. They seem stable and produce a decent hash rate. This in on Ubuntu with AMD 2.4 and 11.6 driver.

Every so often, maybe 6 hours or 12 hours, long but irregular intervals, they will just stop doing hashing.
They don't crash but they both report 0 kHash rate and just sit there. I can Ctrl-C them and start them again and they will continue fine doing hashing. But why?

Is there some place to see a log message of why they stop, or maybe enable debug output. I think it's shortly after a "idel miner" warning usually, so maybe it doesn't resume from idle under some conditions? Just guessing.

I though of adding a cron to restart things every few hours but it would be better to know why and fix it.

You are running into a spurious failure as a result of overclocking.

You can lower the clock rate, use the 'timeout' command to restart, or hack the client to report spending more than 30 seconds in a kernel execution.

For reference I use:

Code:

#!/bin/sh
export DISPLAY=:0
while true; do
    timeout -k 60 24h python phoenix.py -v \
	-u http://user:pass@localhost:8332 \
	-k phatk_2p2 DEVICE=0 AGGRESSION=13 BFI_INT WORKSIZE=128 \
	VECTORS FASTLOOP=false
done

You might also enjoy: https://bitcointalk.org/index.php?topic=33550.0

[BkkCoins]

Thank you bcforum. I'll give timeout a try.
I don't think I can use 24h though as I've seen it stop after even 4-6 hours.
Maybe I'll try 1h timeout.

[MegaBux]

Version 1.6.2 released.

Changes:
1. Reverted some changes in client3420 to resolve a memory leak.
2. Added logging of share reject reason if provided by the server. (Only visible with -v)
3. Fixed phatk2 errors with BFI_INT disabled.
4. Added warning to phatk2 if WORKSIZE set too large.

Thank you for your work!  Can you recommend a way to capture the sampled hashrate to a file in Windows?  The program emits various control codes to overwrite the previously printed hashrate, which makes piping the output in a file difficult to parse later on.

[carlo]

jedi, did you plan to make your "backup server" configuration more flexible ?

1) switch faster  [Y retrys than switch]
2) switch back to primary  [submit X shares to backup than switch to primary

anyway i love your miner ... donation sent !

Code:

[26/08/2011 11:59:08] Result: 42382819 rejected
[26/08/2011 11:59:23] Disconnected from server
[26/08/2011 11:59:38] Warning: work queue empty, miner is idle
[26/08/2011 11:59:49] Failed to connect, retrying...
[26/08/2011 12:00:23] Failed to connect, retrying...
[26/08/2011 12:04:33] Failed to connect, retrying...
[26/08/2011 12:04:33] Primary server failed too many times,
[26/08/2011 12:04:33] attempting to connect to backup server.
[26/08/2011 12:04:33] Connected to server
[26/08/2011 12:04:50] Result: 1168a8cb accepted

[BkkCoins]

Wow. I was having problems with auto-reconnect not happening with 1.48.
So I updated to 1.6.2 and right away got a 10 MHash/s bonus.
Haven't re-tested for auto-reconnect but expecting that may be better now too.
Brilliant! Thank You!

(This is with 2x Sapphire 5830)

How long does it wait to reconnect anyway? (This is when net connection drops out briefly)

Edit: nope, this is still having a problem. If I lose internet then it doesn't disconnect and reconnect any more. I've waited 5 minutes or so and it still just sits there. Last msg is "work queue idle" and then nothing. I have to kill the processes and restart them, and then it connects immediately and continues fine.

I'm getting crappy ISP service tonight so every 20 minutes I'm losing the link.

Edit 2: I've written a small script that detects 0% utilization and reloads phoenix. With 1.6.2 that I'm using it simply does not detect network down and try to reconnect. It may work for other reasons but when my ISP connection drops Phoenix hangs with "work queue empty" message.

By forcing a reload of Phoenix it then starts trying to connect, retrying until it does. I would have thought that Phoenix would try to reconnect on it's own when the network drops out.

[deti]

.... I would have thought that Phoenix would try to reconnect on it's own when the network drops out.

For me Phoenix does reconnect. If I pull my LAN cable out of the computer the miner becomes idle after some seconds. When I connect the cable again with the computer the miner starts after less then one minute to work again. This is with Phoenix-files from yesterday downloaded from github.

[BkkCoins]

.... I would have thought that Phoenix would try to reconnect on it's own when the network drops out.

For me Phoenix does reconnect. If I pull my LAN cable out of the computer the miner becomes idle after some seconds. When I connect the cable again with the computer the miner starts after less then one minute to work again. This is with Phoenix-files from yesterday downloaded from github.

I wonder if it depends on how the connection goes down. In my case my LAN still works, so the miner still has a good network connection, but at the gateway the connection drops, so Phoenix cannot talk to the pool server. It just stops and never recovers. I had it in this state for 24 hours a few days back, but today it's been short 20 minute ISP issues. That why I wrote a script to detect the utilization dropping to 0.

Well, for now my ISP has cleared up the issues pretty much. But I keep my "minewatch" script running just in case since it will catch and restart Phoenix for me.

[shivansps]

All I want to see in the logfile is the time, the speed, the accepted/rejected number and the result. How can I do that?

see my script:

......................

Thanks Zwenny for your workaround, it's a nice idea, but I am asking to the developers for a build-in way to print the output in a nice format into a file. For example in this way:

./phoenix.py -u http://xyz:123456@mineco.in:3000/ -f /path/to/my/miner_log.txt  -k poclbm DEVICE=0 VECTORS BFI_INT FASTLOOP=false AGGRESSION=13

I already done it some months ago...

https://bitcointalk.org/index.php?topic=27761.0

You ill need to change a few things in ConsoleLogger.py in order to work 100% as you want, the file write line should be like this to add time

fileHandle.write(datetime.now().strftime(self.TIME_FORMAT) + '  ' + status)

man i love python, in order to do the above in C++ i need to do a few strcats

i think you can take it from here.

[deti]

I already done it some months ago...

https://bitcointalk.org/index.php?topic=27761.0

You ill need to change a few things ....

Thanks for the link shivansps! I will use the XML-RPC method mentioned in post #7 of your thread.

[shivansps]

I already done it some months ago...

https://bitcointalk.org/index.php?topic=27761.0

You ill need to change a few things ....

Thanks for the link shivansps! I will use the XML-RPC method mentioned in post #7 of your thread.

yeah it depends of what you need to do... personally im just outputing to a html web page where all my miners are displayed.

[Meatball]

jedi, did you plan to make your "backup server" configuration more flexible ?

1) switch faster  [Y retrys than switch]
2) switch back to primary  [submit X shares to backup than switch to primary

anyway i love your miner ... donation sent !

+1 to this.

[noob_jul11]

why is version 1.5 and 1.6 not posted at https://en.bitcoin.it/wiki/Phoenix_miner ??

[generalfault]

jedi, did you plan to make your "backup server" configuration more flexible ?

1) switch faster  [Y retrys than switch]
2) switch back to primary  [submit X shares to backup than switch to primary

anyway i love your miner ... donation sent !

+1 to this.

I posted this over in newbies awhile ago.... seems like it never made it over.
This is a patch that allows falling back to the primary:

Code:

diff -Naur phoenix-1.6.1/Miner.py phoenix-test/Miner.py
--- phoenix-1.6.1/Miner.py	2011-08-15 13:27:10.000000000 -0500
+++ phoenix-test/Miner.py	2011-08-18 10:34:50.000000000 -0500
@@ -42,6 +42,7 @@
         self.idle = True
         self.cores = []
         self.backup = False
+	self.backupLife = 0
         self.failures = 0
         self.lastMetaRate = 0.0
         self.lastRateUpdate = time()
@@ -65,6 +66,25 @@
     def onWork(self, work):
         self.logger.reportDebug('Server gave new work; passing to WorkQueue')
         self.queue.storeWork(work)
+        if self.backup:
+            #When the backup life reaches 0, switch back to the primary pool
+            if (self.backupLife <= 0):
+                #disconnect and set connection to none
+                self.connection.disconnect()
+                self.connection = None
+                
+                #log
+                self.logger.log("Backup Lifespan finished,")
+                self.logger.log("attempting to return to primary server.")
+                
+                #reset failure count and return to primary server
+                self.failures = 0
+                self.backup = False
+                self.connection = self.options.makeConnection(self)
+                self.connection.connect()
+            else:
+                self.backupLife -= 1
+                
     def onLongpoll(self, lp):
         self.logger.reportType('RPC' + (' (+LP)' if lp else ''))
     def onPush(self, ignored):
@@ -73,9 +93,10 @@
         self.logger.log(message)
     def onDebug(self, message):
         self.logger.reportDebug(message)
-    
+
     def failoverCheck(self):
         if self.backup:
+            #The backup pool must fail 3 times before moving to the backup pool
             if (self.failures >= 1):
                 #disconnect and set connection to none
                 self.connection.disconnect()
@@ -106,6 +127,10 @@
                 #reset failure count and connect to backup server
                 self.failures = 0
                 self.backup = True
+		self.backupLife = 20
+                if self.options.backupLife is not None:
+                    self.backupLife = self.options.backupLife
+
                 self.connection = self.options.makeConnection(self, True)
                 self.connection.connect()
             else:
diff -Naur phoenix-1.6.1/phoenix.py phoenix-test/phoenix.py
--- phoenix-1.6.1/phoenix.py	2011-08-15 13:27:10.000000000 -0500
+++ phoenix-test/phoenix.py	2011-08-18 10:31:29.000000000 -0500
@@ -40,6 +40,7 @@
         self.parsedSettings = None
         self.url = None
         self.url2 = None
+	self.backupLife = None
         self.logger = None
         self.kernel = None
         self.queue = None
@@ -57,6 +58,9 @@
         parser.add_option("-b", "--backupurl", dest="url2", default=None,
             help="the URL of the backup mining server to work for if the "
             "primary is down [OPTIONAL]")
+        parser.add_option("-f", "--fallback", dest="backupLife", default=None,
+            help="the number of getworks when on the backup mining server "
+            "before retrying the primary server [OPTIONAL]")
         parser.add_option("-q", "--queuesize", dest="queuesize", type="int",
             default=1, help="how many work units to keep queued at all times")
         parser.add_option("-a", "--avgsamples", dest="avgsamples", type="int",

[runeks]

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. Using Phoenix with a HD5770 gives me 222 MH/s consistently (phatk2 kernel, 960/300 core/mem.).

How often are results posted back to the mining server? I mean, can I safely just Ctrl+C to exit when Phoenix is running, or will I lose some work I have made that isn't reported to the server?
The reason I ask is because at aggression level 12 I get 222 MH/s consistently, rock stable. It doesn't vary more than 1 MH/s max. But this renders my computer useless. When the aggression is set to 4 I can use my computer with 90% (it seems) of graphics performance available. But at this aggression level I only get around 200 MH/s, so naturally I would like to set the aggression level to 12 when I leave my computer, and 4 when I'm using it. But I'm wondering if it's safe to just exit out of the running process without losing work (there is no other way to exit than Ctrl+C is there?).

[iopq]

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

[runeks]

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