I updated my post almost immediately with some info. Do you need to know anything else? Parameters are -d 1 -w 128 -f 0 -r 2

Hm. No errors if I add -v. Same thing happens on a 5850 on the same system, although I did get one accepted before it exited when I tried.

Works great. I get pretty much the same hashrate as with phoenix, but the number of submitted shares is ~7% higher (or maybe the last 3 hours were just extremely lucky).

Hi m0mchil thanks for keeping your miner up to speed with the bit_int support. Out of curiosity does your latest version activate the bit_int support automatically? Is there a flag I have to add to activate it.

Also I noticed similar performance to that of phoenix. I guess essentially both miners are the same as it is running the same kernel, however is the hash checking the same for both?

@kindle
Yes, it is on by default if the hardware supports it.

Both miners are now the same in terms of hash checking. Phoenix has far better documented and structured code. It also cares about 'efficiency', something I'm tired of explaining that actually doesn't matter.

Also, Phoenix seems to have different way of load tuning (aggression) which on my particular setup results in more laggy behavior... and perhaps slightly better performance for dedicated mining rigs, not sure.

I hope I won't attract anger with blatantly copying their BFI_INT support. I tried something like this a month ago but didn't understand there is "elf within elf".

thanks for the update.

Can confirm that poclbm is now up to speed with phoenix (maybe even slightly better but will have to watch shares found over time to confirm).

HD 5970, ubuntu 10.10, SDK 2.1, fglrx 11.2
seems that mem. under-clock speeds (775/300) with linux now works with m0mchill ... yay. Was this connected to the BFI_INT capability?

Faster, cooler, quieter.

After updating to 20110428 I have the following error (Fedora 15 x86_64; Python 2.7.1). Previous version ran fine.

EDIT: Nevermind, I just git cloned the repo instead of downloading stuff manually as this outdated guide suggests (maybe it should be updated). Everything is working.

How can you tell what version you are running?

Also, how come in cmd, I'm getting about 320Mhash/s (I have 2 cores), but in deeptbit, the average is only 400Mhash/s.

I know this is a tired subject, but I'm another victim of the "100% CPU" problem. Though everyone else seemed to have it with AMD cards, and I have an nVidia 9500 running on amd64 Linux.


It is actually using the GPU since it goes up to 5.5 Mhps (my CPUs only go up to 2 Mhps on their own, also I was running minerd at the same time on those CPUs), but still uses a large chunk of my CPU (1 whole CPU), so it's not that I have somehow selected the CPU driver.

I've tried playing with some of the settings, turning off vectors only made it worse (it ate 1 CPU and a bit of another), changing the value of frames to 0 or 30 had no difference.
I have tried running it without minerd hogging the CPUs but that made no difference…


If I get this to work I'll be able to pull off over 13 Mhps (4×2Mhps + 5.5 Mhps - rounding), but if the script itself takes up a whole CPU the minerd's performance halves, so I get hardly 9-10 Mhps.

Oh, and hi!, BTW ;-)

You mean HD-4xxx and up, do you?

https://secure.wikimedia.org/wikipedia/en/wiki/Radeon#Processor_generations

I solved this myself, It was a permissions/folder attributes issue. I don't know exactly what the correct permissions are, but an xcopyOK of the previous version's folder; subsequently updated with the contents of the new version; works fine.