If you were hashing the same numbers 200 million times, then your miner would be useless. For all we know, this BitMinter miner could be doing just that.

How, exactly, is hash rate an inaccurate way to measure miner speed? Some miners may report inaccurate speeds, but the number of nonces you actually calculate over a given span of time directly relates to how much work is being done. What other metric is there, valid shares submitted? That's a nothing more than reflection of your hash rate, but with more variance because there is an unpredictable element.

Even if what you say were somehow accurate, DrHaribo is boasting that his miner is the fastest, so if that's not relevant then why even make this post?


I'm not sure what you're trying to say here... Are you trying to say that because it reports the same hash rate as some other client, its reported hash rate must be accurate?


What, pray tell, is this good and accurate incentive to keep the source completely closed?

I don't see any source links. is your miner open-source? if not, how is anyone to know that the reported speeds, apparently showing it to be the fastest miner in existence, are accurate (other than possibly decompiling your java code, I suppose)?

-aldiyen

what's your CPU usage like? have you tried a different version of phoenix? (although 1.5 should be fairly stable). you could try a completely separate miner, as well. do other applications make it slower, or is it just chrome?

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

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

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.

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!

next time you think to take a condescending tone with people on the internet, you might want to double-check that what you're saying makes sense first

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://bitcointalk.org/index.php?topic=23308.0 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

Those pools, with the exception of Slush (to some extent), are vulnerable to pool hopping, which will ultimately result in lower payouts to you if you do not pool hop. I would recomment BitP.it (https://pool.bitp.it/) or maybe one of the PPLNS pools listed on the wiki's "Comparison of mining pools" page, or you could try one of the geometric scoring pools -- I think the only ones which use the geometric score calculation are Eclipse Mining Consortium and Continuum (the website of which seems to be down at the moment)

Pools with lower hash rates will pay out less often, but for larger amounts. Over time your reward will average out to be more or less the same, not accounting for a pool's luck which, of course, cannot be known in advance

For some info on the concept of pool hopping, if you're not familiar with it: http://bitcointalk.org/index.php?topic=9928.0;all

guiminer has phoenix as an available option. you were probably using the poclbm (OpenCL Miner), as I believe that is the default when using guiminer. if you continue using phoenix, I would recommend using the latest phatk kernel from this post http://bitcointalk.org/?topic=7964.0

cgminer has pretty comparable hash rates to phoenix. I haven't used diablo miner, but it seems to be fairly popular. check out the mining software board

also, try: export DISPLAY=0.0

did you do the "persistent way" or the "live way"? did you check the box to enable X11 forwarding in putty?

What OS are you guys running?

It's a bitcoin pool hopper. There are some other hoppers around, as well, but this one costs money. See https://bitcointalk.org/index.php?topic=33031.0

When I use POCLBM on a server that supports the rollntime functionality, I end up getting a bunch of rejects after 4-5 minutes. Looking at the POCLBM code, it appears as though it'll just keep rolling the ntime indefinitely, until a longpoll comes in. Anyone else using POCLBM have this problem?

I realize this may not be the best place to post this, but hey, what the heck...

hey all, I've been mining for almost a month now, hanging out in various pool channels on freenode and whatnot. guess I should get around to getting established in the forums...