Topic: Phoenix - Efficient, fast, modular miner - page 47. (Read 760839 times)

Work (2^32 nonces) is always checked completely unless the block changes before the entire range of nonces is checked. In terms of full getwork responses, if the queue is already full when more work is received the oldest work is discarded. This doesn't affect the chances of finding a block, since it's just as likely that the new work contains a solution.

Hi I have a question, you mentioned that it is good to set an askrate=10 when mining solo due to the possible change in block. I recalled that the default for poclbm or diablo was 5. Does the askrate for phoenix use the same scale system as the other 2? Additionally, does the askrate=5 potentially cause the miner to work incompletely. For example, if the miner has not completely hash the current work and the new work arrives dumping the current work mid way, and this cycle continues. Would it affect the probability of finding a solution?

Aaawright. Thanks for clearing that up for me.

As jedi95 said, Slush's pool has an extra header in the response that indicates the block number, which is simply displayed in the Phoenix output.
bitcoind doesn't give this header during getwork() responses, (and, as of this writing, nor do any of the other pools), but when I have time to
sit down and adjust the internals a bit, I can make it query the solo Bitcoin client for its block number.

This message is only displayed when the RPC server sends X-Blocknum in the header. A local bitcoin or bitcoind instance doesn't provide it.

congrats on your miner: insane speed!

One question: I'm using phoenix to mine solo on one GPU, on slush's pool on the other. The slush one report "working on block #" when switching to a new block. The miner connected to my local bitcoin (solo) doesn't do that. Why not?

Version 1.3 has been released.

Changes:

1. Kernel performance improvements on ATI hardware without BFI_INT enabled (3-10 Mhash/sec)
2. Added warning on startup if FASTLOOP is enabled with AGGRESSION set to 9 or higher
3. The kernel's work cache is cleared when a new block is started (reduces invalid/stale)
4. Results are checked against the current block before being sent (prevents sending stale work if the block changed while the kernel was processing it)
5. Various minor bugfixes

To follow up: Apparently the DeprecationWarning is something a little bit more serious. For some reason, PyOpenCL is returning
either a negative nonce, or one greater than 2^32. The NumPy array that nonces get placed in is designated as a uint32 array.
There is absolutely no way that should be possible... and yet it's happening.
Maybe there's a bug in your version of PyOpenCL or NumPy? I have absolutely no idea what's wrong, sorry.

However, I don't think this is a benign issue, it could be seriously impacting your hashrate and/or ability to send in shares. We'll probably
have to have a more in-depth conversation via PM about this... I'm just as interested in getting to the bottom of this as you are.

We have identified a possible cause of the increased invalid/stale/rejected shares.

The FASTLOOP setting has the kernel do 8 internal loops before getting additional work from the main queue. This process is not interrupted when new work is pushed through LP or otherwise, so using this option can extend the amount of time the miner spends running stale work. This should not be a problem is FASTLOOP is used as intended with AGGRESSION set to 8 or lower. (since the total delay is less than a second)

With higher AGGRESSION settings FASTLOOP can extend the time it takes the kernel to get new work to more than 10 seconds.

The issue is worsened slightly by a minor bug in the Phoenix framework which will be addressed in 1.3.

Problem is that because everybody will use this miner from now on, the difficulty will rise and soon the payout will be the same as with the old miners. It does make the bitcoin network more secure, though.

Feel free to look at the address in BlockExplorer... 129ZQG33GmqYRVSCw2hw7zmDUCvvMsuGbC

That 10 came as a surprise, but it's otherwise been pretty modest, although we're grateful for the support!

So, what's the average donation been?

That's normal. -v turns on "verbose mode" which shows you debug messages. That mode is mostly
intended for when you're trying to hunt down a problem with your miner.
EDIT: Those "not sending" debug messages are part of the normal behavior of Phoenix. In
reality, the poclbm kernel actually reports only difficulty=1 hashes to the Phoenix system. It is then
up to Phoenix to check if it meets full network difficulty. When that check fails (as it will most of the
time), it flags it as a debug message and continues on its way.

Everything else is fine, but since you're mining solo, you might want an askrate so your miner
switches sooner after the blocks change. Changing your miners to this should do the trick:

Started today with a 5970 XFX Black Edition, stock firmware, oc 805/1200. I'm not completely sure about all the settings and oc yet and these are my results.

Running solo two parallel phoenixes with :
guiminer 290x2~580Mh/s  with -v -d 0 -f 1 -w128
phoenix 330x2~660Mh/s  at 90degC
Is this normal?:

I receive the miner is idle message as well. I get it when going from anything above Aggression 13 (about 408Mh for me). I know people are saying that anything above 10 was unnecessary but what I was seeing was a bump in hash every time I raised it to the point where the dos window would not update the hash rate. In my mind just because it doesn't say it's hashing higher does not mean it isn't. -q 2 or 3 made no difference in the idle messages.

Great work, just the other day I was trying to push my card and this miner takes me further than I thought possible while being stable.
Tipped

Neat idea, but it's probably not practical enough to add to the main code. Being open-source software, you're free to modify it to add that feature yourself, but I don't think it would help enough people to make it worthwhile.

If you're curious anyway: the displayed hex when submitting shares is actually the fifth, sixth, seventh, and eighth bytes of the share hashes. You can calculate the difficulty from that by dividing 4294967040 by the hex displayed.

For example, 3351e8c0 becomes 861006016; 4294967040/861006016 = 4.988 difficulty.

itd be cool if this miner showed what difficulty ech potential hash > or = to 1 would solve. so like "347 diff not met/ not sent, 2 diff not met/ not sent etc.. be more interesting to see how close each potential hash is... lol

aggression is set to 8,
didn't stop since, i'll try to set it lower or set the -q if it does again.

To mine in a pool? You shouldn't have to turn your Bitcoin client on at all unless you're mining solo.
The pool just benefits from your contributed computing power and pays you a % cut. You don't have
to leave Bitcoin up to receive the payments either.


Thanks! And don't worry, I think I hate us too.


"Rejected" can be any number of things, it just means the system you were mining for (a pool server
or your Bitcoin client) rejected the work. A Bitcoin client will reject only on invalid or stale, but a pool
could reject for other reasons (duplicate work, account setting errors, internal server problem, etc.)

However, since invalid work is prevented by a double-check in Phoenix (even with unstable hardware),
and duplicate work won't occur unless the kernel has bugs that would cause that, they're usually
going to be stale... unless there are bugs.

So, pretty much the wordy version of what Raulo just said.


Now that's an interesting error! I'm guessing this is Python 2.7? We haven't done any testing on 2.7 yet.
A little Googling should tell me what's going on with the DeprecationWarnings; it's nothing serious, but apparently
we're doing something in there that the Python team prefers we not do in the future, so we'll fix that in 1.3.

As for the work queue stalling, which should be totally unrelated to the warnings...
What's your aggression set at? Sometimes the aggression is so high that it runs the queue clean out of work on
every loop. We're working on this, but for now you can use -q 2 or -q 3 to increase the size of the queue so that
doesn't happen in the future.

The problems I was having with slushes pool have gone away and it will now connect. I noticed this was happening with other miners as well so I don't think this was ever anything specific to Phoenix.