OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[Diapolo]

Further investigation reveals the phatk kernel included with the current cgminer basically ONLY works with the  bfi int patching. That means the kernel itself needs fixing to even work in its current intended form, so there's still some work to go... However for those brave, at least you have an exe you can use with the kernel and you can delete the .bin files and manually fiddle with the code in the phatk*.cl file included. Other kernels taken from other projects diablo, diapolo, phoenix etc will NOT under ANY circumstances work directly as the API is different so don't waste your time trying that.

My current posted kernel version doesn't work with 7970, but I'm currently in the process of rewriting / reordering the kernel, which currently gives a performance of ~540 MHash/s for my 7970 card (this was over 100 MHash/s lower before I started my work). I guess there is still more potential in it, DiabloD3s kernel seems to be even faster! But as Con said, this won't work for CGMINER ...

Dia

[1714141275]

1714141275

[1714141275]

1714141275

[1714141275]

1714141275

[-ck]

Further investigation reveals the phatk kernel included with the current cgminer basically ONLY works with the  bfi int patching. That means the kernel itself needs fixing to even work in its current intended form, so there's still some work to go... However for those brave, at least you have an exe you can use with the kernel and you can delete the .bin files and manually fiddle with the code in the phatk*.cl file included. Other kernels taken from other projects diablo, diapolo, phoenix etc will NOT under ANY circumstances work directly as the API is different so don't waste your time trying that.

My current posted kernel version doesn't work with 7970, but I'm currently in the process of rewriting / reordering the kernel, which currently gives a performance of ~540 MHash/s for my 7970 card (this was over 100 MHash/s lower before I started my work). I guess there is still more potential in it, DiabloD3s kernel seems to be even faster! But as Con said, this won't work for CGMINER ...

Dia

It's most unusual that you work with only phoenix... it's not like working with cgminer is hard.

[-ck]

Further investigation reveals the phatk kernel included with the current cgminer basically ONLY works with the  bfi int patching. That means the kernel itself needs fixing to even work in its current intended form, so there's still some work to go... However for those brave, at least you have an exe you can use with the kernel and you can delete the .bin files and manually fiddle with the code in the phatk*.cl file included. Other kernels taken from other projects diablo, diapolo, phoenix etc will NOT under ANY circumstances work directly as the API is different so don't waste your time trying that.

I've upgrade a *potential* fix for the phatk kernel in here:
http://ck.kolivas.org/apps/cgminer/temp
Make sure to right click on phatk110817.cl and choose save link as to avoid your browser turning into html falsely. 79x0 Try replacing the file with that one with the new exe and see if that submits valid shares...

[-ck]

Ah.  Gotcha.  I'll give it another go.Well, in that case, there's another thing to sort out that doesn't make any damn sense (of course).  The phatk kernel doesn't always run on GPU0.  It's fairly random.  It always runs on the other 3 cards every time.  CGMiner pauses with a message about closing other apps that use the GPU (like Afterburner).  If I close CGMiner and restart it with the same command line, it'll run.  It's probably 50/50.  

Yes this is the never ending mindfuck that is windows creating a binary that reports size zero after it's built. Then it changes its mind and works the next time around. It's a bug that's plagued cgminer on windows for 6 months now and makes no sense whatsoever to anyone.

Uploaded a fresh .exe which may fix this problem. It turns out I may have been attempting to build the opencl program twice.

[Diapolo]

It's most unusual that you work with only phoenix... it's not like working with cgminer is hard.

I like the fact, that with Phoenix I don't have to fiddle around with a compiler, headers, paths and so on. I can edit a plain text file to change things I need for initialisation (even if I dislike Python ^^) and simply start phoenix.exe without recompiling after every small change + I can redistribute my changes without the need for a new executable.

In no way I want to say Phoenix is better or worse than CGMINER (I know you work hard and do a great job), but for the things I do it's easier for me to use Phoenix .

Dia

[kano]

I am presuming you are talking about the .CL code ... coz it's not entirely clear ...

With cgminer all you have to do is change is the .CL file (then delete a file) and nothing more if you are dealing with that side of things ...
Replace one .CL file with a new one (or edit it) and delete the .bin and that's it.

Next time you start cgminer it will compile the new .CL internally and generate a .bin and run that in the GPU
So after editing the .CL, the hardest step (of only 2 required) is to delete a .bin file
(the other step is to run cgminer ... though that can be difficult for some also ...)

[-ck]

You only would need to compile and shit if you change the API. If the API is static and you're just fiddling with the cl code, modify the cl file, just delete any .bins generated and start the app again.

[-ck]

So I got some debugging on a 6990 and found that, of course, it does things differently to the 5970.

I've committed some changes to the git tree which should detect 5970s and 6990s reliably on linux, and mumble mumble something maybe on windows. I have at least one report of success on windows with 5970 already.

You can now also mine with 7970s if you specify the poclbm kernel with -k poclbm, but it will perform poorly so it's not recommended.

Intensity can also be increased beyond 10 now (specifically put there for the 7970s) but it is highly advised against for most cards, where 8-9 is usually best.

All this and more, and I even made an exe for windows (this is not the final new version).

http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe

This is taking longer than I'd hoped for the next release to come out, but there are still some final touches to put to it, and I really want things working well. Alas 7970 support is still woeful for now, but that will change thanks to this: https://bitcointalk.org/index.php?topic=61027.0

Give it a go and report back!

[JWU42]

Thanks again Con!

As he reported, the windows .exe is working perfectly on my windows box with a 5970 -- reporting fan RPMs for both GPUs.  Pulling from git also fixes that on my dedicated linux miners.

[freakfantom]

So I got some debugging on a 6990 and found that, of course, it does things differently to the 5970.

All this and more, and I even made an exe for windows (this is not the final new version).

http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe

Give it a go and report back!

New exe is working fine as far as I can see on windows x64 3x6990

[kano]

On a completely different side of things - regarding the USB install script that I wrote that's with cgminer (that's always in my sig also)
For the 3rd time in 6 months having to redo it (so yeah only 2 failures in 6 months seemed pretty good actually) I finally had it just keep messing up on me while trying to make the 3rd one.

So I worked out why there are problems with it for some and am working on a new version of the script.
(the problem details were found googling something rather non-obvious!)

Note of course that the current version includes (at the end) the details to do an HDD install - and that is basically how the new version will work, but onto a USB.

It seems that the problems with the USB creator program have been known for 4.5 years (f#&king hell that long!) and still they haven't bothered to fix them!
Basically there are 2:
1) The USB key is ejected during shutdown and some (most?) BIOS's don't reinitialise the USB during a restart, only (of course) during a power off and on, so it's random if it actually works on a reboot or not
2) The casper filesystem (that's the persistent storage) often doesn't properly write all changes to the casper file (yeah I've seen that happen on rare occasions with small system settings) and that can even sometimes mess up the whole USB - like it did for me the other day.

Anyway after failing over and again with a new USB, I ran a full check of the 2nd one that had just failed and found the USB itself was 100% OK just the data was messed up.
So I used that one instead with the new procedure and it is working (and rebooting) fine without any problems or errors.

I'll have it finished (documented) in the next few days and that should hopefully get rid of the biggest issue with the USB install for most people who have had problems with it and don't know why.

[jjiimm_64]

I would like to report an interesting issue that might give a clue to why cgminer not working well with 7970.

known:
  I have been running cgminer all defaults except clocks on both linuxcoin and windoz7
  I get similar hashrates on both for similar cards. (mostly 5870 and 5970)
  the 7970 is very sensitive to the vectors and worksize flags. and afaik, we only have new amd drivers in win boxes


today, someone suggested I try and use  -v 2 and -w 256 on my 5970 rig to test..  and it worked great, got about 5Mh per gpu on that one box. I immediately changed all my rigs to use these settings.  (thxs sunb, added about 600Mh to farm)

so, here is the kicker, I get to the last box. a windows 7 rig with a 5830 and 2x5970s.  My hashrate dropped significantly when I added the flags to this rig.

What worries me is, that when I/we get the 7970's onto the linux boxes with brand new shiny drivers, will those drivers lower the hashrate on the older gen cards that love the -v2 -w256?

I thought this might give a clue to the problems with the 7970,

Jim

[DeathAndTaxes]

so, here is the kicker, I get to the last box. a windows 7 rig with a 5830 and 2x5970s.  My hashrate dropped significantly when I added the flags to this rig.

Did it lower just the 5830 or did the 5970 individual hash rates drop also.  Each model has different # of ALU and thus respond differently to differently to changes in vector & work size.    Really all the v & w flags are doing is trying to optimize the # of ALU used in each clock cycle.  So if the 5970 rose but 5830 tanked it likely is just due to chip differences.  There is no "perfect" setting as each chip has different # of ALUs.

If the 5970 individual hashrate dropped on Win7 and rose on Linux then provide the driver & SDK versions used on both platforms.  It most likely is driver/SDK dependent.

[lodcrappo]

one tiny suggestion, you could make the api socket work a lot faster after a restart by setting SO_REUSEADDR with setsockopt.  I do not know if this might have negative effects on systems other linux, but it works fine here and makes socket always open on first try (no more "API bind to port %d failed - trying again in 15sec", which I was seeing quite a lot).

doubt you actually need the code from me heh.  but in case, at line 889 of api.c, after sock is returned from socket()..

int optval_reuseaddr = 1;
setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &optval_reuseaddr, sizeof(optval_reuseaddr));

or something like that..  makes life nicer.

[jjiimm_64]

so, here is the kicker, I get to the last box. a windows 7 rig with a 5830 and 2x5970s.  My hashrate dropped significantly when I added the flags to this rig.

If the 5970 individual hashrate dropped on Win7 and rose on Linux provide the driver & SDK versions used on both platforms.  It most likely is driver/SDK dependent.

I noticed it immediately on the 5970's.  down to like 320ish.  I think the 580 was lower too but was inconsequential since the clock on the box is 800/300 for all cards. ( I bump the 5830 up manually if I feel like it )

[tnkflx]

So I got some debugging on a 6990 and found that, of course, it does things differently to the 5970.

I've committed some changes to the git tree which should detect 5970s and 6990s reliably on linux, and mumble mumble something maybe on windows. I have at least one report of success on windows with 5970 already.

You can now also mine with 7970s if you specify the poclbm kernel with -k poclbm, but it will perform poorly so it's not recommended.

Intensity can also be increased beyond 10 now (specifically put there for the 7970s) but it is highly advised against for most cards, where 8-9 is usually best.

All this and more, and I even made an exe for windows (this is not the final new version).

http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe

This is taking longer than I'd hoped for the next release to come out, but there are still some final touches to put to it, and I really want things working well. Alas 7970 support is still woeful for now, but that will change thanks to this: https://bitcointalk.org/index.php?topic=61027.0

Give it a go and report back!

Does his mean you don't need another Linux/6990 box?

[cablepair]

so, here is the kicker, I get to the last box. a windows 7 rig with a 5830 and 2x5970s.  My hashrate dropped significantly when I added the flags to this rig.

If the 5970 individual hashrate dropped on Win7 and rose on Linux provide the driver & SDK versions used on both platforms.  It most likely is driver/SDK dependent.

Did it lower just the 5830 or did the 5970 individual hash rates drop also.  Each model has different # of ALU and thus respond differently to differently to changes in vector & work size.    Really all the v & w flags are doing is trying to optimize the # of ALU used in each clock cycle.  

I noticed it immediately on the 5970's.  down to like 320ish.  I think the 580 was lower too but was inconsequential since the clock on the box is 800/300 for all cards. ( I bump the 5830 up manually if I feel like it )
[/quote]

jjimm64: where do you put the -v -w 256 - I have 15 5870s and would like to try this , when I use -v -w 256 with cgminer it does load for me

thanks!

[os2sam]

so, here is the kicker, I get to the last box. a windows 7 rig with a 5830 and 2x5970s.  My hashrate dropped significantly when I added the flags to this rig.

If the 5970 individual hashrate dropped on Win7 and rose on Linux provide the driver & SDK versions used on both platforms.  It most likely is driver/SDK dependent.

Did it lower just the 5830 or did the 5970 individual hash rates drop also.  Each model has different # of ALU and thus respond differently to differently to changes in vector & work size.    Really all the v & w flags are doing is trying to optimize the # of ALU used in each clock cycle.  

I noticed it immediately on the 5970's.  down to like 320ish.  I think the 580 was lower too but was inconsequential since the clock on the box is 800/300 for all cards. ( I bump the 5830 up manually if I feel like it )

jjimm64: where do you put the -v -w 256 - I have 15 5870s and would like to try this , when I use -v -w 256 with cgminer it does load for me

thanks!
[/quote]

After the pool logon's and before CGMiner specific switch's.  Also my 5830 would only accept -w 128 NOT -w 256.  So you may have to specify each GPU independently if your 5970 does accept it but 58xx doesn't.
Sam

[jjiimm_64]

so, here is the kicker, I get to the last box. a windows 7 rig with a 5830 and 2x5970s.  My hashrate dropped significantly when I added the flags to this rig.

If the 5970 individual hashrate dropped on Win7 and rose on Linux provide the driver & SDK versions used on both platforms.  It most likely is driver/SDK dependent.

Did it lower just the 5830 or did the 5970 individual hash rates drop also.  Each model has different # of ALU and thus respond differently to differently to changes in vector & work size.    Really all the v & w flags are doing is trying to optimize the # of ALU used in each clock cycle.  

I noticed it immediately on the 5970's.  down to like 320ish.  I think the 580 was lower too but was inconsequential since the clock on the box is 800/300 for all cards. ( I bump the 5830 up manually if I feel like it )

jjimm64: where do you put the -v -w 256 - I have 15 5870s and would like to try this , when I use -v -w 256 with cgminer it does load for me

thanks!

After the pool logon's and before CGMiner specific switch's.  Also my 5830 would only accept -w 128 NOT -w 256.  So you may have to specify each GPU independently if your 5970 does accept it but 58xx doesn't.
Sam
[/quote]

I put the flags in the conf file. 

"vectors" : "2",
"worksize" : "256",

[kinlo]

So I got some debugging on a 6990 and found that, of course, it does things differently to the 5970.

I've committed some changes to the git tree which should detect 5970s and 6990s reliably on linux, and mumble mumble something maybe on windows. I have at least one report of success on windows with 5970 already.

Give it a go and report back!

I gave that windows build a spin and unfortunatly it doesn't work like it should.

I have 2x6990, so 4 GPU's visible for cgminer.  I've ran it with 3 gpu's enabled, one disabled.  By looking at the temperature, it is clear that cgminer is not showing the correct temperature for the correct core.  Also, this version does not show temperatures for cores that are disabled, I think it would be useful if we still can see that.
Next remark: I see (always have, unchanged in this version) for my 2 first cores the RPM's for the fans, but the other 2 just show a percentage...