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

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: ShadesOfMarble on March 26, 2012, 05:37:33 AM

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

ShadesOfMarble

donator

Activity: 543

Merit: 500

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

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: ShadesOfMarble on March 26, 2012, 04:07:41 AM

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

donator

Activity: 543

Merit: 500

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

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: P_Shep on March 25, 2012, 11:52:34 AM

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?

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

ummas

sr. member

Activity: 274

Merit: 250

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.

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: 1080

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.

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