The software should compile with osx. But since no one who uses osx is willing to compile it regularly and help me debug minor issues as they arise with osx, I can't tell you if it compiles or not. The software IS cross platform, but with no users what is there to say? The number of people building on osx is basically zero now. Mining on osx is expensive an inefficient; the hashrate is never as good as win/linux.

sudo aticonfig --adapter=all --initial -f

Indeed but I'm not advocating changes to raise voltage and engine clock speed further. There is no apparent limit to how high you can set engine clock speed with just the ADL support. I want to lower memory clock speed and voltage. Can't say that I've heard of underclocking or undervolting harming hardware.

OpenCL sees every display-enabled device as a separate device. This means that 2 displays on one GPU comes up as 2 devices and there is no way for the software to tell a virtual device from a physical one. So your one physical device attached to two monitors will be mined as though they're two separate devices and the overall hashrate will be identical, half coming from each. Apart from disabling one of the devices on the command line with -d, there is no workaround for this amd fail short of unplugging the monitor.

That means you have installed one of the drivers that use unnecessary CPU. Change your driver and there will be no need to set affinity.

You cannot define different numbers of threads per gpu. Use different intensities for that effect.

The normal failover mechanism in cgminer will allow some work to go to the backup pools if there is a delay in getting work from the primary pool you have set. This can be as much as 10% if the pool has latency issues. It then only fails to the backup pool if the primary pool stops giving work for 1 minute. failover-only does not change the failover mechanism, but it does not allow work to go to the backup pools unless the primary pool has failed completely for at least a minute. It then will switch to the backup pool. If cgminer considers a pool dead or down, it tries to contact that pool 1 minutely.

cgminer is limited by what the bios will accept via the driver. Often it is -way- outside the reported "safe range" that the ATI Display Library tells it. cgminer will allow you to happily ignore the safe range and set whatever you like. Some cards respond to that, some don't, ignoring values you pass to it. On my cards I can overclock my engine to any value I like and same with the memory. But try to set the memory more than 125 below the engine it ignores it (6970). It also happily ignores -any- voltage setting I pass to it. On the other hand, flash the bios on those cards and you can set whatever you like via the ATI Display Library and therefore cgminer. The other tools that hack via i2c and stuff are so device and OS dependent that they'd be a nightmare to write in a general fashion that could be included in cgminer. Sure if someone else did the code, I'd include it. But short of having one of each card, and every possible OS to test it on, I cannot write the code myself.

I've downgraded to the 8.921 driver for my 7970 on linux. 12.2 would crash the 7970 at lower engine clocks than normal and 12.3 would introduce rare but occasional hardware errors on the 7970 and would spontaneously crash a 6970, taking the device with it and I'd need to cold boot the machine for the 6970 to reappear. 8.921 was the version that needed a manually edited xorg.conf and specific card order to work with 7970 and 6970 was mixed.

Way to go AMD..

The fact is that the existing drivers -were- broken. It did not properly set up my mixed 7970/6970 rig and I had to put them a specific order on the motherboard to work, and to manually add devices to the xorg conf. So these problems should go away on moving from the preview release driver to 12.3. Furthermore, there were rumours of a very slight increase in hashrate going to 12.3. However, it introduced other problems as you've seen me say. But since I now have a working stable machine, I ain't changing it for shit unless there's a much more compelling reason.

I take it back. It is slightly less stable with 12.3 than with the 8.921 driver release. I randomly get a GPU disappearing with 12.3 that doesn't reappear after a spontaneous reboot, but its fan keeps spinning.

That's because people thought the number of stream processors they would have in them was far more than they actually ended up having.

The other thing is that sdk 2.4/2.5 should actually work fine and they're very close in performance to 2.1 anyway.

Small heads up. If you notice a hashrate drop in dynamic mode, you can tune  it with the

--gpu-dyninterval <arg> Set the refresh interval in ms for GPUs using dynamic intensity (default: 7)

parameter. The same exponential counter that adjusts hashrate display also affects detected dynamic speed changes and may affect your hashrate in dynamic mode on going to version 2.3.2.

It's worth noting that I spent a lot of time customising the poclbm kernel in cgminer as well so that it works well with sdk 2.6, and of course cgminer has a diablo kernel option as well.

I'm now using the 12.3 LLQL (Linux Low Quality Labs) release and it's satisfactory on my 6970s and 7970. The 7970 on linux would crash at lower than normal clock speeds with the 12.2 release but that problem has gone away with 12.3.

Although the actual bandwidth required for mining is minimal, the fact that requests go out simultaneously tends to stress some cheap routers. If you are using cgminer to mine with, try the --net-delay option.

Much appreciate the donation. Enjoy.

If you do use cgminer, be aware that un-flashed bioses on 69x0 will only allow you to set the memory to 125 lower than the engine clock speed.

Ok, try re-downloading.