Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 681. (Read 5805728 times)

Sorry, I meant is it the same *.bin file you are running with each one.
When you start cgminer the first time it creates the *.bin file.
Every time after that it will use the *.bin file it created the first time (unless you delete it)
The fastest *.bin should perform at the same speed no matter which version of cgminer you are using (unless there is a problem with the cgminer version you are using)

Lastly:
cgminer -n
cgminer -V
will report info - what do they say?

i had to compile them, because i made the mistake of installing an x86 debian on my home server (before reinstalling it, i was able to use your binaries).

On windows i use your binaries, of course.

Also, on windows, the difference is less noticeable, but its there too.

I mine only with 5830 (i recently got a new rig with 2 5850, with ubuntu, but i havent touched it yet, the previous owner had phoenix running, and its still running.

ps: how can i run cgminer when the user logs in, automatically ? i tried putting the script i use, but nothing happens (it does work if i double click it, i have it in /home/user/bitcoin, with a symlink on the desktop, which is what i use)

usual ... is it the same binary?
What does cgminer -n report for each ...
Edit: and cgminer -V
and are they pre-built or did you compile them?

i finally got the time to compile 2.1.1, 2.1.2 and 2.2.1 on my debian machine (sdk 2.4).

Just like in windows, 2.2.1 is slower than 2.0.7, 2.1.1 and 2.1.2.

My hd5830 running at 975/300 produces 300 to 315 MHASH with the older versions, but with 2.2.1, it produces 280 to 290 MHASH.

I'm not sure if this would indicate effectiveness of your fix for false positives on pools providing work, but thought I would provide it just in case:
Fedora 15 x64, cgminer 2.2.1, no shares were submitted to other pools in the vicinity of these records.

yes I understand that, I have had best luck with 11.9 with the sdk it with, I recently tried many others including sdk 2.1 and 2.4

for windows 7 x64 radeon 5xxx I can confirm you cant get better than 11.9 with the sdk that comes with it.

should be not. if only the heatsink is still on the chip, the FPGA is hard to burnout by a fan fail. a FPGA only generate about 6~7W heat, much less than a GPU. but it will output error data at first.






  FPGA mining is not a heat concentrated project. engineers rarely pay attention to overheating protection on these stuff. at least that's my case.
spartan-6 FPGAs haven't a built-in thermal sensor. so a monitor of temperature needs additional hardware, and logic in the FPGA.
may i put a "heat switch" on board, and simply reset the FPGA when they reached a TEMP protect point? so the software will notice the FPGAs stopped and tigger some exception handling code?

The 11.9 driver or the SDK that comes with it? Or both?

Remember that you can use any combination of driver/sdk, for example you could install 12.1 and afterwards install SDK 2.5.732.1 (which comes packed with the 11.9 driver).

thank you for posting that information, thats quite useful info, I have tested them all and the best for mining with 5xxxx in windows is 11.9 without a doubt

Almost 24 hours has passed since 2.2.1 without massive death and destruction this time. Thank goodness. 

Did you try other versions of the 2.5 SDK, aside from 11.7? Any performance differences?

I just did a quick review of SDK versions from driver 11.6 to 12.1 and this is what I got:
(In bold are the highest minors for each major version)

SDK2.4 - SDK 2.4.595.10
11.6     - SDK 2.4.650.9
11.7     - SDK 2.5.684.213
SDK2.5 - SDK 2.5.684.213
11.8     - SDK 2.5.709.2
11.9     - SDK 2.5.732.1
11.10   - SDK 2.5.775.2
11.11   - SDK 2.5.793.1
SDK2.6 - SDK 2.6.831.4
11.12   - SDK 2.6 (10.0.831.4)
12.1     - SDK 2.6 (10.0.851.4)

I'm currently on 11.6 (driver & sdk 2.4.650.9) with 2x5850's but I think I'll try 12.1 with SDK 2.5.793.1 from the 11.11 driver to see how it goes!

Cheers!

no, i'm not the one.  the btc i sent was to ckolivas directly.

thank you.  your probably the 'unknown' i just put on the list

LOL, i don't own one and i just sent him some btc!  but i guess one day i might...

It does, just not well. If you would like to help improve it look here https://bitcointalksearch.org/topic/collection-for-cgminer-7970-card-as-been-sent-thank-you-everyone-61027

sorry to ask this but this thread is so fricking long!

when will cgminer support 7xxx video cards?

Thanks a lot, but as I said, mine came back yesterday so assuming it stays up and running with the new motherboard, I will be fine 

ckolivas if you need a rig for testing, let me now / drop me a mail and we'll find a way

ocminer

And thank you

Okay so the GPU reorder saga brought up a few issues, lemme explain just for reassurance.

OpenCL and the ATI Display Library have completely different numbers for their devices - and there is no way to correlate the devices

- If they report exactly the same number of devices, and ADL was working properly (built in etc) then the last release worked fine.
- However OpenCL will report more devices than ADL if you have more than one display connected to one GPU.
- OpenCL will report less devices than ADL if you have a card that has no mining support.
- ADL will report only one device if you don't export DISPLAY on linux, or if you use some remote viewer on windows (I think).

On 2.2.0:
If you had less ADL devices than OpenCL, only the ADL devices would work, but the devices that worked on 2.2.0 would be different to the ones working on 2.1.2 because of the changed order.
->If you had less ADL devices, it would put all the mining threads on the one device.
If you had more ADL devices than OpenCL, hardware monitoring wouldn't work.
->If hardware monitoring didn't work, you often couldn't mine at all/crash whatnot.
On Linux the ordering was almost never out of order (unlike windows) but it was reversed. However it was not universally reversed...

On 2.2.1: Now I can cope with discrepancies in the number of devices and still have the option of trying to reorder by bus ID. So it's quite a safe option now, whereas previously it worked more often than not, but when it didn't work it would do weird and wonderful things.

It was getting impossible to debug this without a real mining rig and it was just fortuitous that my rig came back to me yesterday.

All in all, I was just dealing with more AMD facepalm...

FYI, the crash I reported is gone with the latest updates. Thanks!