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

ancow

full member

Activity: 373

Merit: 100

Quote from: -ck on January 04, 2012, 01:00:10 AM

I'm thinking this may all be related to my donation pool being flaky lately with the move and nothing to do with the new version.

In support of that theory: I only had one instance of the connection bug so far, and that was when I turned on donations and happened more or less simultaneously for two instances of cgminer. I turned donations off again and have been sailing smoothly since New Year's Eve (which is when the bug occurred for me).
Anyway, I'm back to donating manually.

ovidiusoft

sr. member

Activity: 252

Merit: 250

Quote from: -ck on January 04, 2012, 07:11:49 AM

Quote from: ocminer on January 04, 2012, 04:44:24 AM

Hardware Errors=0 even though one card is "DEAD" ?

Hardware errors are very different to a card becoming unresponsive under load. Usually hardware errors occur if someone has unlocked the shaders in a card that has faulty shaders, or they are overclocking beyond reliable levels but below crash levels. Hitting hardware errors without a hardware hang/dead card is actually quite rare.

Mmmm... no, not really:

RAM: 325
CPU: 1040
Mhash/s: 337,2
Accepted: 289690
Accept/min: 4,51
Hardware: 523
Hardware %: 0,18

As you can see, a uptime of 1,5 months (since I restarted cgminer). The card never haged or went dead.

DBordello

sr. member

Activity: 349

Merit: 250

BTCPak.com - Exchange your Bitcoins for MP!

Quote from: -ck on January 04, 2012, 07:11:49 AM

Quote from: ocminer on January 04, 2012, 04:44:24 AM

Hardware Errors=0 even though one card is "DEAD" ?

Hardware errors are very different to a card becoming unresponsive under load. Usually hardware errors occur if someone has unlocked the shaders in a card that has faulty shaders, or they are overclocking beyond reliable levels but below crash levels. Hitting hardware errors without a hardware hang/dead card is actually quite rare.

I actually had a 5830 @ 1030MHz that would spew about 7 HW errors a day, but was otherwise stable. I figured I had it OCd right to the edge.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: ocminer on January 04, 2012, 04:44:24 AM

Hardware Errors=0 even though one card is "DEAD" ?

Hardware errors are very different to a card becoming unresponsive under load. Usually hardware errors occur if someone has unlocked the shaders in a card that has faulty shaders, or they are overclocking beyond reliable levels but below crash levels. Hitting hardware errors without a hardware hang/dead card is actually quite rare.

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

The GPU replies with it's status.
If you request "devs" you will get all GPUs and CPUs ( or {"command":"devs"} )

Each GPU will have a field called 'Status' that says one of:
"Alive", "Dead", "Sick" or "NoStart"

Or you can request each GPU individually e.g. "gpu|0" etc ( or {"command":"gpu","parameter":"0"} )
and again it will be the same as above but with just the single GPU info.

Edit: as you can see in your screen dump, the total HW value is indeed zero.

ocminer

legendary

Activity: 2688

Merit: 1240

Hardware Errors=0 even though one card is "DEAD" ?

I have:

[P]ool management [G]PU management ettings [D]isplay options [Q]uit
GPU 0: 41.0C 1041RPM | DEAD /262.5Mh/s | A:2294 R:10 HW:0 U:3.59/m I: 8
GPU 1: 75.0C 1067RPM | 386.4/386.3Mh/s | A:3427 R:21 HW:0 U:5.36/m I: 8
GPU 2: 58.0C 0% | 215.4/215.9Mh/s | A:1873 R: 9 HW:0 U:2.93/m I: 8

But a "summary" gives me:

Array
(
[STATUS] => Array
(
[STATUS] => S

Code:

 => 11
            [Msg] => Summary
            [Description] => cgminer 2.1.1
        )

    [SUMMARY] => Array
        (
            [0] => SUMMARY
            [Elapsed] => 38299
            [Algorithm] => c
            [MHS av] => 865.15
            [Found Blocks] => 0
            [Getworks] => 5520
            [Accepted] => 7590
            [Rejected] => 40
            [Hardware Errors] => 0
            [Utility] => 11.89
            [Discarded] => 433
            [Stale] => 0
            [Get Failures] => 3
            [Local Work] => 15829
            [Remote Failures] => 0
            [Network Blocks] => 76
        )

)


I was trying to check if a card is dead/sick/whatever over "Hardware Errors" as this seems to be the most logic parameter for me.

Is that not possible ?

P4man

hero member

Activity: 518

Merit: 500

[quote author=ckolivas link=topic=28402.msg673233#msg673233
There was a bug that would cause higher rejects with multipool setups that was fixed in 2.1.0. We're only turning LP off at the moment to debug a network connectivity issue.
[/quote]

The network bug has been there for me since 2.0.8 at least, possibly longer. Its not new in 2.1.0

bitlane

sr. member

Activity: 462

Merit: 250

I heart thebaron

Quote from: BkkCoins on January 03, 2012, 11:59:23 PM

When I switched to cgminer a couple months back I noticed that I always had a much higher reject rate. I get typically 3-7% rejects regardless of pool, Ars, Eligius, BTCGuild and others. Not sure what causes this and haven't tried to debug yet. I just let it be because I like the interface and monitoring in cgminer but it would be nice to track this down and see why the rejects are high. Before, same HW/OS setup, I used to get more like 0.7%.

I would say there is definitely something wrong with your setup, especially if you consider 0.7% a good rate.

The only reason I am responding, is I notice that you mention BTCGuild as being problematic for you and that happens to be my primary pool, so I am quite familiar with the performance there, as I also use it as a benchmark against other pools when I am bored and changing things up - yet always return to BTCGuild.

On BTCGuild, using my WORST MINER as an example....
After nearly a Million shares submitted since I last reset it's stats, my VALID % is 99.83, leaving 0.17% to Stales/Dupes/Invalids.
(Total Shares Submitted: 837520 ..... Valid = 836092 Shares ..... Stales/Dupes/Invalids etc = 1428 shares)

This is my current 'Bastard Miner'.....a mixed-card machine (5770, 5830, 6870) and to be honest, I do most of my 'testing' using this rig, hence it's higher rejected rate (for me anyway)....not to mention, the software environment (not including CGMiner) is far from being optimal.

I have also been using CGMiner since version 1.6.0 and every release tends to get better for me, so I would definitely have a look at your setup, both software and hardware, not simply pointing a finger at CGMiner.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: ?? on ??

Quote from: -ck on January 04, 2012, 12:46:41 AM

Try turning donation off

Ok will try that and with LP on to make the test equal.

Thanks.

I'm thinking this may all be related to my donation pool being flaky lately with the move and nothing to do with the new version.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Try turning donation off

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: BkkCoins on January 03, 2012, 11:59:23 PM

When I switched to cgminer a couple months back I noticed that I always had a much higher reject rate. I get typically 3-7% rejects regardless of pool, Ars, Eligius, BTCGuild and others. Not sure what causes this and haven't tried to debug yet. I just let it be because I like the interface and monitoring in cgminer but it would be nice to track this down and see why the rejects are high. Before, same HW/OS setup, I used to get more like 0.7%.

Should I turn LP off? I thought that was to help reduce rejects.

There was a bug that would cause higher rejects with multipool setups that was fixed in 2.1.0. We're only turning LP off at the moment to debug a network connectivity issue.

BkkCoins

hero member

Activity: 784

Merit: 1009

firstbits:1MinerQ

When I switched to cgminer a couple months back I noticed that I always had a much higher reject rate. I get typically 3-7% rejects regardless of pool, Ars, Eligius, BTCGuild and others. Not sure what causes this and haven't tried to debug yet. I just let it be because I like the interface and monitoring in cgminer but it would be nice to track this down and see why the rejects are high. Before, same HW/OS setup, I used to get more like 0.7%.

Should I turn LP off? I thought that was to help reduce rejects.

Proofer

member

Activity: 266

Merit: 36

Quote from: -ck on January 03, 2012, 09:35:26 PM

Quote from: Proofer on January 03, 2012, 08:35:51 PM

Quote from: Proofer on January 03, 2012, 08:23:54 PM

2.2Gh/s

Only change was adding this to .conf:
"no-longpoll" : true,

...which I have now removed, as the intermittent "not responding" problem was costing much less than 6%.

That's a lot shyter than I would have expected... I guess longpoll is still a most valid mechanism. Was there any difference otherwise?

Not that I noticed. I don't pay any attention to the status line, though.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: Proofer on January 03, 2012, 08:35:51 PM

Quote from: Proofer on January 03, 2012, 08:23:54 PM

2.2Gh/s

Only change was adding this to .conf:
"no-longpoll" : true,

...which I have now removed, as the intermittent "not responding" problem was costing much less than 6%.

That's a lot shyter than I would have expected... I guess longpoll is still a most valid mechanism. Was there any difference otherwise?

Proofer

member

Activity: 266

Merit: 36

Quote from: Proofer on January 03, 2012, 08:23:54 PM

2.2Gh/s

Only change was adding this to .conf:
"no-longpoll" : true,

...which I have now removed, as the intermittent "not responding" problem was costing much less than 6%.

Proofer

member

Activity: 266

Merit: 36

Quote from: kano on January 03, 2012, 08:19:02 PM

Quote from: Proofer on January 03, 2012, 08:03:23 PM

In first 1.5 hours without longpoll, reject rate is 6%; formerly it was less than 1/10 that.

The reject rate should be DIRECTLY related to LP (unless you are doing something weird like CPU mining)
So if you are testing this mining on a low hash rate machine - those numbers will mean nothing.
6% is way too high for it to be a result that makes any sense at all unless you are mining with a very low hash rate.

2.2Gh/s

Only change was adding this to .conf:
"no-longpoll" : true,

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: Proofer on January 03, 2012, 08:03:23 PM

Quote from: -ck on January 03, 2012, 06:05:58 PM

cgminer's stale rate should be exceptionally low even without longpoll, but it will be slightly higher.

In first 1.5 hours without longpoll, reject rate is 6%; formerly it was less than 1/10 that.

The reject rate should be DIRECTLY related to LP (unless you are doing something weird like CPU mining)
So if you are testing this mining on a low hash rate machine - those numbers will mean nothing.
6% is way too high for it to be a result that makes any sense at all unless you are mining with a very low hash rate.

Proofer

member

Activity: 266

Merit: 36

Quote from: -ck on January 03, 2012, 06:05:58 PM

cgminer's stale rate should be exceptionally low even without longpoll, but it will be slightly higher.

In first 1.5 hours without longpoll, reject rate is 6%; formerly it was less than 1/10 that.

vapourminer

legendary

Activity: 4354

Merit: 3614

what is this "brake pedal" you speak of?

Quote from: P4man on January 03, 2012, 03:36:42 PM

Anyway, lets see if we can find anything else in common, besides just cgminer.

- Im using google DNS
- I have donations enabled. (thinking of disabling it, just for testing)
- I have several pools configured in fail-over (but Ive since encountered the problem on several different pools)
- Im behind a NAT router
- hmm?

Ill add my 2 cents, as I have occasionally had your problem (cgminer cant connect, keeps trying to find a pool, submits the odd random share though, only a restart cures it). happened in 2.1.0 but not (so far) 2.1.1. it was pretty infrequent though, rare enough I wasnt too worried. but now that Im reading the thread...

machines are win XP SP3, vista 32 bit SP2, Win7 64 bit. various driver versions as the only one I really keep current is the 6770 on the HTPC.

google DNS
donation on
3 pools in failover mode: Slush, BTC Guild, Deepbit - in that order
behind NAT (well, Internet Connection Sharing on the win7 box as I have a wireless 3G connection via USB modem as internet)

when cgminer goes into the weeds I can still browse the network and internet on the affected machines.

I seem to have been affected way less than some and my modem drops and "redials" every 24 hours.

EDIT: no one has mentioned if the cards in question are OCd. I do have all cards wound up pretty tight OC wise. but never had errors, bluescreens, driver recovers, SICKs, DEADs, etc. very stable so far. I do folding @ home too so Im a fairly old hand at winding the snots outta videocards and still letting them live long useful lives

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: Proofer on January 03, 2012, 06:29:56 PM

Quote from: -ck on January 03, 2012, 06:05:58 PM

Can you guys try starting it without longpoll? Maybe the longpoll switch code is responsible which is new since 2.1.0

Seems implausible, as I had the problem with 2.1.0.

English grammar can be confusing at times, I admit. It's been there since 2.1.0.... it's not in 2.0.8 but is in 2.1.0

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