Pages:
Author

Topic: Phoenix - Efficient, fast, modular miner - page 20. (Read 760839 times)

member
Activity: 78
Merit: 10
Get a CPU with hyper-threading (and 6-cores) and your miners will work among 12 virtual cores.  Having said that, there is something wrong (i.e. very slow CPU, bus and memory perhaps) if your miners are maxing out a CPU core when GPU mining.  I had two cards mining in my main desktop machine [i7 960 3.2GHz quad-core with hyper-threading] and never saw any spikes on any CPU core [of all 8 virtual that show in task manager or other tool].

Are you mining with ATI cards Veldy? AFAIK they always max out at least one core when one mines on them on Windows. If they don't on your system, care to describe your setup for others to replicate? Thanks!
member
Activity: 98
Merit: 10
Hey, I have a question about using multiple GPU mining.  One thing that I've noticed is that the GPU miner tends to use one CPU core per GPU.  Having OpenCL capable CPUs makes this more of a problem since the GPU miners can actually run on the CPU cores, but let's not get into that.  Anyhow, I wanted to ask if what I said is accurate as to one CPU core per GPU since I'm hoping to put together a 4x HD6990 rig and can only really find 6 core CPUs.  If it won't work, then I won't invest in the 4th and useless card.  So I need someone to fill me in before I do something stupid.

Thanks!

Edit:  I have posted this question in this thread since I will most likely be using this miner until I find that one works better than another.  So my question applies mainly to this miner.  Feel free to answer for other miner programs too if their mining methods would change the outcome of the answer.

Get a CPU with hyper-threading (and 6-cores) and your miners will work among 12 virtual cores.  Having said that, there is something wrong (i.e. very slow CPU, bus and memory perhaps) if your miners are maxing out a CPU core when GPU mining.  I had two cards mining in my main desktop machine [i7 960 3.2GHz quad-core with hyper-threading] and never saw any spikes on any CPU core [of all 8 virtual that show in task manager or other tool].
newbie
Activity: 23
Merit: 0
Does 1.5ver supports backup pool (--backup=...) like the newest poclbm?


Where did You find poclbm that supports backup pool? Please support me with link.
You can find out with ./poclbm.py --help

The usage is adding --backup=worker_name:worker_pass@hostname:port. This new feature saved me sometimes Smiley
member
Activity: 98
Merit: 10
Poclbm has backup feature now. Just enter their thread, go to source and u can see there 17 june version. It just need to be compiled.
hero member
Activity: 626
Merit: 500
Mining since May 2011.
Does 1.5ver supports backup pool (--backup=...) like the newest poclbm?


Where did You find poclbm that supports backup pool? Please support me with link.

I have never heard of a client that supports a native mechanism of a backup pool, as in "the primary is down, use backup". I have only read and have it setup through running multiple instances with either the -f30 (primary) and -f60 (backup) for poclmb, or with the aggression=11 (primary) and aggression=5 (backup) for phoenix. (those are just example numbers, choose what works for best for your miner)

And yes, a portion of the 2nd instance will be sending shares to the backup, adjusting the -f or aggression= numbers varies that load.

If anyone knows a way to make it 100% on primary, 0% on backup, then if there is a failure make the switch to the backup I'd love to see it.
member
Activity: 98
Merit: 10
Does 1.5ver supports backup pool (--backup=...) like the newest poclbm?


Where did You find poclbm that supports backup pool? Please support me with link.
newbie
Activity: 40
Merit: 0
Sorry if this question occured earlier ITT, but what exactly is the -q parameter? How does it work?

-q tells Phoenix to keep more than one work unit in its "to-do" queue. Advantage: When the miner can't immediately get new work from the pool server, it will have something to do anyway. Disadvantage: the amount of done work that has to be discarded when a new block is found by somebody else is higher.

So you might want to experiment with slightly increasing the value above 1 especially if you're mining on a rig with very high speed per GPU core. But don't go too high or you'll lose efficiency again due to more rejected shares.

So this setting is only for high speed GPUs?

What I find somewhat weird is that I (with my crappy 35mh/s gpu) dont seem to get new work properly. I posted my prop in another thread: http://forum.bitcoin.org/index.php?topic=21330.0

Whenever I produce a rejected result within a block, I cant submit an accepted one after that until a new Block is started. However, when I restart phoenix I can.  I dont know if this has something to do with -q, but I am testing several values atm in testnet to get some comparion.
member
Activity: 78
Merit: 10
Sorry if this question occured earlier ITT, but what exactly is the -q parameter? How does it work?

-q tells Phoenix to keep more than one work unit in its "to-do" queue. Advantage: When the miner can't immediately get new work from the pool server, it will have something to do anyway. Disadvantage: the amount of done work that has to be discarded when a new block is found by somebody else is higher.

So you might want to experiment with slightly increasing the value above 1 especially if you're mining on a rig with very high speed per GPU core. But don't go too high or you'll lose efficiency again due to more rejected shares.
newbie
Activity: 40
Merit: 0
Sorry if this question occured earlier ITT, but what exactly is the -q parameter? How does it work?

Appreciate ur help.
newbie
Activity: 4
Merit: 0
Hey, I have a question about using multiple GPU mining.  One thing that I've noticed is that the GPU miner tends to use one CPU core per GPU.  Having OpenCL capable CPUs makes this more of a problem since the GPU miners can actually run on the CPU cores, but let's not get into that.  Anyhow, I wanted to ask if what I said is accurate as to one CPU core per GPU since I'm hoping to put together a 4x HD6990 rig and can only really find 6 core CPUs.  If it won't work, then I won't invest in the 4th and useless card.  So I need someone to fill me in before I do something stupid.

Thanks!

Edit:  I have posted this question in this thread since I will most likely be using this miner until I find that one works better than another.  So my question applies mainly to this miner.  Feel free to answer for other miner programs too if their mining methods would change the outcome of the answer.

I had the same issue. My guess is that you're running at a pretty high aggression. I was running at aggression 12 and getting ~13% CPU usage across all 8 cores (really 4 cores with hyperthreading). You can set the affinity so it only runs on one core, and then I got ~95% CPU usage on just that core, or you can just turn down the aggression.

It took me hours of googling before someone suggested it, but simply going to aggression 9 dropped my CPU usage to 0. My hash rate is about the same and Windows is more responsive. The only downside is that my hashrate drops ~3 MHashs/s when I do things like move windows around or use any aero features.

I'd guess that the max aggression level before you run into CPU usage issues is different for each card, but just try going lower one at a time; from 10 to 9 was like night and day for me.
member
Activity: 78
Merit: 10
Could you guys please tell me how to properly compile the source for this? I am no good with python, and I am having trouble compiling the source into a standalone exe..
I have tried with py2exe, but the resulting exe has a lot of dependencies. My exe is 22kB while the official exe is ~6800kB
I don't expect anyone to make a tutorial, but it would be nice to be pointed in the right direction.

Do you actually need a standalone exe? Or could you live with running your modified miner on Python? If the latter, check out the "Howto run Phoenix SVN" sticky on the Bitcoinpool.com forum, board "Miner discussion".
member
Activity: 78
Merit: 10
Hey, I have a question about using multiple GPU mining.  One thing that I've noticed is that the GPU miner tends to use one CPU core per GPU.  Having OpenCL capable CPUs makes this more of a problem since the GPU miners can actually run on the CPU cores, but let's not get into that.  Anyhow, I wanted to ask if what I said is accurate as to one CPU core per GPU since I'm hoping to put together a 4x HD6990 rig and can only really find 6 core CPUs.  If it won't work, then I won't invest in the 4th and useless card.  So I need someone to fill me in before I do something stupid.

The CPU is maxed out but it's not actually used very much by Phoenix for any real work, typically less than 2% is real use. I'm not sure what it's actually doing all the time but I guess it's constantly polling the GPU to check whether it's done with its current bit of work. In Windows, use something like

start /affinity 0x8 phoenix.exe .....

to get all your miners to run on only one CPU core (not one each, but all on one, I use CPU #3, the last one of my 4 core CPU with numbering starting at 0, hence the 8 which is 2 to the 3rd power). Then only that one core will be maxed out, without any noticeable loss in mining speed. I run the Ufasoft CPU miner on the other cores to get a bit more out of the rig.

On Linux, you can prevent the CPU hogging altogether by saying

export GPU_USE_SYNC_OBJECTS=1

before you start the miner(s).
newbie
Activity: 10
Merit: 0
I am trying to make a slightly modified version of the phoenix miner (specifically I want to make the output stream unbuffered)

Could you guys please tell me how to properly compile the source for this? I am no good with python, and I am having trouble compiling the source into a standalone exe..
I have tried with py2exe, but the resulting exe has a lot of dependencies. My exe is 22kB while the official exe is ~6800kB
I don't expect anyone to make a tutorial, but it would be nice to be pointed in the right direction.

Thank you.

- CptHook
sr. member
Activity: 378
Merit: 250
Hey, I have a question about using multiple GPU mining.  One thing that I've noticed is that the GPU miner tends to use one CPU core per GPU.  Having OpenCL capable CPUs makes this more of a problem since the GPU miners can actually run on the CPU cores, but let's not get into that.  Anyhow, I wanted to ask if what I said is accurate as to one CPU core per GPU since I'm hoping to put together a 4x HD6990 rig and can only really find 6 core CPUs.  If it won't work, then I won't invest in the 4th and useless card.  So I need someone to fill me in before I do something stupid.

Thanks!

Edit:  I have posted this question in this thread since I will most likely be using this miner until I find that one works better than another.  So my question applies mainly to this miner.  Feel free to answer for other miner programs too if their mining methods would change the outcome of the answer.
sr. member
Activity: 386
Merit: 334
-"When the going gets weird, the weird turn pro."
Quote
[16/06/2011 20:21:48] Server gave new work; passing to WorkQueue
[16/06/2011 20:22:01] Result 000000002f4255ac... accepted
[16/06/2011 20:22:06] Result 00000000956163ae... accepted
[16/06/2011 20:22:08] Result 000000006244c69e... accepted
[16/06/2011 20:22:15] Server gave new work; passing to WorkQueue
[16/06/2011 20:22:42] Server gave new work; passing to WorkQueue
[16/06/2011 20:23:08] Result 0000000068e4507d... rejected
[16/06/2011 20:23:08] Result 00000000e2b80025... rejected
[16/06/2011 20:23:09] Server gave new work; passing to WorkQueue
[16/06/2011 20:23:10] New block (WorkQueue)
[16/06/2011 20:23:13] Result 000000003717b83f... accepted
[16/06/2011 20:23:25] Result 00000000706aa557... accepted
[16/06/2011 20:23:28] Result 00000000edf564dc... accepted
[16/06/2011 20:23:37] Warning: work queue empty, miner is idle
[0 Khash/sec] [859 Accepted] [23 Rejected] [RPC (+LP)]
v1.50
did not restart for two hours...

Seven other miner instances worked fine, one of them on the same GPU. Could it be something with the socket connection?

anything we can do to help debug?

I'm assuming you are running Linux?

Code:
$ sudo sysctl -a | grep tcp_keepalive

net.ipv4.tcp_keepalive_time = 7200
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_intvl = 75

Those are the default kernel parameters when running Linux (Ubuntu 11.04). First one gives keeps the TCP/IP connection alive for two hours (7200 seconds) without ack (eg. if you pull the network cable), second one is how many times it will try to reconnect/probe, and third one is how many seconds it will perform each probe. Only after all this is done will the application (python binary in this case) get the socket call terminated when the TCP/IP connection is bork.

I've only had the hang you describe once so far, all other times phoenix handles this. I think it depends on how the connection is broken against the pool, and somehow bypasses the exception handling in Phyton.

Anyway, to change the kernel parameters dynamically (until next reboot) you can issue this command.

Code:
sudo sysctl -w net.ipv4.tcp_keepalive_time=60 net.ipv4.tcp_keepalive_probes=3 net.ipv4.tcp_keepalive_intvl=10

This will give a reconnection after one minute (60 seconds), and do three probe attempts lasting 10 seconds each.

To change permanently you can edit /etc/sysctl.conf (as root) with your favorite editor and add these lines.

Code:
net.ipv4.tcp_keepalive_time=60
net.ipv4.tcp_keepalive_probes=3
net.ipv4.tcp_keepalive_intvl=10

Let me know if it seems to work for you.
Ali
member
Activity: 84
Merit: 10
I'm using Phoenix on OSX 10.6 . Either I'm really unlucky or it couldn't find a single share within the last 30 minutes at 60 Mhash/s. New work gets pushed though.
What could be going wrong?

Here's some output:

[22/06/2011 15:58:54] Phoenix 1.50 starting...
[22/06/2011 15:58:54] Connected to server
[22/06/2011 16:20:06] LP: New work pushed               
[22/06/2011 16:24:50] LP: New work pushed             
[22/06/2011 16:28:58] LP: New work pushed             
[22/06/2011 16:31:18] LP: New work pushed             
[57.95 Mhash/sec] [0 Accepted] [0 Rejected] [RPC (+LP)]
newbie
Activity: 23
Merit: 0
Does 1.5ver supports backup pool (--backup=...) like the newest poclbm?
newbie
Activity: 9
Merit: 0
After a halt, one of my systems got this strange error when starting a miner:

File "phoenix.py", line 18
SyntaxError: Non-ASCII character '\xd4' in file phoenix.py on line 18, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details

After a fresh re-install of the phoenix miner that error was gone and the miners started normally. I am running an Ubuntu 10.10 with phoenix 1.50.

 
member
Activity: 78
Merit: 10
After losing a weekend's worth of mining when my computer locked up while I was 300km away from it, I've coded support for a QUANCOM hardware watchdog card into Phoenix. It starts the timer when Phoenix starts and re-triggers it whenever a share has been accepted by the server. If there is any prolonged problem (server unresponsive, network problem, GPU refusing to work, computer locked up...) the watchdog will short the reset switch pins on the mainboard after a few minutes and thus cause a hard reboot. Of course the miner is set to auto-start with Windows.

The patch is fairly simple and probably not as pretty as it could be (I'm entirely new to Python coding), and it would have to be modified for Linux, but it does the job for now. If anybody is interested in it please send me a message.
legendary
Activity: 1762
Merit: 1011
Quote
MSG: upstream RPC error                                    
[18/06/2011 01:29:06] Disconnected from server              
[18/06/2011 01:29:18] Warning: work queue empty, miner is idle
[18/06/2011 01:29:19] Result: d8d7ccc4 accepted  
[18/06/2011 01:29:19] Connected to server        
[18/06/2011 01:29:43] Warning: work queue empty, miner is idle
[18/06/2011 01:31:13] Result: c8b213d5 accepted        
[18/06/2011 01:31:13] Result: 2dd8e44a accepted        
MSG: upstream RPC error                                
[18/06/2011 01:31:13] Disconnected from server        
[18/06/2011 01:31:23] Result: e5eb79fe accepted        
[18/06/2011 01:31:24] Result: d981469f accepted  
MSG: upstream RPC error                          
[18/06/2011 01:31:34] Failed to connect, retrying...
MSG: upstream RPC error                          
[18/06/2011 01:32:30] Failed to connect, retrying...
MSG: upstream RPC error                          
[18/06/2011 01:32:43] Failed to connect, retrying...
MSG: upstream RPC error                          
[18/06/2011 01:32:58] Failed to connect, retrying...
MSG: upstream RPC error                          
[18/06/2011 01:34:01] Failed to connect, retrying...
MSG: upstream RPC error                          
[18/06/2011 01:36:22] Failed to connect, retrying...
MSG: upstream RPC error                          
[18/06/2011 01:36:33] Failed to connect, retrying...
MSG: upstream RPC error                          
[18/06/2011 01:37:42] Failed to connect, retrying...
[0 Khash/sec] [1812 Accepted] [30 Rejected] [RPC]

This erro occurs with Version 1.5



I got this issue, as well as the just being stuck at 0 issue that another user mentioned, with 1.50 today.  What I did to get the Failed to connect error to stop and it to kick back into gear without restarting it was to simply load a website in Internet Explorer!

To see if it can be prevented, I've decided to run an automated ping of google.com every 10 mins, and am going to see if this prevents the problem from recurring.
Pages:
Jump to: