Bitcoin Forum
December 08, 2016, 02:42:20 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 734934 times)
jedi95
Full Member
***
Offline Offline

Activity: 219


View Profile
August 22, 2011, 12:07:31 AM
 #941

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.

Phoenix Miner developer

Donations appreciated at:
1PHoenix9j9J3M6v3VQYWeXrHPPjf7y3rU
1481208140
Hero Member
*
Offline Offline

Posts: 1481208140

View Profile Personal Message (Offline)

Ignore
1481208140
Reply with quote  #2

1481208140
Report to moderator
1481208140
Hero Member
*
Offline Offline

Posts: 1481208140

View Profile Personal Message (Offline)

Ignore
1481208140
Reply with quote  #2

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

Activity: 418


View Profile
August 22, 2011, 05:56:45 AM
 #942

Yeah, for me, 1.5 is faster than 1.6.2. I'm clueless as to why.
owowo
Jr. Member
*
Offline Offline

Activity: 43


View Profile
August 23, 2011, 12:55:43 AM
 #943

for me (6850) 1.6 is faster than 1.5, about 30 Mh/s more. Shocked)
pandemic
Sr. Member
****
Offline Offline

Activity: 418


View Profile
August 23, 2011, 12:59:29 AM
 #944

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

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

Activity: 769



View Profile WWW
August 23, 2011, 05:51:44 AM
 #945

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

Liked my former work for Bitcoin Core? Drop me a donation via:
1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x
bitcoin:1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x?label=Diapolo
BkkCoins
Hero Member
*****
Offline Offline

Activity: 784


firstbits:1MinerQ


View Profile WWW
August 23, 2011, 09:20:08 AM
 #946

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

Activity: 140


View Profile
August 23, 2011, 01:22:58 PM
 #947

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

If you found this post useful, feel free to share the wealth: 1E35gTBmJzPNJ3v72DX4wu4YtvHTWqNRbM
BkkCoins
Hero Member
*****
Offline Offline

Activity: 784


firstbits:1MinerQ


View Profile WWW
August 23, 2011, 02:26:11 PM
 #948

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

Activity: 33


View Profile
August 23, 2011, 04:23:14 PM
 #949

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

Activity: 132


View Profile
August 26, 2011, 10:09:50 AM
 #950

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

Activity: 784


firstbits:1MinerQ


View Profile WWW
August 26, 2011, 11:52:10 AM
 #951

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
Member
**
Offline Offline

Activity: 65


View Profile WWW
August 27, 2011, 11:08:43 AM
 #952

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

Activity: 784


firstbits:1MinerQ


View Profile WWW
August 27, 2011, 11:16:39 AM
 #953

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

Activity: 346


View Profile
August 28, 2011, 12:30:50 AM
 #954

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
Quote
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 Tongue

i think you can take it from here.

1NEvmZTwLhqBgr3h7LwZap1sEHsyf3QFuv
deti
Member
**
Offline Offline

Activity: 65


View Profile WWW
August 28, 2011, 11:12:11 PM
 #955

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

shivansps
Sr. Member
****
Offline Offline

Activity: 346


View Profile
August 29, 2011, 05:02:37 AM
 #956

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

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

1NEvmZTwLhqBgr3h7LwZap1sEHsyf3QFuv
Meatball
Sr. Member
****
Offline Offline

Activity: 322



View Profile
August 30, 2011, 11:43:15 AM
 #957

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

Activity: 121


View Profile
September 03, 2011, 12:53:43 AM
 #958

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

Activity: 26


View Profile WWW
September 03, 2011, 11:27:04 PM
 #959

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",

Did I help you? Tiny Donations always welcome : 15Zk7DoFYJ7hESpZzmix1WLkomTMGW81c2
runeks
Legendary
*
Offline Offline

Activity: 924



View Profile WWW
September 07, 2011, 08:32:21 PM
 #960

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