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

Nope nope, as I've said numerous times before this is the most unsatisfying part of it.
The opencl information is useless for determining which card is which. Furthermore if you have 2 monitors connected to a single GPU, it will come up as 2 unique opencl devices.
Then motherboards decide to order cards backwards sometimes with the pci bus id order being the opposite of the device order we end up getting.
Some motherboards do not order their PCIE lanes in numerical order as well, with lanes going 1,3,2 or other randomness.
Then the ATI Display Library gives unique adapter ID information that has absolutely nothing in common with the opencl devices.
The ADL will also give you one for each device, including the ones that don't have OpenCL support so if you have a card that can't mine in your setup, the number of devices cannot match.
There are also unique "thermal devices" in the ADL which had the opportunity to designate GPU 0 and GPU 1 in shared devices (like 6990) but instead they simply come up as unique devices.
Shared GPUs in single cards also do not have a single identifying feature whatsoever to say they're on the same card.
Then of course, windows does something different to linux, and osx doesnt even have an ADL.
All I can do is enumerate them in the order they appear and *hope* they align.
Then I use surrogate markers with circumstantial evidence that the GPUs are on the same card.
As far as I'm concerned, getting any of these bastards behaving in concert is somewhat of a miracle.
All in all it's a mindfuck of epic proportions.

Want me to really ruin your day?

For me the order of GPU (for 3x5970 rig running windows 7) in the config file is different than the order of the GPU as reported AND the pairs of cards are in differing order too.  I never brought it up because I (via trial & error) got it working and nobody else has ever reported it BUT

I have a 3x5970 watercooled rig.  The only thing I can think that might contribute is that 2 of the cards are ATI reference and one is an XFX black edition.


It took forever for me to figure this out.  I got suspicious because when I raised the overclocked on the fastest GPU it was always the slowest GPU that crashed and lower its clock even down to stock didn't help.  So to test my theory I intentionally set the clocks to something like:

   

and then checked the shares submitted after an hour.


Does AMD API exposed a card serial # or any other unique identifying information?

BTW I don't have this problem in Linux.

Righto, well still some work to do then 

I was the one with the out of order 5970's on win7

miner14 is a win7 box
http://cgminerweb.com/example.miner.php.html#miner14

miner16 would be a more normal view for 5970s

This is a windows machine, yes? Was this one where the two GPUs from the same card would be not one after the other? I don't know if I can pick those up at all. As I've said before, false positives for linked GPUs would be a big problem whereas false negatives would be no worse than current releases of cgminer. I'll try and make a debugging version for windows which might give me more information.

Im going to assume that that's Because you 6990's only have 1fan Per GPU? Durr? AKA 2 fans, AKA 2 readouts

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...

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",

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

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!

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

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 )

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.

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.

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

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.

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

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.

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://bitcointalksearch.org/topic/collection-for-cgminer-7970-card-as-been-sent-thank-you-everyone-61027

Give it a go and report back!

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.