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

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Anyone get an issue where cgminer hangs w/ 100% CPU usage in linuxcoin?

I have cgminer set to startup automtically (auto.sh). ~95% of time after power cycling a rig it starts up just fine but sometimes the following happens ...

cgminer starts
it begins processing some shares
the "display" never appears

Instead of this

Code:

cgminer version 2.0.7 - Started: [2011-11-07 03:53:00]
-------------------------------------------------------------------------------
(5s):2271.6 (avg):2255.4 Mh/s | Q:70  A:102  R:0  HW:0  E:146%  U:29.60/m
TQ: 11  ST: 12  SS: 0  DW: 22  NB: 3  LW: 189  GF: 1  RF: 0
Connected to http://api2.bitcoin.cz:8332 with LP as user .....
Block: 000003786a1f68a61c89c31b2ce8f9bb...  Started: [03:55:49]
-------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
GPU 0: 48.5C | 376.8/381.0Mh/s | A:20 R:0 HW:0 U:5.80/m I:4
GPU 1: 49.5C | 386.1/386.4Mh/s | A:16 R:0 HW:0 U:4.64/m I:9
GPU 2: 48.5C  960RPM | 376.8/384.3Mh/s | A:17 R:0 HW:0 U:4.93/m I:9
GPU 3: 48.0C  960RPM | 379.3/383.5Mh/s | A:15 R:0 HW:0 U:4.35/m I:9
GPU 4: 374.5/379.6Mh/s | A:20 R:0 HW:0 U:5.80/m I:9
GPU 5: 49.0C | 376.2/377.8Mh/s | A:15 R:0 HW:0 U:4.35/m I:9

I get something like this ...

Code:

GPU 0: 48.5C | 376.8/381.0Mh/s | A:20 R:0 HW:0 U:5.80/m I:4
[2011-11-07 03:56:39] Accepted 00000000.e18ff5e4.7bf0da85 GPU 1 thread 7 pool 0
GPU 3: 48.0C  960RPM | 379.3/383.5Mh/s | A:15 R:0 HW:0 U:4.35/m I:9
[2011-11-07 03:56:42] Accepted 00000000.f2bb9183.2f81f5c6 GPU 1 thread 1 pool 0
GPU 1: 49.5C | 386.1/386.4Mh/s | A:16 R:0 HW:0 U:4.64/m I:9
[2011-11-07 03:56:42] Accepted 00000000.d0d064f8.b2a7d847 GPU 1 thread 7 pool 0
[2011-11-07 03:56:43] Accepted 00000000.5b0a721c.7479a52d GPU 0 thread 0 pool 0
GPU 4: 374.5/379.6Mh/s | A:20 R:0 HW:0 U:5.80/m I:9
GPU 2: 48.5C  960RPM | 376.8/384.3Mh/s | A:17 R:0 HW:0 U:4.93/m I:9
GPU 5: 49.0C | 376.2/377.8Mh/s | A:15 R:0 HW:0 U:4.35/m I:9
GPU 2: 48.5C  960RPM | 376.8/384.3Mh/s | A:17 R:0 HW:0 U:4.93/m I:9
GPU 2: 48.5C  960RPM | 376.8/384.3Mh/s | A:17 R:0 HW:0 U:4.93/m I:9

Almost like it isn't updating the "display area" and insteading dumping everything to the command line. This only seems to happen on "startup" and only rarely. The bad news is it seems to eventually take 100% of CPU and then hard lock all the GPU. When I detect it (which is easy because it only happens when cgminer startsup) I simply reboot the rig and the issue goes away.

It is just kinda annoying. Just wonder if anyone has seem anything like this or any ideas on prventing it.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

The work item stores a reference to which pool it came from and that reference is never changed. If the pool itself is having communication trouble of some sort, it's entirely possible that the pool doesn't recognise its own work afterwards? Unless there's a bug I haven't tracked down, cgminer never changes reference to where the work came from. Now if you're piping it through some other proxy of some sort or hopper or something, then perhaps they mess with the headers as they come through.

static bool submit_upstream_work(const struct work *work)
struct pool *pool = work->pool;
val = json_rpc_call(curl, pool->rpc_url, pool->rpc_userpass, s, false, false, &rolltime, pool);

So it sends the work upstream each time with the pool information directly stored in the work structure. As I said, there may be a bug I haven't tracked down, but that field is never changed once the work is grabbed.

P4man

hero member

Activity: 518

Merit: 500

Minor bug report; as DrHaribo already explained in a PM I believe, Id like to confirm the issue is real.

When using failover, cgminer 2.0.7 is sending withheld shares to the wrong pool, obviously resulting in stales.

I saw this first hand when bitminter pool was having trouble this morning. I didnt log it, but by memory, cgminer first displayed that bitminter was slow to respond, and was witholding results. A few seconds later, it decided that bitminter pool was unreachable, and switched to slush's pool. Then it resubmitted the withheld shares, which were obviously rejected. Ive seen it happen a few times. IIRC it also happened in the other direction, when bitminter went live again, it sent shares which should have been sent to slush.

Is it necessary or useful to enable logging and try to force the issue by blocking bitminter on my firewall?

update: I just tried on my windows machine, with just one gpu, and cgminer's failover seems to work fine. Possibly this is only an issue on linux or with 2+ gpus? Ill test some more and report back.

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: btcex on November 04, 2011, 05:42:01 AM

Just change from GUIMiner to CGMINER on Windows 7 x64 with two 6990 - just awesome, great work!

Once you switch you won't ever consider another miner. Throw some donations towards the author if you found it useful. If you don't have the coins then you can enable donations and send 1% of your hashing power to him.

btcex

newbie

Activity: 28

Merit: 0

Just change from GUIMiner to CGMINER on Windows 7 x64 with two 6990 - just awesome, great work!

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: Ghostofkobra on November 04, 2011, 03:27:07 AM

Quote from: The00Dustin on November 02, 2011, 02:58:22 PM

Quote from: kano on November 02, 2011, 02:54:21 PM

Actually, on linux, it's better to use:

now="`date +%Y%m%d%H%M%S`"

so now looks like: 20111101121520
and them something like:

./cgminer ....... 2> run.$now.$$.log

That way the name sorts in time order and '$$' adds the process number in case there are accidentally 2 running at the same time

Very nice, you wouldn't believe how hard it is to get people to understand why that date (and date-time in this case) structure is the logical way to go, or maybe you've been there, done that.

I prefer the more compact version but the result is the same.

./cgminer .... 2> run-`date +%y:%T`.log

creates the file "run-02:02:01:56.log"

Best
//GoK

I think the time must be wrong on your computer ...
%y is the 2 digit year - and 02 is definitely not this year

Did you want %F maybe?

Just putting the year there wouldn't help with sorting.
As The00Dustin said, my choice is so the files automatically sort in date/time order.

Ghostofkobra

full member

Activity: 164

Merit: 100

Quote from: The00Dustin on November 02, 2011, 02:58:22 PM

Quote from: kano on November 02, 2011, 02:54:21 PM

Actually, on linux, it's better to use:

now="`date +%Y%m%d%H%M%S`"

so now looks like: 20111101121520
and them something like:

./cgminer ....... 2> run.$now.$$.log

That way the name sorts in time order and '$$' adds the process number in case there are accidentally 2 running at the same time

Very nice, you wouldn't believe how hard it is to get people to understand why that date (and date-time in this case) structure is the logical way to go, or maybe you've been there, done that.

I prefer the more compact version but the result is the same.

./cgminer .... 2> run-`date +%y:%T`.log

creates the file "run-02:02:01:56.log"

Best
//GoK

GlenBot

newbie

Activity: 46

Merit: 0

I'm running cgminer on a win7 32-bit box. With 11.9 I was getting 292Mh/s avg with 1 sapphire 5830. Upgraded to 11.10 and saw hashrate problems (60-70Mh/s avg). Rather than mess around trying to figure it out, I did a System Restore back to before the 11.10 upgrade. Worked like a charm; system rebooted with 11.9 drivers and 292Mh/s avg. I'm leaving it alone for now.

sgravina

sr. member

Activity: 451

Merit: 250

Quote from: dishwara on November 02, 2011, 10:59:37 AM

Any one tried 11.10 which is released on 31st oct?
I am not mining now, so cant test how 11.10 behaves with cpu usage.

I update a machine to Ubuntu 11.10. It comes with fglrx 11.9 which has the 100% cpu bug. I was unable to downgrade it to fglrx 11.6 which doesn't have the bug. So I reloaded Ubuntu 11.04 which comes with fglrx 11.5, I upgraded fglrx to 11.6. Now it works again without the 100% bug.

I also mine litecoins so the 100% bug is unacceptable. litecoin mining won't work with the 100% bug.

I spent way too much time on this experiment. I'm waiting till someone else succeeds before I upgrade anything.

Sam

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: bronan on November 03, 2011, 02:38:43 AM

Thats where dummy plugs come in handy, no need for extend desktop and no effect on it also

There hasn't been a need for dummy plugs in a long time.

ocminer

legendary

Activity: 2688

Merit: 1240

sure youre right 11.10 :-)

bronan

hero member

Activity: 774

Merit: 500

Lazy Lurker Reads Alot

Quote from: ocminer on November 02, 2011, 04:53:39 PM

10.10 has the same 100% CPU bug...

Under Linux x86_64 at least..

lol you mean 11.10 i hope since 10.10 does not have the cpu bug Cheesy

11.9 1 gpu used no cpu bug
11.9 2 gpu 100% cpu usage
11.10 2 gpu 100% cpu usage

So again nothing changed

bronan

hero member

Activity: 774

Merit: 500

Lazy Lurker Reads Alot

Quote from: os2sam on November 01, 2011, 09:16:14 AM

Quote from: DeathAndTaxes on November 01, 2011, 09:02:38 AM

If you have more than one GPU and all your monitors hooked up to a single GPU you can set the "monitor" GPU to dynamic and all other cards to a high I value. For example my 3x5970 workstation has 1 GPU set to D and the other 5 set to I=9. If you have multiple monitors hook them all up to the same GPU to minimze the number of GPU which need to be set to dynamic.

That doesn't hold true for Windoze does it? Since I have to extend the desktop to the GPU without the monitor to enable it. Whatever I do to that GPU seems to have an effect on the desktop GUI as well.
Sam

Thats where dummy plugs come in handy, no need for extend desktop and no effect on it also
I have no clue why people do not want to use this simple solution.
Even on the normal connected ones i have one since i switch cable often to fix other pc's
Anyway for me hurrah for the dummyplug

As for the I setting i found the best to be I=7 it works great and no stalls even with high overclocks
With 8 i found more stalls where present which overall gave lower results anything higher makes it all worse
(4770,5870 and 5970 gpu's)

ancow

full member

Activity: 373

Merit: 100

Quote from: os2sam on November 02, 2011, 11:03:52 PM

Quote from: ancow on November 02, 2011, 12:05:50 AM

Quote from: os2sam on November 01, 2011, 09:28:07 AM

Hmm, I'm using Catalyst 11.6 and tried it with that version and also 11.7 and neither could do it, plus the 11.7 has the high CPU utilization issue.

If you get a chance take a peek at which version Catalyst your using drop me a note and I'll give it a whirl.

Last time I tried 11.9, it didn't have the 100% CPU utilisation bug either in windows or Linux. In Linux, however, my KDE desktop became a little too crashy for my tastes and the hashing speed went down slightly. I didn't have either problem in windows, but then I don't run it much.
I don't know about the dummy plugs/desktop extending issue, but it might be worth a try.

Sounds like it ought to be worth a try. I'll dig out my Win7 hard drive and give it a try soon. I only have one mining rig so I don't like to take it down too long.

Apparently it only works well with a one-GPU-setup, so it won't be very useful for your multi-GPU one... Undecided

os2sam

legendary

Activity: 3583

Merit: 1094

Think for yourself

Quote from: ancow on November 02, 2011, 12:05:50 AM

Quote from: os2sam on November 01, 2011, 09:28:07 AM

Hmm, I'm using Catalyst 11.6 and tried it with that version and also 11.7 and neither could do it, plus the 11.7 has the high CPU utilization issue.

If you get a chance take a peek at which version Catalyst your using drop me a note and I'll give it a whirl.

Last time I tried 11.9, it didn't have the 100% CPU utilisation bug either in windows or Linux. In Linux, however, my KDE desktop became a little too crashy for my tastes and the hashing speed went down slightly. I didn't have either problem in windows, but then I don't run it much.
I don't know about the dummy plugs/desktop extending issue, but it might be worth a try.

Sounds like it ought to be worth a try. I'll dig out my Win7 hard drive and give it a try soon. I only have one mining rig so I don't like to take it down too long.
Thanks,
Sam

ocminer

legendary

Activity: 2688

Merit: 1240

10.10 has the same 100% CPU bug...

Under Linux x86_64 at least..

The00Dustin

hero member

Activity: 807

Merit: 500

Quote from: kano on November 02, 2011, 02:54:21 PM

Actually, on linux, it's better to use:

now="`date +%Y%m%d%H%M%S`"

so now looks like: 20111101121520
and them something like:

./cgminer ....... 2> run.$now.$$.log

That way the name sorts in time order and '$$' adds the process number in case there are accidentally 2 running at the same time

Very nice, you wouldn't believe how hard it is to get people to understand why that date (and date-time in this case) structure is the logical way to go, or maybe you've been there, done that.

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Actually, on linux, it's better to use:

now="`date +%Y%m%d%H%M%S`"

so now looks like: 20111101121520
and them something like:

./cgminer ....... 2> run.$now.$$.log

That way the name sorts in time order and '$$' adds the process number in case there are accidentally 2 running at the same time

Muppion

newbie

Activity: 12

Merit: 0

Quote from: gnar1ta$ on November 02, 2011, 10:39:39 AM

I have a simple startup script to launch cgminer on restart (Ubuntu) and have 2>cglog.txt to generate a log. Of course it overwrites on every restart, which isn't exactly useful. Is there a way to make it change the name of the log on every restart so it doesn't overwrite?

you can add the following lines before the start of cgminer to give the log file an unique name:

DAY=`date '+%F_%T'`
LOG=cglog-${DAY}.log

--------------------

You can then use the variable $LOG as the unique log file name for this run of the miner as in .... 2>$LOG

The different log files are named as date with time at the start of the name (as in cglog-2011-11-02_19:15:01.log).

(See date --help for more formats to use if needed)

/Muppion

Jay_Pal

legendary

Activity: 1493

Merit: 1003

Quote from: dishwara on November 02, 2011, 10:59:37 AM

Any one tried 11.10 which is released on 31st oct?
I am not mining now, so cant test how 11.10 behaves with cpu usage.

I'm on 10.10 x64 on AMD Athlon II X3, with a 5550HD on Catalist 11.9 and it's the same performance as 11.04 with 11.7.

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