Can't seem to get this to work. When i extract the zip i get a folder and phoenix.exe
when i tried running the exe, the cmd window goes up then disappears.
I tried xp sp2 and vista sp2 compatibility mode
ran as admin
im on win7 x64
11.4 preview catalyst.
6950 unlocked and 5870 on the rig.
Topic: Phoenix - Efficient, fast, modular miner - page 50. (Read 760771 times)
Hi I think logging to file is a great Idea. Monitoring it from the web would be a breeze!!
There's also Multiminer, which jedi95 and I use for our cluster's status page.
Multiminer's already quite usable and Phoenix already has builtin support for it; all you would have to do is download and
set up Multiminer, connect your Phoenix clients to it with an mmp:// URL, and write a .rpy script that would display info
on your miners. (I'd release ours, but the code is in desperate need of cleanup, and I'd have to okay it with jedi95 first.)
I'll post clearer instructions on how to do that when I fully test and release Multiminer 1.4, which has support for long polling.
I like the idea; how about if we added an option to log to a file directly from Phoenix? (And logging to - disables console output and logs directly to stdout instead.)
Something like: phoenix.py -l mining.log
Not sure what the best way to specify the rate is, though.
Hi I think logging to file is a great Idea. Monitoring it from the web would be a breeze!!
went from 334 Mhash/s to 388 Mhash/s. Overclocked some more and I'm getting 409 Mhash/s with mem at 300 and core at 975 on my 5870. temp is 76-77c with fan at 75%. This is fantastic! Great work!
syntax - "vectors=on" or just "vectors"?
I made the options parser very lenient on syntax. Take your pick of any of the following:
VECTORS=on
VECTORS=true
VECTORS=yes
VECTORS=t
VECTORS=y
VECTORS
VeCtORs=TRuE
...anything else will disable it. Same goes for BFI_INT.
Any way to track the source (git/svn)?
There's SVN here, but we might occasionally commit untested and horribly broken things there, so use it at your own risk.Also, quick feature request. Could you add a feature similar to poclbm --rate 30. So rather than displaying a screen progress, every 30 seconds it timestamps a progress message. That way I can do phoenix.py > logfile and get something sensible.
I like the idea; how about if we added an option to log to a file directly from Phoenix? (And logging to - disables console output and logs directly to stdout instead.)Something like: phoenix.py -l mining.log
Not sure what the best way to specify the rate is, though.
Incredible!
My 5850's does now 325-330MH/s (before 295-300) and the 6970 does now 420-425MH/s!!! (before 380)
syntax - "vectors=on" or just "vectors"?My 5850's does now 325-330MH/s (before 295-300) and the 6970 does now 420-425MH/s!!! (before 380)
overclock - @850/1100 or higher?
Hi,
Any way to track the source (git/svn)?
Also, quick feature request. Could you add a feature similar to poclbm --rate 30. So rather than displaying a screen progress, every 30 seconds it timestamps a progress message. That way I can do phoenix.py > logfile and get something sensible.
Excellent software btw.
Any way to track the source (git/svn)?
Also, quick feature request. Could you add a feature similar to poclbm --rate 30. So rather than displaying a screen progress, every 30 seconds it timestamps a progress message. That way I can do phoenix.py > logfile and get something sensible.
Excellent software btw.
Im getting a ton of "work queue empty, minder is idle" messages
im on a 5970 flags are -k poclbm DEVICE=0 VECTORS AGGRESSION=14 BFI_INT
im on a 5970 flags are -k poclbm DEVICE=0 VECTORS AGGRESSION=14 BFI_INT
VECTORS AGGRESSION=10 -v FASTLOOP BFI_INT WORKSIZE=128
idle messages gone when I dropped AGGRESSION to 10
Incredible!
My 5850's does now 325-330MH/s (before 295-300) and the 6970 does now 420-425MH/s!!! (before 380)
Thx for all!
ByE!
My 5850's does now 325-330MH/s (before 295-300) and the 6970 does now 420-425MH/s!!! (before 380)
Thx for all!
ByE!
poclbm: 5870 @ 900/900 => 344Mh/s
phoenix: 5870 @ 900/300 => 375Mh/s
Very nice
phoenix: 5870 @ 900/300 => 375Mh/s
Very nice
Yeah vectors seemed to slow my hashes down on a 6950 with shaders unlocked vcore 1.15 core 935 mem 500
I actually looked again and there was 1 that wasn't immediately following the LP but still only one. Sorry had to do it in RDP.
here is my batch script start
/DC:\bitcoin\phoenix phoenix.exe -u http://xxxx:[email protected]:8334/ DEVICE=1 BFI_INT AGGRESSION=12 -k poclbm
That is odd indeed. Perhaps this is a bug with LP support. I'm wish slush's pool and I just remembered that he doesn't use LP so I never noticed this issue. Sorry for the misinformation. When I replied to your post the first time I forgot about slush's lack of LP support.
I'm curious why you haven't enabled the VECTORS variable? Does that setting slow mining down?
Also what card are you running and at what speed? Overclocked?
I think this may be an issue with LP support and not something hardware/configuration related.
I actually looked again and there was 1 that wasn't immediately following the LP but still only one. Sorry had to do it in RDP.
here is my batch script start
/DC:\bitcoin\phoenix phoenix.exe -u http://xxxx:[email protected]:8334/ DEVICE=1 BFI_INT AGGRESSION=12 -k poclbm
great software! for sure the guys worth a donation 
keep up the good work!
now the net force is reaching 1Th/s!!!!!
keep up the good work!
now the net force is reaching 1Th/s!!!!!
It seems to commonly reject the the generation immediately after a LP new block is that normal?
Hmm, that's odd. This is not happening for me. I've also noticed that 1.2 produces far fewer rejected results - the ratio of accepted to rejected is much lower now.
I guess it could just be a coincidence but literally every one of my rejected ones came immediately following a LP new block.
Can you post some screenshots maybe? Also what arguments are you passing to the miner? paste them here...perhaps there is something wrong with usage?
It seems to commonly reject the the generation immediately after a LP new block is that normal?
Hmm, that's odd. This is not happening for me. I've also noticed that 1.2 produces far fewer rejected results - the ratio of accepted to rejected is much lower now.
I guess it could just be a coincidence but literally every one of my rejected ones came immediately following a LP new block.
It seems to commonly reject the the generation immediately after a LP new block is that normal?
Hmm, that's odd. This is not happening for me. I've also noticed that 1.2 produces far fewer rejected results - the ratio of accepted to rejected is much lower now.
It seems to commonly reject the the generation immediately after a LP new block is that normal?
Another amazing release, went from 421-422 mHash/sec to 423-424 mHash/sec on my 5870s (Aggression 13, Vectors, 128 Worksize, BFI_INT, using 975/300 @ 0.950v).
Just a suggestion, update your original post with the changelog/updates so we can find out what's new without searching through the various replies within the thread.
Just a suggestion, update your original post with the changelog/updates so we can find out what's new without searching through the various replies within the thread.
Version 1.2 with Long pool supported, thx mate, great work so far 
Jump to: