Topic: **UPDATED Sep. 6th** Improved Phoenix miner -- new features! (Read 3866 times)

On lastest phoenix had very serious issues with LP and empty queue on ars pool. Tried yours from yesterday and the stales still about the same (maybe location and ping), but the other problems mentioned before are solved, no more empty queue .


Thumbs up!

done. you'll have to get a copy of the latest revision from the repository. use --refresh-rate or -r to override the default.

-aldiyen

I like the --disable-redraw in concept, but it causes a new line with status information to be written every second (which is just as much noise in a log file).  Any chance to add an additional option to control how often a status line is output when in --disable-redraw mode? 

Here's an explanation of why it spawns two phoenix.exe processes when you run the exe:
http://www.pyinstaller.org/export/latest/tags/1.4/doc/Manual.html?format=raw#how-one-file-mode-works

Also, I've uploaded a newer version with some refinements and enhancements. See the original posts for details.

-aldiyen

I assume you mean when you run the phoenix.exe it spawns two processes called "phoenix.exe"? something to do with the way the software I used to convert the python to a windows .exe operates, from the look of it. one of them is using 0% CPU and only 1MB of memory, so I can't imagine it's doing much of anything. perhaps it's needed to spawn the main process

why every link is launching two phoenix.exe process? 

Ok, so the results are in:

[300 Mh/s] [4456 Accepted] [1 Rejected] = 0.02% Rejected
[290 Mh/s] [4420 Accepted] [0 Rejected] = 0.00% Rejected

I have to say... awesome job!

Some pools have mentioned that they support it here in the forums, and some may list it as a feature on their sites, but in general I don't think it's well documented. I haven't added any output to explicitly indicate that the server supports rollntime, but if you run with the -v (verbose) flag, you will see when the miner gets new work, which should be a pretty good indicator. The normal phoenix gets work 2-3 times per minute on my system, at 410MH/sec, whereas this version will get work once every 4 minutes (on servers that support rollntime) unless the server explicitly specifies a work expiration (for instance, Eligius sets expiration to 120 seconds).

Anyway, I'm glad to hear that it's working well so far! Some time, perhaps later this week, I'm planning to add some functionality for the software to try re-submitting work that fails due to communication errors / timeouts; currently any such work is treated as a reject and discarded. After that I may add some other little tweaks to make the software a little bit friendlier. I'll update this thread as soon as I add any new features.

Ditto. I just started running it against bitcoins.lc. I usually get about 0.3% stales so there's not a lot to improve on, but I guess every share counts

How do I know if a pool supports rollntime?

Edit: So far so good. "Grand Total : [1088.90 MHash/sec] [551 Accepted] [0 Rejected] [0% Rejected]"

Edit2: Still going strong. "Grand Total : [1088.68 MHash/sec] [3035 Accepted] [0 Rejected] [0% Rejected]"

Edit3: I'm impressed. "Grand Total : [1088.82 MHash/sec] [9490 Accepted] [0 Rejected] [0% Rejected]"

I just installed your version on my 2x5830 machine and am testing it now against Bitp.it. I'm going to let it run overnight and let you know the results as soon as I get the chance. I usually average about 1-2% rejections from this pool over a 24hr period. So far, no issues and everything seems to be running smoothly. Will keep you posted. 

cool, glad to hear it. it probably won't perform any differently unless you're mining at a pool, but it's still helpful to know that it's not doing anything weird when you're not connected to something that supports updating the work time. thanks!

Hey buddy,

Using it to mine SolidCoins.

nmc@nm:~/phoenix_beta$ sudo python phoenix.py -u http://crs:pass@localhost:7556/ DEVICE=1 -k phatk PLATFORM=1 BFI_INT VECTORS AGGRESSION=12 WORKSIZE=256
[22/08/2011 10:15:59] Phoenix Miner (aldiyen mod) v1.6.2 starting...
[22/08/2011 10:15:59] Connected to server
[337.19 Mhash/sec] [0 Accepted] [0 Rejected] [RPC]

Your version is about 4 mil hashes faster and everything seems to be ok.
Thanks !

Hey everyone,

I've created a fork of the Phoenix miner with a few improvements/changes over the main line

New functionality:
-  Retrying of failed work submissions: When standard Phoenix miner has an issue communicating with the pool while submitting work it simply discards the work unit, losing possibly valid shares. It will now retry submission until it is able to connect
-  Roll Ntime support: Locally update work time so we don't have to get new work from the pool server nearly as often. This should help reduce the number of "miner idle" warnings, for those of you who have them. Also important, it will help keep your pool operator's administration costs down which will keep them from having to institute or raise fees to keep the pool going. (Only supported on some pools.) Technical details at https://en.bitcoin.it/wiki/Getwork#rollntime

Cosmetic changes:
-  New status output format: The only major change here is that it shows reject %, but I think it also looks better. Will also show getwork count and efficiency (getworks vs. accepted shares) when -v is passed. Can be disabled by passing --old-status
-   Make the status line scroll: It's now possible to disable the redrawing of the status line (hash rate, accepted/rejected, etc.), so it scrolls like any other log message. This is useful for programmatically parsing the miner's output, or redirecting to a log for later review. Enable this with --disable-redraw. Change the rate at which it outputs status with --refresh-rate or -r
-  Reject reason is now shown next to the rejected share message, rather than in a separate log message (verbose mode only)
-  Redrawing of the status line should no longer result in the text flashing or disappearing for a moment, as it redraws the entire line in one go rather than needlessly writing four separate times

Bug fixes:
-  Discard current work unit if a share from it is invalid (e.g. stale). Previously it'd simply keep working on the work unit until we exhausted the entire 32-bit nonce range or until an LP returned, which could result in multiple invalid shares being wastefully produced
-  Potentially prevent an indefinitely long loop of getwork calls if Phoenix receives a work from an earlier block after one from the most recent block

Github URL:
https://github.com/aldiyen/Phoenix-Miner-aldiyen

Direct download link:
https://github.com/aldiyen/Phoenix-Miner-aldiyen/zipball/v0.2.4

Windows .exe download:
http://aldiyen.com/phoenix-ald-v0.2.4_onefile.zip

I've created a new Guiminer-compatible exe. Unpack it to a new directory, so you don't overwrite any existing Guiminer files. You can change the path to the executable from within Guiminer to point to my Phoenix in the directory you've just unpacked it to. Download at:
http://aldiyen.com/phoenix-ald-v0.2.4_gm.zip

It seems that people like the XML-RPC patch from thejfk, so here's a version which is compatible with this version of Phoenix: http://www.aldiyen.com/phoenix-ald-xmlrpc.diff - see https://bitcointalksearch.org/topic/xml-rpc-interface-for-phoenix-allows-monitoring-23308 for an explanation

Note: I previously stated that rollntime could notably reduce stales, but I have been unable to reproduce the rejects with mainline Phoenix miner that I did with my initial tests, so I assume the rejects with mainline Phoenix during that testing were a fluke. My apologies

I don't have any plans to add more changes at this point, but I'd be happy to fix bugs and I would consider new features if you have something in particular in mind

Feedback is most welcome. Thanks!

-aldiyen

p.s. I haven't tested it at all with the MMP protocol