Author

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

hero member
Activity: 591
Merit: 500
i.e. you have two conf files:
 ~/Dropbox/cgminer/cgminer.conf
and
 ~/.cgminer/cgminer.conf
so you have to consider the affect of both of them
... was the point of my question Smiley
I wrote the .conf from cgminer and then moved it out of the default folder into my Dropbox folder. There's nothing in ~/.cgminer anymore.

Are you sure your first core is the one running your desktop?

Try switching the intensity values around.   9,d
I'm positive I have the right ones. My desktop would hardly function if my display GPU was on 9. Tongue
hero member
Activity: 658
Merit: 500
Are you sure your first core is the one running your desktop?

Try switching the intensity values around.   9,d
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
i.e. you have two conf files:
 ~/Dropbox/cgminer/cgminer.conf
and
 ~/.cgminer/cgminer.conf
so you have to consider the affect of both of them
... was the point of my question Smiley
hero member
Activity: 591
Merit: 500
Code:
{
"pools" : [
(pool info here)
],

"intensity" : "d,9",
"vectors" : "2,2",
"worksize" : "128,128",
"kernel" : "phatk,phatk",
"gpu-engine" : "700-960,700-960",
"gpu-fan" : "0-85,0-85",
"gpu-memclock" : "0,0",
"gpu-memdiff" : "0,0",
"gpu-powertune" : "0,0",
"gpu-vddc" : "0.000,0.000",
"temp-cutoff" : "95,95",
"temp-overheat" : "85,85",
"temp-target" : "75,75",
"api-port" : "4028",
"auto-fan" : true,
"auto-gpu" : true,
"expiry" : "120",
"gpu-dyninterval" : "7",
"gpu-platform" : "0",
"gpu-threads" : "1",
"log" : "5",
"queue" : "1",
"retry-pause" : "5",
"scan-time" : "60",
"temp-hysteresis" : "3",
"shares" : "0",
"kernel-path" : "/usr/local/bin"
}

Pretty much just stuff that got written to the file when I made it through cgminer's menu.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
what is in ~/.cgminer/cgminer.conf ...
hero member
Activity: 591
Merit: 500
So after updating to 2.4.2, I decided to try switching to 2 threads per GPU again. The problem is still there; my display GPU starts to function really slowly, both mining and drawing my desktop. It's on dynamic intensity which means it's still only running on 1 thread, right? Why would enabling 2 threads affect it at all?

I have my .sh script set to run the export commands:

Code:
#!/bin/sh

export GPU_USE_SYNC_OBJECTS=1
export DISPLAY=:0
~/Dropbox/cgminer/cgminer -c ~/Dropbox/cgminer/cgminer.conf

Is that maybe my problem? Not sure what could possibly be causing this.
legendary
Activity: 2702
Merit: 1468
Making a windows based GUI front end to monitor (and control) my miners is on my list of things to do.  That would help the windows guys (yes, we still exist, and aren't likely going anywhere anytime soon).

M

Many web stats display/monitors are available.  Nice charts and all.  So I'd not waste time on this.
My take on this is that charts are nice to look at but they don't make money. Your miner does.

If you interested in something that would actively control your miner process, you might take a look at my akbash.
It can be set to monitor many miner, Windows and GPU hardware statistics.  When triggers (hash rates, hw errors, process handle count or working set, GPU H/W temp, utilization, faulty fans etc) are met, miner (or OS) is restarted, email notifications are sent.  Most importantly, driver crashes and werfault conditions are detected.

yxt
legendary
Activity: 3528
Merit: 1116
hero member
Activity: 518
Merit: 500
Quite frankly, antivirus blacklists/scanners seem to be turning into more of a problem than the virii/trojans themselves. But maybe I'm biased because I've never been infected (even when I ran Windows; and no, I've never used antivirus)

Same here. Ran Windows 2000 SP4 with updates turned off and if you have a brain you never have any problems. If you don't and have the best antivirus you still can get raped.
legendary
Activity: 2576
Merit: 1186
Quite frankly, antivirus blacklists/scanners seem to be turning into more of a problem than the virii/trojans themselves. But maybe I'm biased because I've never been infected (even when I ran Windows; and no, I've never used antivirus)
full member
Activity: 238
Merit: 100
Problem with aVast, even though I still prefer it, is the same thing that's wrong with all the other AV vendors, they toss the kitchen sink into it. By that I mean somebody like PCMag will do a review with a nice table saying what each AV product does with nice little check marks then management sees these charts and comes back at the Devs and says "why isn't our product also scanning for XYZ"? With each new tool added into the product it gets slower, more intrusive and overall less popular, look at McAfee, the number one product for years yet like Norton most educated users stay far away from both now.

With aVast I love how it scans webpages for rogue code so much better than others but it's becoming a challenge to stick with them. I am still on version 4.8 as it's lighter than the new releases PLUS allows for URL blocking which is great for those ad banners. I'm a bit ticked at it blocking downloading of CGMiner yet it's log does not show any event concerning that block. Having to disable scanning just to download is a total fail on their part.

ok sorry for the thread steal, back to CGMiner.
hero member
Activity: 658
Merit: 500
they have probably found code and traced web connections from trojans that are using cgminer and your pools and are flagging anything that appears to match.
legendary
Activity: 1260
Merit: 1000
Heh.. avast seems to be going apeshit with Bitcoin related stuff lately.  They flagged OzCoin and apparently my pool as well (though I think it's since been corrected) ... WTH is up over there at Avast, are they just stupid?
sr. member
Activity: 266
Merit: 250
The king and the pawn go in the same box @ endgame
Boy aVast sure doesn't like this update. Have not had it complain about my current version but it doesn't even want me to download this one saying it's Malware. Reported as False like that will make a difference.

Same here. I reported as a false positive, and I am trying to get it on my excluded list, when I can can figure out where its at!
full member
Activity: 238
Merit: 100
Boy aVast sure doesn't like this update. Have not had it complain about my current version but it doesn't even want me to download this one saying it's Malware. Reported as False like that will make a difference.
full member
Activity: 196
Merit: 100
Web Dev, Db Admin, Computer Technician
Just installed 2.4.2 and received a strange message:

Code:
No login credentials for pool 0 http://p2pool:9332 -u bitcoinaddress -u <-imadummy

Edit: My mistake, I typoed the script to run.  Embarrassed
hero member
Activity: 518
Merit: 500
As each pool has a different idea about when the block changes, if I choose the first pool's block change to discard all work from all pools then there can be quite a long period across block changes where cgminer throws out lots of work because it will continue to consider it from the old block. I had to relax the stale testing for load balance to prevent this work from being thrown out. On the other hand it's almost certainly what's leading to higher stales at every longpoll/block change. People generally get scared when they see a huge dip in hashrate across longpoll and start blaming cgminer for not keeping the devices busy. It probably makes more sense to throw out the work and accept the dip in hashrate so I can do that next version, but no matter what I choose, someone will complain  Roll Eyes

I was wondering if something like this was the case. Looking at the log that seemed to me what was happening, but I was having difficulty translating what was going on... (for one, the specific pool/device the message is about is rarely referenced in the logs!).

If there's not much you can do, there's not much you can do! I'll just stick to fail-over then Smiley

I'd say taking the dip in hashrate would be better option though. I prefer not to start work than throw away work done...
1. You won't waste power calculated hashes you know will be stale.
2. You don't get stales appearing in the stats.

Absolute genius !

And now each 10 minutes / new block found my GPUs will go to no load / very low temps and then to high load / very high temps in a timeframe of 1 minute.

This hot -> cold -> hot cycle is not good for the fans or for the GPU itself. Same with FPGAs if you have that junk.

Brilliant, I tell you !

sr. member
Activity: 266
Merit: 250
The king and the pawn go in the same box @ endgame
I cannot seem to get (--real-quiet) to run. Is there a way to make it run from the config file?

Kindest Regards
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
As each pool has a different idea about when the block changes, if I choose the first pool's block change to discard all work from all pools then there can be quite a long period across block changes where cgminer throws out lots of work because it will continue to consider it from the old block. I had to relax the stale testing for load balance to prevent this work from being thrown out. On the other hand it's almost certainly what's leading to higher stales at every longpoll/block change. People generally get scared when they see a huge dip in hashrate across longpoll and start blaming cgminer for not keeping the devices busy. It probably makes more sense to throw out the work and accept the dip in hashrate so I can do that next version, but no matter what I choose, someone will complain  Roll Eyes
you don't want to break p2pool + other pool combinations because p2pool is unique in how it does most things
This really doesn't have much to do with p2pool as p2pool is impossible to use as anything other than the primary pool, or a backup pool in pure failover-only mode. Using p2pool in load balance with it as anything other than the primary would be a mess for shares going to p2pool.
hero member
Activity: 658
Merit: 500
I think I might have found what's been causing my high stales, though not specifically...
It seems with load-balance I get very a poor stale rate, which seems to get worse the more pools involved. with 3 pools I get around 1.5% stale, with 5 it's up to 3-4%. When it's fail-over-only I'm looking at < 0.5%
Trouble is, the CGminer reported stats are not the same as the pools report. it seems the pools (some more than others) often report a share as valid to cgminer, then decide in it's own stats that it's stale.

I have a 10Mb debug log file taken over 1.5hrs if it'll be useful to diagnose anything.  
As each pool has a different idea about when the block changes, if I choose the first pool's block change to discard all work from all pools then there can be quite a long period across block changes where cgminer throws out lots of work because it will continue to consider it from the old block. I had to relax the stale testing for load balance to prevent this work from being thrown out. On the other hand it's almost certainly what's leading to higher stales at every longpoll/block change. People generally get scared when they see a huge dip in hashrate across longpoll and start blaming cgminer for not keeping the devices busy. It probably makes more sense to throw out the work and accept the dip in hashrate so I can do that next version, but no matter what I choose, someone will complain  Roll Eyes
you don't want to break p2pool + other pool combinations because p2pool is unique in how it does most things
Jump to: