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

Nice Upgrade.. Excellent Work..

I finally took the time to upgrade from 1.6.2 to 1.7.3..  Nice results..

Just for example, my test rig has a single 5850 and went from 398 -> 438 MH/s.  10% !!

Enigma

I'm pretty sure your change to bitselect() was not needed, because it should have worked before, too . I was the one who wrote it that way.
But thanks for your hard work and the exchange we have, it's fun!

Dia

Crashes for me on win7 64bit

I mainly intended to eliminate pyopencl as the source of the problem.

1.7.3 has a few fixes:
 - Updated phatk and poclbm to use bitselect() with BFI_INT disabled. This should help for GCN based GPUs (7970)
 - Modified WORKSIZE checking for poclbm, phatk, phatk2.
 - Disallowed -q 0 since it won't work correctly.

From what I have read bitselect() will properly compile to BFI_INT on GCN based GPUs without the crazy binary patching method required for VLIW5/VLIW4.

It really bothers me, the kernel you linked is one I know, it's an earlier version, who uses a different approach to compute the bases used in the kernel. Phateus introduced another method in his 2.x kernel, which I took and refined. But this seems to break uint3 support for my current version. Only other big difference I can think of is the use of an ulong as output buffer in my version, where your linked one still has an uint ... weird and it sucks ^^.

By the way, what have you added in 1.7.3? I downloaded and it works so far ... thanks.

Dia

I know for a fact that uint3 vectors works under this version of pyOpenCL. I have been able to get the stock phatk to run with uint3 vectors enabled. The problems only occurs when I try to adjust the rateDivisor in the Python portion of the kernel. Dividing 2^N by 3 always has a remainder, so you end up sending bad work to the kernel.

This should at least give you a starting point:
https://github.com/downloads/jedi95/Phoenix-Miner/kernel.cl

The only change I made to the Python portion of the kernel is setting it to pass -DVECTORS3 to the compiler. Also note that without changing the rateDivisor your reported hashrate is going to be 2/3 of the actual value. Obviously this won't work well for mining as-is, but it at least it demonstrates that uint3 vectors work.

I was surprised to, as it seems that most people are using phatk or phatk2.  I haven't mined with that particular card (it's my gaming machine) in about 3 months, but I never got anything over 390-395 before, using GUIMiner.  I decided to mine again with it and was only getting ~366 mhash, so I tried out phoenix 1.72 and after a little tinkering and testing had my jaw drop when I saw it cranking out 433 or so mhash... going strong for over 24 hrs now too.

poclbm kernel is at least 10 MH/s slower than my phatk version on my system with 6950, strange.

@jedi: Any reason to not use the latest pyOpenCL version for Phoenix? Perhaps there lies the vec3 problem? I read a bit in it's documentation and it seems a few commands Phoenix uses are now deprecated.

Dia

Using Phoenix 1.72 with 12.1 Preview drivers and 2.6 SDK - poclbm Aggression 7 - Worksize 64 - I'm getting ~433 mhash on my HD 6970 at Stock settings and voltage.... I'm delighted with those results, esp. considering that it's not using 100% of a CPu core now either.  

Sorry about that, I forgot that -q 0 only works in my current development version. It's an ugly workaround so I can test some things for rollntime.

The other solution is to use an askrate, which will reduce the problem.

Askrate can be specified by using this format for HTTP connections:
http://login:[email protected]:8332/;askrate=20

@jedi95
 Sorry for my error, i have mssspeled. Of course i ment VECTORS.

I can confirm this, -q 0 is a no got currently.

Dia

Hmmm... at -q 0 Phoenix (current git running on Windows 7 x64, 64-bit Python 2.7.2) just keeps complaining that the queue is empty and never starts any actual mining.

The queue issue seems to be the reason why I get relatively high amounts of rejects when running against a local proxy; the proxy adds another layer of pre-fetching which of course makes the issue worse (and which you, jedi95, aren't responsible for at all).

If NVIDIA has OpenCL 1.1 drivers, they should support uint3 ... but as I observed, too, Phoenix crashes in . Perhaps a certain parameter is not valid there. I had in my mind, because for VECTORS3 rateDivisor is 3 and so self.size is not correct, because nonceRange.size is perhaps not dividable by 3?

Dia

As far as I know, phatk2 is the fastest kernel for a 5870 on Phoenix when using SDK 2.4 or 2.5. I have only used 2.4 myself, so there might be a better option for SDK 2.5.

The settings to use depend on your memory clock. If you are running stock or near stock (1200MHz) then WORKSIZE=128 will give better performance. If you have downclocked your memory significantly (to 300MHz, for example) then WORKSIZE=256 will be faster.

If that 5870 isn't used for anything besides mining, I would recommend a bit higher AGGRESSION. (10 or so) If not, then I recommend that you don't disable FASTLOOP since it is beneficial at AGGRESSION 8 on a 5870.

Finally, it's VECTORS, not VACTORS



I am working on the problem, but I want to take the time to do it correctly instead of putting together a quick hacked-together fix. Thanks for the offer to help, but I think I have a pretty good idea of how I want to implement this.

I had a look at your VECTORS3 code, but I couldn't find any issues at first glance. Testing it is somewhat problematic because the computer I am working with only has a single GTX 580. All my 5870s are in dedicated mining systems which are not suitable for in-depth kernel debugging.

I can run VECTORS, VECTORS4, and no vectors on my GTX 580, but VECTORS3 gives me this:

Thanks for this explanation, so I was on the right track. Are you trying to implement a solution for this currently or is there anything we / I can do to assist you there? Have you got an idea for the vec3 stuff not working?

I'm now trying AGRESSION=10, will report back after Phoenix ran a bit with that setting.

Edit 1: That's another error and has nothing to do with the discussed problem, right?

Thanks,
Dia

Any1 can tell me where can i find fastest kernel to use witn 5870 ?
Currently i`m using stock 1.7 phatk2 from github with those param:
VACTORS AGGRESSION=8 BFI_INT FASTLOOP=false WORKSIZE=256

It looks like you have run into the same fundamental problem I am trying to address before I can implement rollntime.

Essentially the server is rejecting your work because it is too old, not because kernel processing took too long. At 65 Mhash/sec, it will take just over a minute to process an entire WorkUnit of 2^32 nonces. Now, this work is not necessarily "stale" because it's from the current block and it meets the target specified by the server. This is made worse by the fact that Phoenix maintains a second WorkUnit in the queue by default. On a 5870 that can check the entire 2^32 space in 10-11 seconds, this is beneficial because it allows the miner to continue running during momentary connection disruptions or server load spikes. However, on hardware that takes over a minute to process 2^32 nonces, this can cause shares to be submitted from WorkUnits that are over 2 minutes old. This won't cause problems when the block changes because all work from previous block will be discarded immediately.

Rollntime introduces the same problems, since even very fast miners can now function for 30-60+ seconds on a single WorkUnit. The queue behavior needs to be adjusted to account for this. Most likely the solution will involve monitoring how much time is left until the miner runs out of work, and fetching more work when it falls below some value.

The message you are getting is sent by the pool server using x-reject-reason. I'm going to guess that the pool you are connecting to "forgets" about work it has assigned after some amount of time. (probably to save resources) I recommend trying other pools to see if you get the same behavior.

That said, aggression 12 on hardware doing only 65 Mhash/sec is probably not a good idea. Your kernel execution times are going to be something like ~4 seconds. This is problematic because you can't reasonably interrupt kernel executions to switch work. (eg: when the block changes) On average this is going to mean 2 seconds of wasted time per block (which amounts to a 0.33% loss) Try aggression 10 or so, which should limit this effect without much of a hashrate drop.

You can also use -q 0 to disable the queue entirely. This cuts your work age in half compared to the default of 1, but you might see the miner idling once per minute when it needs new work. At aggression 10 (kernel execution time 1 second) this shouldn't be a problem under normal cases. This allows for enough time to fetch new work before the miner runs out completely. However, this doesn't work at low aggression where the kernel execution time is a small fraction of a second.

I'm using 1.7.2 with an own kernel version and 1/3 of the shares for my 6550D (A8-3850 APU) are rejected with:

What does this mean? Agression to high? Is the valid nonce invalid, because processing took too long?
My command line is:


Thanks,
Dia

Btw.: Anyone here, who is able to debug why I can't seem to get 3-component vectors working (see: http://www.mediafire.com/?r3n2m5s2y2b32d9 and use VECTORS3).

don't know what to tell you

maybe it nrollover shit

needless to say you & deepbit need to get it fixed