OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 612.

P_Shep

legendary

Activity: 1795

Merit: 1208

This is not OK.

Quote from: kano on March 22, 2012, 11:44:25 AM

I've put a few commits in my git:
https://github.com/kanoi/cgminer/
that add a simple device history that is accessible via the new API command 'notify'

Compiling my git reports itself as 2.3.1k

You can see it with

Code:

echo -n notify | nc 127.0.0.1 4028 ; echo

The base code change adds a few extra fields and counters to the device structure (that are all reported by the API)
Including: per device: last well time, last not well time, last not well reason, and counters for each of the reasons meaning how many times they have happened (e.g. Device Over Heat count, Device Thermal Cutoff count among others)

Wondering if you can make it retrievable per device?

I don't think this is info that needs to go on anubis' host page (where the devices are listed). Seems to be more detailed then necessary for that page, so I would put it on the individual device page, but then I'd have to get the whole list and find the relevant entry.
Thoughts?

vapourminer

legendary

Activity: 4354

Merit: 3614

what is this "brake pedal" you speak of?

Quote from: sharky112065 on March 24, 2012, 02:58:06 PM

I'm re-posting this for people wanting to compile on Windows. Tends to get lost in all the posts. Hopefully ckolivas will one day put the link in the README included with cgminer.

Cgminer native Windows compile instructions:

http://pastebin.com/3pzivj32

+1. a link in the readme would great.

I can attest this howto works perfectly. if I can do it, anyone can.

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: jake262144 on March 25, 2012, 07:02:04 AM

Utility... an indicator I didn't even consider. Sounds good.

Actually, on second thoughts, it would be better to simply compare results every minute - shares accepted in the past 60 seconds - thus you'd have to remember "Accepted" between "API pools" calls (and maybe "Rejected" also)
If you have a low hash rate you may need 120 seconds

jake262144

full member

Activity: 210

Merit: 100

Utility... an indicator I didn't even consider. Sounds good.

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: jake262144 on March 25, 2012, 05:41:15 AM

Quote from: kano on March 24, 2012, 11:34:40 PM

You'd go to a lot of trouble to do that Tongue

You could just have a script that uses the API and enables/disables each of the 2 pools as required

My approach stemmed from the fact that it was boozer who reported a range of horrible events like cards dying constantly, cgminer eating the whole available memory space and bringing the system to a screeching halt...
Oh and yes, using the API calls to interact with cgminer would be by far preferable - I never suggested using messenger pigeons or necromancy in the overseer script. Cheesy

The rest - such as actually detecting the pool-related issues remains the same, doesn't it? At least until the PoolIsInTrouble API is added.

Quote from: DeathAndTaxes on March 24, 2012, 11:39:09 PM

API for the winz. So glad that thing exists. Boy it certainly was a smart idea for *someone* to start a bounty for that.

*stroking DAT's head* good Death, wise Death. We're certainly glad to have thee aboard Grin

Oh - you want to to add "Last Share Time" to each pool?
Each device already says it - I guess it wouldn't hurt to have each pool say it too ... maybe one day ... if I'm bored ... or someone needs it Tongue

However, the point was to actually handle swapping 2 pools and that is already easily possible.

Since you only have one active pool at a time:
Look at each device to determine when the last share was ... and the device "Utility".

Edit: I guess next we'll be telling pool OPs to run cgminer and get it to tell them when their pool has crapped out

But I should also mention that pools are unreliable anyway - you cannot know immediately that a pool is bad - it takes a bit of time.
If you decided every time a pool returned some problem or didn't reply, you'd be swapping pools faster than my API pool hopping script ...
Did I say that? No - never

When I implemented the pool control in the API I actually wrote a script that same night to hop before I even released the API code change Tongue

Just as a test example of course

That works

However, if you hop lots with cgminer you lose hashes - last time I tried it was about a 2%-3% drop in hash rate due to swapping pools.

jake262144

full member

Activity: 210

Merit: 100

Quote from: kano on March 24, 2012, 11:34:40 PM

You'd go to a lot of trouble to do that Tongue

You could just have a script that uses the API and enables/disables each of the 2 pools as required

My approach stemmed from the fact that it was boozer who reported a range of horrible events like cards dying constantly, cgminer eating the whole available memory space and bringing the system to a screeching halt...
Oh and yes, using the API calls to interact with cgminer would be by far preferable - I never suggested using messenger pigeons or necromancy in the overseer script. Cheesy

The rest - such as actually detecting the pool-related issues remains the same, doesn't it? At least until the PoolIsInTrouble API is added.

Quote from: DeathAndTaxes on March 24, 2012, 11:39:09 PM

API for the winz. So glad that thing exists. Boy it certainly was a smart idea for *someone* to start a bounty for that.

*stroking DAT's head* good Death, wise Death. We're certainly glad to have thee aboard Grin

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: de4l on March 25, 2012, 02:52:07 AM

do you need to delete bins when switching kernels in the config file?

No. Only if you are changing SDKs and want the newly installed SDK to build the kernel.

de4l

member

Activity: 82

Merit: 10

do you need to delete bins when switching kernels in the config file?

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: kano on March 24, 2012, 11:34:40 PM

You'd go to a lot of trouble to do that Tongue

You could just have a script that uses the API and enables/disables each of the 2 pools as required

API for the winz. So glad that thing exists. Boy it certainly was a smart idea for *someone* to start a bounty for that.

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

You'd go to a lot of trouble to do that Tongue

You could just have a script that uses the API and enables/disables each of the 2 pools as required

jake262144

full member

Activity: 210

Merit: 100

Quote from: boozer on March 24, 2012, 09:33:21 PM

... is there a way to tell cgminer to mine on the backup pool(s) for x amount of time or x amount of shares before switching back to the primary?

Unfortunately, no.
This behavior can be achieved by writing an overseer script for cgminer:
(1) cgminer is launched with just one pool defined (your primary pool).
(2) in case of connectivity issues¹ cgminer is killed off and restarted with a share limit² and another pool (or set of pools) configured.
(3) upon hitting the share limit cgminer shuts down and the overseer repeats step 1.

Notes:
1. detected by e.g. measuring the GPU temperature drop and low GPU load. A more sophisticated approach could include looking for certain key phrases in cgminer output to detect a range of pool issues where the pool is crippled but not down.
2. alternatively, the overseer could kill cgminer when a time limit expires.

boozer

sr. member

Activity: 309

Merit: 250

Quote from: -ck on March 24, 2012, 03:03:54 AM

Quote from: boozer on March 24, 2012, 01:06:51 AM

The only one that helped was setting GPU threads to 1.

Since I have done that, I have been stable for 8 hours with no restarts, so looks promising, but we'll see if it lasts... Undecided

Any disadvantage to only running 1 thread per gpu? Hash rates seem about the same.

That's interesting and unusual. I have certainly heard that particular driver and sdk combos would make 5970s unstable, but I don't know if that's true. If you're getting good hashrates it doesn't matter what settings you particularly chose now does it? I found 2 threads simply smoothed out the hashrate rather than improved it substantially, but some cards had slightly higher hashrates with 2 instead of 1.

Yes, it is weird... leave it to me to have a one-off, "out there", issue on my machines... but my 5970 rigs have been rock solid since i switched to 1 thread per gpu.... however my pools havent which leads me to a question...

I have backup pools defined, and cgminer switched as expected... and when the primary came up, it switched back as expected, thing is though... the primary was having intermittent issues, so cgminer was bouncing back and forth as it went up and down... is there a way to tell cgminer to mine on the backup pool(s) for x amount of time or x amount of shares before switching back to the primary?

sharky112065

sr. member

Activity: 383

Merit: 250

I'm re-posting this for people wanting to compile on Windows. Tends to get lost in all the posts. Hopefully ckolivas will one day put the link in the README included with cgminer.

Cgminer native Windows compile instructions:

http://pastebin.com/3pzivj32

If anyone finds something not working correctly, please msg me here and I will find a solution and update the pastebin as needed.

zefir

donator

Activity: 919

Merit: 1000

Quote from: -ck on March 24, 2012, 07:29:28 AM

Quote from: zefir on March 24, 2012, 07:09:58 AM

Using intensity of 13 for the 7970 and 9 for the 6950 the machine becomes very irresponsible (exported GPU_USE_SYNC_OBJECTS=1, CPU is used 50% by compiz/X and 50% by cgminer). Not sure if CPU is the bottleneck now or if there are better settings for this setup Undecided

Don't go over 11 for 7970 on linux with sync objects or 9 on windows.

Thanks, that helped to reduce MH fluctuation (flatting out near the values I had before with 13) and increase responsivity.

Ah, and FYI, removing all compiz related garbage also helped. I am using Gnome Classic without 3d effects, but with the latest driver compiz was eating all available CPU.

vapourminer

legendary

Activity: 4354

Merit: 3614

what is this "brake pedal" you speak of?

Quote from: stevegee58 on March 24, 2012, 06:11:44 AM

BTW how'd you get your 6770 cranked up to 1005? I'm currently running 960/300 and I've been unable to run higher reliably.

luck of the draw I guess. very good cooling in the HTPC case, probably 80% of the case air intake is right at the card (horizontal case). cgminer keeps it @ 70C max, 60% fan max.

although its @ 1000 now, it blew up while mining and watching a .MKV bluray rip a while back. generally runs 227 MH/s @ -I 7. gets 75 MH/s while watching movies @ 1080p at -I D though, heh.

use MSI Afterburner to set to 1000/300 on boot, then fire up cgminer.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: zefir on March 24, 2012, 07:09:58 AM

Using intensity of 13 for the 7970 and 9 for the 6950 the machine becomes very irresponsible (exported GPU_USE_SYNC_OBJECTS=1, CPU is used 50% by compiz/X and 50% by cgminer). Not sure if CPU is the bottleneck now or if there are better settings for this setup Undecided

Don't go over 11 for 7970 on linux with sync objects or 9 on windows.

zefir

donator

Activity: 919

Merit: 1000

Quote from: sveetsnelda on March 23, 2012, 08:46:47 PM

zefir,

Are you running a 32 or a 64 bit kernel?

Hi,

using 32bit kernel. Finally while trying every possible PCIe-slot / driver combination it works.

The XFX Black is getting hot already at stock clock (82°C@1GHz), cgminer is not even trying to OC, ending up at ~570 MH/s. The Gigabyte is being pushed to the max locked freq of 1.2GHz, pulling highly fluctuating 660-740 MH/s and staying at ~72°C.

I let my old 6950 in the rig for reference that pulls what it did before: 360 MH/s @ 890 MHz @ 75°C.

Using intensity of 13 for the 7970 and 9 for the 6950 the machine becomes very irresponsible (exported GPU_USE_SYNC_OBJECTS=1, CPU is used 50% by compiz/X and 50% by cgminer). Not sure if CPU is the bottleneck now or if there are better settings for this setup Undecided

stevegee58

legendary

Activity: 916

Merit: 1003

Yup. I'm currently running 2.3.1-2 on my 6770 (using diablo kernel) very happily and stably. I'll need a really good reason to upgrade again but I don't foresee ever needing to.

BTW how'd you get your 6770 cranked up to 1005? I'm currently running 960/300 and I've been unable to run higher reliably.

vapourminer

legendary

Activity: 4354

Merit: 3614

what is this "brake pedal" you speak of?

Quote from: -ck on March 23, 2012, 05:16:52 PM

Quote from: vapourminer on March 20, 2012, 06:47:05 PM

[2012-03-20 14:04:09] Failed to create submit_work_thread

Failing to create submit_work_thread is the key here. It has nothing to do with how it fails after that. Inability to create the thread suggests a system resource problem, like running out of memory or too many threads starting up for some reason.

been waiting to update this.

I updated cgminer on the 6770 and 6870 systems to 2.3.1-2 (was straight 2.3.1) and no problems since. the updated version may or may not have anything to do with it as I kinda glazed over the differences. need to pay more attention Grin

just seems odd that 2 completely different systems (with different windows OSs, sdks and driver versions) gave the exact same error multiple times in the same time frame. only thing the same was 2.3.1 cgminer.

wonder if it was a MS "patch tuesday" thing as I recall a pile of patches came down around that time.

anyway all is well now.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: boozer on March 24, 2012, 01:06:51 AM

The only one that helped was setting GPU threads to 1.

Since I have done that, I have been stable for 8 hours with no restarts, so looks promising, but we'll see if it lasts... Undecided

Any disadvantage to only running 1 thread per gpu? Hash rates seem about the same.

That's interesting and unusual. I have certainly heard that particular driver and sdk combos would make 5970s unstable, but I don't know if that's true. If you're getting good hashrates it doesn't matter what settings you particularly chose now does it? I found 2 threads simply smoothed out the hashrate rather than improved it substantially, but some cards had slightly higher hashrates with 2 instead of 1.

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