Topic: Phoenix - Efficient, fast, modular miner - page 13. (Read 760839 times)
Hey, I've noticed a major decrease in the number of shares since the last revision. I don't know what you changed to fix the memory leak, but I've had the same hash rate with about 10x less submitted shares. Granted, there was a difficulty change today, but 10x is still a lot. Is there a means to re-download the older one?
Wow!8-10 Mh/s more on my 4 miners combined.
Thanks a lot.
Thanks a lot.
What does this mean?
bit@Bit:~$ aticonfig --odgc --adapter=all
aticonfig: This program must be run as root when no X server is active
I just bought a new computer, had a computer shop make it, and went through all the steps but I can't tell what number my GPUs are. I am mining successfully on my CPU so it works, but why won't my cards show up?
bit@Bit:~$ aticonfig --odgc --adapter=all
aticonfig: This program must be run as root when no X server is active
I just bought a new computer, had a computer shop make it, and went through all the steps but I can't tell what number my GPUs are. I am mining successfully on my CPU so it works, but why won't my cards show up?
You need an X server running in order to do basically anything with the ATI drivers in Linux. This isn't a problem with the miner. Without an X server running your GPUs are not visible to OpenCL so they can't be used for mining.
Find a setup guide for mining on Linux. I'm not sure if they go over setting up an X server though.
What does this mean?
bit@Bit:~$ aticonfig --odgc --adapter=all
aticonfig: This program must be run as root when no X server is active
I just bought a new computer, had a computer shop make it, and went through all the steps but I can't tell what number my GPUs are. I am mining successfully on my CPU so it works, but why won't my cards show up?
bit@Bit:~$ aticonfig --odgc --adapter=all
aticonfig: This program must be run as root when no X server is active
I just bought a new computer, had a computer shop make it, and went through all the steps but I can't tell what number my GPUs are. I am mining successfully on my CPU so it works, but why won't my cards show up?
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.
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.
ok, thx, then I have just to find that one little line for the xmlrpc.
EDIT: well. It was more the "one little line" actually it was four little lines. But it works.
EDIT: well. It was more the "one little line" actually it was four little lines. But it works.
Thanks for spotting that, I have committed a reverted client3420. Please test with this version to make sure it's not leaking. If that fixes it I will go ahead and release 1.6.2 with this change.
Looks much better I think,
this morning - 306832 VSZ 74092 RSS
12 hours later - 380564 VSZ 74344 RSS
It has grown a little bit, but that's nothing compared to what was happening with earlier versions.
hi, is there a way to get hashrate, stales, etc. values and send it to munin (monitoring)? like for 1.5 there was a patch...
If it is the logtotext or xmlrpc patch, they still work, just that the patching fails and saves something to phoenix.py.rej.But it is only one line which can be added manually to phoenix.py.
Ok jedi95, but can you tell me a bit more of what exactly FASTLOOP does. Does it check less nonces or something?
AGGRESSION sets the number of nonces hashed per kernel run.
FASTLOOP adjusts the number of nonces hashed per kernel run to try and get it under one frame time, ostensibly to improve desktop performance.
Ultimately, alll 2^32 nonces are tested in multiple kernel runs.
That's not quite accurate regarding FASTLOOP.
FASTLOOP does not change the number of nonces per kernel execution. The purpose of FASTLOOP is to improve hashrate at low AGGRESSION. The WorkQueue isn't fast enough to directly feed the kernel without a performance drop once you go above about 30-50 executions per second. FASTLOOP requests larger NonceRanges from the queue and splits them up into smaller pieces.
Ok jedi95, but can you tell me a bit more of what exactly FASTLOOP does. Does it check less nonces or something?
AGGRESSION sets the number of nonces hashed per kernel run.
FASTLOOP adjusts the number of nonces hashed per kernel run to try and get it under one frame time, ostensibly to improve desktop performance.
Ultimately, alll 2^32 nonces are tested in multiple kernel runs.
legendary
Activity: 1862
Merit: 1011
Reverse engineer from time to time
Ok jedi95, but can you tell me a bit more of what exactly FASTLOOP does. Does it check less nonces or something?
hi, is there a way to get hashrate, stales, etc. values and send it to munin (monitoring)? like for 1.5 there was a patch...
Did another git pull this morning, and the stale shares issue is gone now, back to well below 1% for the last few hours. Jood job.
The miner hasn't yet locked up again so I can't tell if whatever problem that caused it is also solved. I'll add a -v as soon as I'm back at my machine tonight and then we will see.
About failover... I'm pointing the miner at my local mining proxy (cdhowie) which lives on the same machine. What do you think, should I use the same address as backup url, so even if not actually switching servers it will still reset the protocol if it's idle? Of course that wouldn't help with the proxy itself going down, but in my experience the proxy is very well behaved once you've figured out how to configure the underlying Apache for more concurrent threads and longer timeouts.
EDIT: One more thing, the phatk2 kernel produces a warning about variable t1 being defined but never used in the kernel (line 153 I think) on start-up, but then works fine as it seems. Is that normal and expected behaviour? Or am I missing out on an optimization that way?
The t1 variable in phatk2 is a dummy to make the compiler behave a certain way. I'm not quite sure why defining a dummy variable results in better performance, but if you need more information about the OpenCL level tweaks I recommend asking in the phatk thread:
https://bitcointalksearch.org/topic/modified-kernel-for-phoenix-15-7964
From kernel.cl:
Code:
u W[124];
u Vals[8];
//Dummy Variable to prevent compiler from reordering between rounds
u t1;
//Vals[0]=state0;
Vals[1]=B1;
Vals[2]=C1;
Vals[3]=D1;
u Vals[8];
//Dummy Variable to prevent compiler from reordering between rounds
u t1;
//Vals[0]=state0;
Vals[1]=B1;
Vals[2]=C1;
Vals[3]=D1;
Hi, it seems the mem leak is back in 1.61 
(at least for me)
In this commit https://github.com/jedi95/Phoenix-Miner/commit/7bc2bf7b452ce48b7f8be8f5d6b6a95db13e1c8f
I have changed client3420.py from line 788 till the end back to how it was in 1.60 (while protos ...)
and now it is not leaking anymore. Still seems to work fine, only my inet was down for a few minutes and it
somehow did not reconnect itself, but my watchdog script took care of that.
(at least for me)In this commit https://github.com/jedi95/Phoenix-Miner/commit/7bc2bf7b452ce48b7f8be8f5d6b6a95db13e1c8f
I have changed client3420.py from line 788 till the end back to how it was in 1.60 (while protos ...)
and now it is not leaking anymore. Still seems to work fine, only my inet was down for a few minutes and it
somehow did not reconnect itself, but my watchdog script took care of that.
Thanks for spotting that, I have committed a reverted client3420. Please test with this version to make sure it's not leaking. If that fixes it I will go ahead and release 1.6.2 with this change.
Yes, 1.61 leaks memory.
Hi, it seems the mem leak is back in 1.61 (at least for me)
In this commit https://github.com/jedi95/Phoenix-Miner/commit/7bc2bf7b452ce48b7f8be8f5d6b6a95db13e1c8f
I have changed client3420.py from line 788 till the end back to how it was in 1.60 (while protos ...)
and now it is not leaking anymore. Still seems to work fine, only my inet was down for a few minutes and it
somehow did not reconnect itself, but my watchdog script took care of that.
(at least for me)In this commit https://github.com/jedi95/Phoenix-Miner/commit/7bc2bf7b452ce48b7f8be8f5d6b6a95db13e1c8f
I have changed client3420.py from line 788 till the end back to how it was in 1.60 (while protos ...)
and now it is not leaking anymore. Still seems to work fine, only my inet was down for a few minutes and it
somehow did not reconnect itself, but my watchdog script took care of that.
Hi, I was just wondering under what circumstances quad-vectors are used? I happened upon the option VECTORS4 in the code and it's undocumented in your first post as to its use.
Hello,
the failover feature seems to be a bit slow, i tested it with a iptables drop. About 1-2 minutes than the miner switched the server.
Than i removed the iptables rule but the miner didnt switch back to the primary server, maybe i didnt wait long enough.
I would like to have a parameter that tells the miner: If there are more than X idles in the last Y minutes than switch for Z shares.
And there is another question: Is AGGRESSION=16 possible for a linux dedicated miner ? Whats the max value for AGGRESSION ?
Thx for the nice miner and your support.
the failover feature seems to be a bit slow, i tested it with a iptables drop. About 1-2 minutes than the miner switched the server.
Than i removed the iptables rule but the miner didnt switch back to the primary server, maybe i didnt wait long enough.
I would like to have a parameter that tells the miner: If there are more than X idles in the last Y minutes than switch for Z shares.
And there is another question: Is AGGRESSION=16 possible for a linux dedicated miner ? Whats the max value for AGGRESSION ?
Thx for the nice miner and your support.
So, i heard that phoenix checks all the 2^32 noncespace. However i feel that the "documentation" about it is scarce at best.
What exactly are these avg samples? What are the best settings for my 5870 so i can make phoenix really scan all the nonces.
What exactly are these avg samples? What are the best settings for my 5870 so i can make phoenix really scan all the nonces.
Phoenix will automatically scan the entire nonce space as long as the server you are connecting to has some way of pushing work. (either MMP or RPC + LP) This is the reason Phoenix has a queue. When the queue size falls below the value specified with -q the miner requests more work.
The average samples are just how many samples are used for the hashrate display. Higher values will give a more stable hashrate display while smaller values will show the fluctuations in hashrate better.
Recommended settings for a 5870 right now:
-k phatk2 VECTORS BFI_INT AGGRESSION=8
You can increase AGGRESSION if you don't plan on using the computer while mining. Higher values will improve hashrate, but also increase the amount of lag. You will also need to specify which OpenCL device to run on using DEVICE=X.
legendary
Activity: 1862
Merit: 1011
Reverse engineer from time to time
So, i heard that phoenix checks all the 2^32 noncespace. However i feel that the "documentation" about it is scarce at best.
What exactly are these avg samples? What are the best settings for my 5870 so i can make phoenix really scan all the nonces.
What exactly are these avg samples? What are the best settings for my 5870 so i can make phoenix really scan all the nonces.
The t1 variable in phatk2 is a dummy to make the compiler behave a certain way.
I figured as much; my question was more along the lines of, if the OpenCL compiler (I use the one from the Windows Catalyst 11.7 drivers) complains about it being unused, will it still "behave a certain way" then, or will t1 just be removed and the desired behaviour doesn't happen.
Whatever, just answers this if you feel like it, I don't want to steal more of your time. Thanks again for such a great miner.
Jump to: