I tried the search function, but I didn't get any results, so gonna ask my question.

Can I cap the processing power this can use? I'd like to be able to limit it to 50% or so power so I can still get decent gaming performance.

You shouldn't have to if you use -f. Try adding -f 120 to the command line and play a game. The game framerate will be just slightly degraded; I don't usually notice a difference. If you have dual monitors and put the miner on the one you don't use for gaming, you'll notice that the hashrate will drop dramatically while you play. Basically it will be using the extra GPU cycles that the game is idle during.

Tips are always welcome and can be sent to 1CZ8QgBWZSV3nLLqRk2BD3B4qDbpWAEDCZ

I removed one of my video cards for a bit and noticed the poclbm was not using 100% of a cpu core any more. The second I added back in my 2nd card cpu usage jumped up to 1 full core pure instance of poclbm. Apparently the high gpu usage is tied to dual card setups.

Although, the problem is not seen on Windows XP. I have a miner running XP, that has dual 5870s, and poclbm doesn't eat cpu there. It may only be a Windows 7 issue.

I removed one of my video cards for a bit and noticed the poclbm was not using 100% of a cpu core any more. The second I added back in my 2nd card cpu usage jumped up to 1 full core pure instance of poclbm. Apparently the high gpu usage is tied to dual card setups.

Although, the problem is not seen on Windows XP. I have a miner running XP, that has dual 5870s, and poclbm doesn't eat cpu there. It may only be a Windows 7 issue.

Maybe this can help track it down.

On Linux Ubuntu 10.10, I think it maybe a bit more complicated than this ... I've noticed that when you run a graphical tool to monitor CPU/Mem usage (whilst miners are running) then the CPU usage skyrockets. If you use the command line tool

$top

the CPU usage stays low around 3-5%, and it is mostly on Xorg that is using the CPU. In fact, I think if you run any process that has graphics GUI or other then Xorg goes nuts, it must be competing with poclbm for the GPU, even when you give it a -f 30 ....

A slightly related anomaly I noticed one time, after loggin in on boot-up I set all miners off and they were getting ~2MHash more than they normally do for about 10-15 seconds, but then something happened and they dropped back to normal speeds ... so i suspect Xorg hadn't woke up and stuck its nose in yet ... so to test the theory i rebooted and ran fgl_glxgears immediately on logging in. Similar behaviour, for 10-15 seconds I was getting 3000+ fps and then it stopped and throttled back to < 1000 fps ... so something (Xorg most likely) is definitely jumping in and throttling poclbm and fglrx from running at optimum ... unfortunately it also eats CPU as it does it. Managing GPGPU processing with Xorg is a kludgy idea, can't believe this is the best AMD can come up with.

I'm pulling in 330 Mhash/s on average at the moment. Tends to bounce around from 328-336.

It's been going for about an hour and the temperature reading from the catalyst control center is 74c, activity 98%, fan speed 70%.

I'm using the following flags : -v -w128

Looking from the hardware comparison table I should be able to pull out some more, possibly up to 350. Do you think those kinds of results are only possible on a dedicated box running Linux? I'm not sure whether to downgrade the SDK to 2.1/2.2 to test it though. Also heard people were having problems with the GUI miner on 2.1, thoughts?

Be aware, that for what ever reason, OS X is FAR slower for mining than Linux or Windows. I run this on a Mac Pro with a pair of ATI Radeon HD 5770s. In OS X I get about 65Mhash/s on one and 95Mhash/s on the other. I installed Ubuntu 10.10 and boot into it through Bootcamp. There I get 170Mhash/s on each card, over 2x the performance.

thanks.

using poclbm gives me about 3400 khash/s (4500 with -f 15 -w 64) while using diablominer i get 5500khash/sthis is on a 2010 mbp with a GeForce 320m

The OpenCL part is supposed to calculate the 8 first bytes of the hash. The 4 first bytes are calculated fine, but the next ones are not, so they end up being essentially random numbers. In specific situations, it could lead to the miner ignoring a valid block.

I saw the target given to OpenCL is hardcoded. I changed 0xFFFF0000 to 0x80000000. That should cause the OpenCL part to return nonces that result in hashes having the first 8 bytes lower than 0x0000000080000000, right?

Turns out it doesn't. When I ran poclbm, I got the "Verification 2 failed" message in a few minutes.

For some reason, there is commented-out code in BitcoinMiner.cl that modifies G, which should be the bytes 4-7 of the resulting hash in the end.

Why is this a problem, then? If the bytes 4-7 of the real hash are below the current target, but the OpenCL program calculates that they're over the hard-coded value of 0xFFFF0000, it would lead to a valid block being ignored, and no BTC for you.

Proposed fix: As the bytes 0-3 are calculated correctly and the target given to OpenCL is hardcoded anyway, I'd drop the target being sent to OpenCL altogether and have it just report nonces that lead to hashes for which the first 4 bytes are zero.

Looking from the hardware comparison table I should be able to pull out some more, possibly up to 350. Do you think those kinds of results are only possible on a dedicated box running Linux? I'm not sure whether to downgrade the SDK to 2.1/2.2 to test it though. Also heard people were having problems with the GUI miner on 2.1, thoughts?

You can try with lower -f, i.e. under 20. Or you can overclock your GPU (core, memory doesn't affect performance) a little. I don't think downgrading to 2.2 will bring much more.

The OpenCL part is supposed to calculate the 8 first bytes of the hash.

No. The kernel computes correctly only the 4 first bytes. It's confusing, because there is a code in BitcoinMiner.cl BelowOrEquals() which checks 8 bytes - this produces better assembler for some reason, at least in my setup. It can be replaced with 'if (H == 0)' (but it was slower). That's exactly why the targets are hard coded to difficulty of 1 (00000000 FFFF0000).

Quote

The 4 first bytes are calculated fine, but the next ones are not, so they end up being essentially random numbers. In specific situations, it could lead to the miner ignoring a valid block.

Actually you are right, but in a different way - because of this I should use hard coded kernel target of 00000000 FFFFFFFF in order to not lose 1 thousandth of a percent of all valid difficulty=1 candidates. I'll do this with the next release.

Quote

Code:

elif h[6] > 0x80000000:

...

I saw the target given to OpenCL is hardcoded. I changed 0xFFFF0000 to 0x80000000. That should cause the OpenCL part to return nonces that result in hashes having the first 8 bytes lower than 0x0000000080000000, right?

Why you check for 'lower' with a 'greater than' operator? Where did the '0x80000000' came from?

Can someone give me advice how to stable this miner on 5970, MSI afterburned to 875MHz core | 695MHz memory? MHashes/s are way too low - approx. 530, they must be around 640-650. Current extra flags are -v -w128.I'm using 11.4 the early preview version under Windows 7 x64 because every other driver gives me a bsod

No. The kernel computes correctly only the 4 first bytes. It's confusing, because there is a code in BitcoinMiner.cl BelowOrEquals() which checks 8 bytes - this produces better assembler for some reason, at least in my setup. It can be replaced with 'if (H == 0)' (but it was slower). That's exactly why the targets are hard coded to difficulty of 1 (00000000 FFFF0000).

then I got very different results in my tests on Windows 7 x64 & HD5850.

With belowEquals I get ~270MhpsWith the H == 0 version I get ~275Mhps

That's a 1.8% speed increase.

Quote

Actually you are right, but in a different way - because of this I should use hard coded kernel target of 00000000 FFFFFFFF in order to not lose 1 thousandth of a percent of all valid difficulty=1 candidates. I'll do this with the next release.

I'd just stop the target from being sent to the GPU and do that H==0 thing. I see no logical reason that it would be slower. There might be illogical reasons, though :-)

Quote

Why you check for 'lower' with a 'greater than' operator? Where did the '0x80000000' came from?

I guess I didn't explain that part that well. I chose 0x80000000 to make it easy to determine if bytes 4-7 were actually calculated correctly. I edited BitcoinMiner.cl to only accept hashes below 0x80000000. In the Python code, "> 0x80000000" (should've been >= though) is checking if that part of the hash is over 0x80000000 and warns the user if it is, i.e. if the GPU calculated the hash wrong. But none of that matters since it wasn't even supposed to calculate bytes 4-7 right.

A pool I'm trying to connect to requires a higher TIMEOUT than the 5 set in BitcoinMiner.py. Would it be possible to make that into a parameter so I can avoid having to recompile it? I attempted it anyway but I just don't have the time to install and configure all the required prereqs.

No. The kernel computes correctly only the 4 first bytes. It's confusing, because there is a code in BitcoinMiner.cl BelowOrEquals() which checks 8 bytes - this produces better assembler for some reason, at least in my setup. It can be replaced with 'if (H == 0)' (but it was slower). That's exactly why the targets are hard coded to difficulty of 1 (00000000 FFFF0000).

then I got very different results in my tests on Windows 7 x64 & HD5850.

With belowEquals I get ~270MhpsWith the H == 0 version I get ~275Mhps

That's a 1.8% speed increase.

Quote

Actually you are right, but in a different way - because of this I should use hard coded kernel target of 00000000 FFFFFFFF in order to not lose 1 thousandth of a percent of all valid difficulty=1 candidates. I'll do this with the next release.

I'd just stop the target from being sent to the GPU and do that H==0 thing. I see no logical reason that it would be slower. There might be illogical reasons, though :-)

Quote

Why you check for 'lower' with a 'greater than' operator? Where did the '0x80000000' came from?

I guess I didn't explain that part that well. I chose 0x80000000 to make it easy to determine if bytes 4-7 were actually calculated correctly. I edited BitcoinMiner.cl to only accept hashes below 0x80000000. In the Python code, "> 0x80000000" (should've been >= though) is checking if that part of the hash is over 0x80000000 and warns the user if it is, i.e. if the GPU calculated the hash wrong. But none of that matters since it wasn't even supposed to calculate bytes 4-7 right.

mOmchill,

Is this H==0 mod. going to go into official version of poclbm miner on github ?

I just installed the 270.61 nvidia drivers, and it seems to make the drivers crash each time I exit poclbm by clicking the x, if I ctrl-c they seem to exit fine most of the time. Nothing serious yet, but I keep getting these in my system event log: