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

Run a separate instance of cgminer for each coin, and make a script that uses the API to enable GPUs on some instance, and disable them on all the others.

Third line of readme...

You're welcome.

Let me know if this is unsupported, but I think I found a bug (or my misunderstanding of the capabilities) in cgminer.  I'm running cgminer on BAMT with a GPU mining bitcoins and everything works just fine 24/7. 

I wanted to check out some FreiCoin (sha256d), so I added a second pool to my list of pools in cgminer.conf and then set rotate to 5 minutes.  My expectation is that every five minutes I would alternate between mining BitCoins and FreiCoins.  Everything seemed to work the first day, but the second day the BitCoin pool had some connection problems (stratum connection interrupted) and it kept switching between the pools.  Unfortunately it seemed that it would submit BitCoin work to the FreiCoin pool and vice-versa.  I got quite a few strange errors, including 'H not zero' replies from the pools.  Sorry, I don't have a good log right now.

Is this supposed to work?  Is there a better way to achieve this goal of mining two types of coins on the same hardware?

-E

P.S.  Thanks for the great software.

Tks for the reply, it is a very good tip for those who use several GPUs, i would be happy if it was my case but unfortunately i only use one. I tryed it just in case anyway but it didnt maked any change.

I will try look into Power saving configs. when the screen its turned off to see if there is smth i can change, meanwhile if someone got any idea or know what can be causing the problem it would be welcome some tips

Yes - I do already.
 https://bitcointalksearch.org/topic/m.2129102
and
 https://bitcointalksearch.org/topic/m.2137231

However at the moment it also requires options of --icarus-options 115200:1:1 --icarus-timing 2.9761=100

I'm now updating the code to automatically detect all Icarus devices (the AMU - AsicminerUSB is an Icarus device) and it will have similar to those options by default for the AMU and default options for Lancelot and Cairnsmore1 also

If you are using cards that support ULPS, disable it. Latest MSI Afterburner has a convenient checkbox for doing so. That's exactly what happens when the display is powered off on an ULPS-enabled card.

Also, with a 2x7970 Crossfire setup, I had to disable monitor power saving totally, just disabling ULPS didn't help there.

Tks for the tip, i haven't tryed that but looks easy and i got the resistances, but it will make a little energy drop there.

Im still wondering if there is some solution on software conf. that dont allow the GPU (ATI) to idle and drop near half of the hash power.

Tks for the sugestions /help

Short question: Is it possible to mine with several different fpgas at the same time? For instance a ztex board plus a few of these: https://bitcointalksearch.org/topic/m.2025318

Works that "out of the box" (start cgminer and that's it) or would that be somehow tricky?

Looks like the GPU is idling for some peculiar reason.
Did you try dummy vga plugs?

I recently moved to cgminer and i noticed that hash rate drop when screen power its turn off, is there a way to avoid that?

Shouldnt be the opposite as GPU no longer need to refresh the screen?


Most likely its some software config or any linux/windows configuration that i'm falling. Sry if its double post i tryed to search and found noothing related with this issue.

Tks in advance for the reply

You might also try using the IP of your pool instead of its domain name. just ping it to find out.

A perfectly valid question.

When cgminer sends shares via stratum, it does not send the share and then wait for the response as this might slow down the sending of other shares. This means that the response back from the pool is processed separately from the share submission (to make the most of a truly multithreaded environment). However there is never a guarantee that the responses come back in the same order you send them. So cgminer stores a copy of each share as it sends it to the server in its own local database of submitted shares. When it gets a response back about that share from the pool, it deletes the copy of that share. Now stratum is meant to be an uninterrupted connection to the pool, and if you lose that connection, it is assumed that your "session" is no longer valid. So if you send some shares and get disconnected before you get a response, cgminer has to assume that those shares have been lost - otherwise it may end up keeping copies of heaps of shares that it will never get a response to and wastes memory. If you manage to reconnect, sometimes the pool will actually tell you "oh by the way those shares are ok" - however cgminer has now thrown out the record of what those shares were and can only say that the pool said a share was accepted or rejected. Then cgminer just says it's an "untracked share".

Summary: Find a pool/network setup that gives you a more reliable connection.

i am mining with cgminer 3.1.0 with an stratum mining pool.
i often get this error: Accepted untracked stratum share from pool 0
What does this mean ?
Can somebody explain the reason for that ?

Thanks guys, your posts have helped me along to the right path. Although I was sure that X was correctly installed and running, it was not. Doing this first, then starting cgminer fixed it all up:

Thank you very much. I was starting to loose my mind over this

Thank you for the link. I came across this before but it isn't the problem. I tried it with real screens attached (and powered on) and that didn't change anything. The issue is not getting a nagging message, it's ADL not working with that "Failed to ADL_Adapter_ID_Get. Error -1" message.


Thank you Kano.

DISPLAY=:0 xlsfonts did not work at first as the package was missing as you said. "aptitude install x11-utils" took care of that. Now the result is this:

# DISPLAY=:0 xlsfonts
xlsfonts:  unable to open display ':0'

So there seems to be something not working right here. Any ideas on how to fix this?

I'm certain I did sudo aticonfig --adapter=all -f --initial (tried with one card, then the second) after each install, but just to be sure I did it again and rebooted the machine, with the same results still.

Very smart folks already spent many months optimizing the heck out of this code.  I doubt there is much room from improvement in the GPU mining kernels.

Check the names, one of them may give you a hint to the answer ...

Edit: and I should mention ... optimising code doesn't help if the code you are optimising doesn't affect performance.
Something I've seen over the many years I've worked on software, is most people don't understanding what needs optimisation.
First and foremost, in cgminer it is only the code that the devices will be waiting on and secondly performance monitoring is mandatory before optimisation - most people optimise code that doesn't affect performance in even a marginal way.

ADL requires correct X access.
Here's something to try see if X access is correct:
DISPLAY=:0 xlsfonts
(of course you need xlsfonts installed - use some other X program if you don't - xlsfonts doesn't open a window - just reports information)

Maybe gpu map is your solution (as it says to use)

Otherwise ... at a guess ... ADL version?

Edit: oh forgot, also on the 2 rig machine, you need to have done (in case you missed it) sudo aticonfig --adapter=all -f --initial as per GPU-README

Check this thread and see if its the same or similar problem.

https://bitcointalksearch.org/topic/m.1857068

How optimized is the mining engine in cgminer? Considering a USB ASICs device can get 300-400 MH/s mining, I can't help but think we should be able to get more performance out of a 7900 series GPU.

I'm a Software Engineer by trade, so I wouldn't mind dabbling around in cgminer development to try to improve GPU mining performance if I thought there was a decent chance of it bearing fruit.

Have very smart folks already spent many hours optimizing the heck out of this code, or is there still room from improvement?