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

[jake262144]

You'd go to a lot of trouble to do that
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. 
The rest - such as actually detecting the pool-related issues remains the same, doesn't it? At least until the PoolIsInTrouble API is added.

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

[1714045775]

1714045775

[1714045775]

1714045775

[kano]

You'd go to a lot of trouble to do that
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.  
The rest - such as actually detecting the pool-related issues remains the same, doesn't it? At least until the PoolIsInTrouble API is added.

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

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

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

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

[kano]

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

[vapourminer]

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.

[P_Shep]

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?

[ummas]

I had the problem witch boozer has.
GPU0 crasches and i get 50/50% of usage by Xorg/cgminer or any other combination with xorg.
only reboot helps.

configuration: 5870 VaporX+2x5970 with acceleroX, Xubuntu 11.04, CAT 12.2(SDK 2.6), cgminer 2.3.1, kernel diablonow i`m testing phatk).
For last lew days, i was using 2.0.6 with cheat(few pages ago), but my hdd was dying, it was matter of time....
All new install. 2.0.6 wont work
2.3.1 crasches my GPO0 :/

EDIT:
phatk and diablo do this same...after prox 20 minutes, crash of xorg.
now i`m trying: -g 1
5870 works on 940/150, where i know i can pull 970 .... max temp 62 *C
system was totally 13minutes uptime, and xorg failed :/

Edit#2
Now i think it`s just broken xorg. I was ipgrading al, and xorg dieded. I`ll end it tomorow - i hope.

Edit#3
rule No.69 - always tourn off your screen sever.

[kano]

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?

It's more of a miner hardware status and 'debug' style info - so better to show it all on some extended status or 'debug' style page.

Basically, you already have Alive, Sick, Dead, NoStart, Disabled.

When things are Sick or Dead, then on that rare occasion someone may want to see some info about what's going on.
If it's one device, that's fine, but if it's more than one ... having to go to N different device pages would be a PITA in my opinion - but that's just my opinion

I'm thinking more along the lines of: there is something wrong and this overview of where things are going wrong is the best use of it
i.e. "I see a problem", is it only one card, or multiple cards or even 2 GPU's on the same card or 2 GPU's on different cards - so an across the board rundown of the status of everything is way more useful as that is the point of what boozer was looking at and since he gave me some BTC for helping I thought best to also write the code to help some more - i.e. an overview of what's going wrong: where it's happening and why

[ShadesOfMarble]

How can I set the getwork delay (if such a setting exists)?

[kano]

How can I set the getwork delay (if such a setting exists)?

You can't - you can set the Queue size with -Q though ...
The code decides what its best
(which of course makes perfect since)

If you are talking Icarus - then set it to at least 4
Otherwise ... what for?

[ShadesOfMarble]

I was asked to set it to 10 seconds (because of a high stale rate).

[kano]

I was asked to set it to 10 seconds (because of a high stale rate).

If you mean P2Pool, then that's not the getwork delay.

I they did mean P2Pool then that would probably be some noob who didn't read the README that tells you what to do on P2Pool.
Of course, yes read the README if you are referring to P2Pool

README:
Q: How do I tune for p2pool?
A: p2pool has very rapid expiration of work and new blocks, it is suggested you decrease intensity by 1 from your optimal value, and decrease GPU threads to 1 with -g 1.

If on the other hand it has nothing to do with P2Pool, then ask whoever told you what on earth they mean

[P_Shep]

It's more of a miner hardware status and 'debug' style info - so better to show it all on some extended status or 'debug' style page.

Basically, you already have Alive, Sick, Dead, NoStart, Disabled.

When things are Sick or Dead, then on that rare occasion someone may want to see some info about what's going on.
If it's one device, that's fine, but if it's more than one ... having to go to N different device pages would be a PITA in my opinion - but that's just my opinion

I'm thinking more along the lines of: there is something wrong and this overview of where things are going wrong is the best use of it
i.e. "I see a problem", is it only one card, or multiple cards or even 2 GPU's on the same card or 2 GPU's on different cards - so an across the board rundown of the status of everything is way more useful as that is the point of what boozer was looking at and since he gave me some BTC for helping I thought best to also write the code to help some more - i.e. an overview of what's going wrong: where it's happening and why

OK, that makes sense. My other thought was to add a new page to display this.

[-ck]

I'm back online. So time to start rounding up a few pending patches and bring out a new version in the next few days.

Interestingly, I finally got to try the official 12.2 driver for linux with my 7970 and it actually makes my GPU go sick and then dead at clocks that were fine with that early GCN only driver release amd-driver-installer-8.921-x86.x86_64.run . Downgrading to that fixed the problem. Worth considering a different driver version if you're having apparent hardware instability it seems.

[ShadesOfMarble]

On Windows, can I use a driver version which does NOT officialy support the 7970 as long as the newest SDK is installed?

[-ck]

On Windows, can I use a driver version which does NOT officialy support the 7970 as long as the newest SDK is installed?

no

[manifold]

Hi, I just wanted to report that with the latest git My Hashrate drops from 190 MH/s to 170 MH/s. When I check the git repository out from the date 3/3/2012 then I get again  190MH/s.
I use the default kernel and I use ubuntu 11.10 with a HD5770.  What changes made the hashrate drop so drastically?

[-ck]

Hi, I just wanted to report that with the latest git My Hashrate drops from 190 MH/s to 170 MH/s. When I check the git repository out from the date 3/3/2012 then I get again  190MH/s.
I use the default kernel and I use ubuntu 11.10 with a HD5770.  What changes made the hashrate drop so drastically?

I'm experimenting. It looks like you are on SDK 2.6. Try -k diablo and see what that does to your hashrate.

And then try -k poclbm.

[manifold]

yes...  know, but I prefer the default kernel (is it diabolo?) since I tested all of them a while ago and diabolo was the fastest. Therefore I prefer to work with the older git version...   but why did the hashrate drop?

[-ck]

yes...  know, but I prefer the default kernel (is it diabolo?) since I tested all of them a while ago and diabolo was the fastest. Therefore I prefer to work with the older git version...   but why did the hashrate drop?

The kernels have radically changed and I need to choose the right ones. I'm asking you because I need your feedback, i'm not telling you a workaround. You are running very experimental code by trying the git tree.