Bitcoin Forum
April 27, 2024, 08:36:08 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
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 760546 times)
jedi95 (OP)
Full Member
***
Offline Offline

Activity: 219
Merit: 120


View Profile
August 14, 2011, 10:58:39 AM
 #881

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.

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.

Phoenix Miner developer

Donations appreciated at:
1PHoenix9j9J3M6v3VQYWeXrHPPjf7y3rU
It is a common myth that Bitcoin is ruled by a majority of miners. This is not true. Bitcoin miners "vote" on the ordering of transactions, but that's all they do. They can't vote to change the network rules.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714206968
Hero Member
*
Offline Offline

Posts: 1714206968

View Profile Personal Message (Offline)

Ignore
1714206968
Reply with quote  #2

1714206968
Report to moderator
carlo
Full Member
***
Offline Offline

Activity: 133
Merit: 100


View Profile
August 14, 2011, 11:24:01 AM
Last edit: August 14, 2011, 11:41:11 AM by carlo
 #882

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

Activity: 378
Merit: 250



View Profile WWW
August 14, 2011, 03:32:45 PM
 #883

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.

Funroll_Loops, the theoretically quicker breakfast cereal!
Check out http://www.facebook.com/JupiterICT for all of your computing needs.  If you need it, we can get it.  We have solutions for your computing conundrums.  BTC accepted!  12HWUSguWXRCQKfkPeJygVR1ex5wbg3hAq
nomnomnom
Sr. Member
****
Offline Offline

Activity: 313
Merit: 250



View Profile
August 14, 2011, 03:51:19 PM
 #884

Hi, it seems the mem leak is back in 1.61 Grin (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.


carlo
Full Member
***
Offline Offline

Activity: 133
Merit: 100


View Profile
August 14, 2011, 05:08:19 PM
 #885

Yes, 1.61 leaks memory.
jedi95 (OP)
Full Member
***
Offline Offline

Activity: 219
Merit: 120


View Profile
August 14, 2011, 07:30:41 PM
 #886

Hi, it seems the mem leak is back in 1.61 Grin (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.

Phoenix Miner developer

Donations appreciated at:
1PHoenix9j9J3M6v3VQYWeXrHPPjf7y3rU
d3m0n1q_733rz
Sr. Member
****
Offline Offline

Activity: 378
Merit: 250



View Profile WWW
August 15, 2011, 02:34:57 AM
 #887


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://bitcointalk.org/index.php?topic=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;
Ironically, I believe this causes a cache miss and signals the automatic prefetch to engage.  Ideally, the prefetch would be called upon normally by a command in the code, but this is a means to have the processor pay more attention and pre-empt the required data.

Funroll_Loops, the theoretically quicker breakfast cereal!
Check out http://www.facebook.com/JupiterICT for all of your computing needs.  If you need it, we can get it.  We have solutions for your computing conundrums.  BTC accepted!  12HWUSguWXRCQKfkPeJygVR1ex5wbg3hAq
owowo
Newbie
*
Offline Offline

Activity: 43
Merit: 0


View Profile
August 15, 2011, 06:59:02 AM
 #888

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...
Remember remember the 5th of November
Legendary
*
Offline Offline

Activity: 1862
Merit: 1011

Reverse engineer from time to time


View Profile
August 15, 2011, 02:12:41 PM
 #889

Ok jedi95, but can you tell me a bit more of what exactly FASTLOOP does. Does it check less nonces or something?

BTC:1AiCRMxgf1ptVQwx6hDuKMu4f7F27QmJC2
bcforum
Full Member
***
Offline Offline

Activity: 140
Merit: 100


View Profile
August 15, 2011, 02:25:16 PM
 #890

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.

If you found this post useful, feel free to share the wealth: 1E35gTBmJzPNJ3v72DX4wu4YtvHTWqNRbM
jedi95 (OP)
Full Member
***
Offline Offline

Activity: 219
Merit: 120


View Profile
August 15, 2011, 02:50:42 PM
 #891

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.

Phoenix Miner developer

Donations appreciated at:
1PHoenix9j9J3M6v3VQYWeXrHPPjf7y3rU
nomnomnom
Sr. Member
****
Offline Offline

Activity: 313
Merit: 250



View Profile
August 15, 2011, 04:11:08 PM
 #892

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.

owowo
Newbie
*
Offline Offline

Activity: 43
Merit: 0


View Profile
August 15, 2011, 05:17:09 PM
Last edit: August 15, 2011, 06:50:42 PM by owowo
 #893

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.
jedi95 (OP)
Full Member
***
Offline Offline

Activity: 219
Merit: 120


View Profile
August 16, 2011, 01:17:10 AM
 #894

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.

Phoenix Miner developer

Donations appreciated at:
1PHoenix9j9J3M6v3VQYWeXrHPPjf7y3rU
bboques
Newbie
*
Offline Offline

Activity: 58
Merit: 0



View Profile
August 16, 2011, 06:42:47 PM
 #895

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?
jedi95 (OP)
Full Member
***
Offline Offline

Activity: 219
Merit: 120


View Profile
August 16, 2011, 07:13:38 PM
 #896

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?

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.

Phoenix Miner developer

Donations appreciated at:
1PHoenix9j9J3M6v3VQYWeXrHPPjf7y3rU
Seraphim401
Full Member
***
Offline Offline

Activity: 215
Merit: 100


Live Long and Prosper


View Profile
August 17, 2011, 02:38:17 AM
 #897

Wow!8-10 Mh/s more on my 4 miners combined.
Thanks a lot.

d3m0n1q_733rz
Sr. Member
****
Offline Offline

Activity: 378
Merit: 250



View Profile WWW
August 17, 2011, 11:59:44 AM
 #898

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?

Funroll_Loops, the theoretically quicker breakfast cereal!
Check out http://www.facebook.com/JupiterICT for all of your computing needs.  If you need it, we can get it.  We have solutions for your computing conundrums.  BTC accepted!  12HWUSguWXRCQKfkPeJygVR1ex5wbg3hAq
d3m0n1q_733rz
Sr. Member
****
Offline Offline

Activity: 378
Merit: 250



View Profile WWW
August 17, 2011, 06:04:01 PM
 #899

Well, looks like it's picked-up since last night.  It must have been a random streak of bad luck or something.  Sorry.

Funroll_Loops, the theoretically quicker breakfast cereal!
Check out http://www.facebook.com/JupiterICT for all of your computing needs.  If you need it, we can get it.  We have solutions for your computing conundrums.  BTC accepted!  12HWUSguWXRCQKfkPeJygVR1ex5wbg3hAq
pandemic
Sr. Member
****
Offline Offline

Activity: 434
Merit: 250


View Profile
August 18, 2011, 01:20:56 AM
 #900

Does 1.6.2 use these mods?

further improved phatk OpenCL Kernel (> 4% increase) for Phoenix - 2011-08-11
http://bitcointalk.org/index.php?topic=25860.0

I started using 1.6.2 over 1.5 and haven't seen any increase.
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:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!