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

[Proofer]

Interesting.
And I may have had the same here; there have been mornings when I checked hashrate and it was surprisingly low. Probably because of that error. When I caught it "live" I  never waited 70 minutes, so you are probably correct that at some point it may recover, I just never waited long enough.

That's exactly what triggered my scrolling through the log this morning:  a low average hash rate, E%, U, etc.

No problems since my last post -- two more hours -- in the same session.

[1715156360]

1715156360

[1715156360]

1715156360

[P4man]

Mine have worked for weeks without problems, or at least without me noticing. It seems to be happening more and more often now.

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?

Ive already ruled out OS and AMD driver versions as its happening on both windows and linux machines here with various drivers and cgminer versions.

[Proofer]

...
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?
...

Donation and NAT, but not Google DNS;  failover-only pools in this order:
Eclipse port 9007;
Bitminter;
Eclipse port 8337;
local bitcoind

[cablepair]

do you guys think its possible for a pool to make your cards run funny if the pool is configured in a certain way?

[-ck]

...
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?
...

Donation and NAT, but not Google DNS;  failover-only pools in this order:
Eclipse port 9007;
Bitminter;
Eclipse port 8337;
local bitcoind

Hmmm...

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

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

[Proofer]

Hmmm...

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

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

Seems implausible, as I had the problem with 2.1.0.

And as reported earlier, the problem, in addition to being highly intermittent, is not persistent.  My current session, which started about 16 hours ago and had three rashes of the problem in its first eight hours or so, has since been cruising fine for eight hours.  At this writing there are 111 instances of "LONGPOLL detected" in the log.

But, ever cooperative, I just now restarted with no-longpoll.

[-ck]

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

[vapourminer]

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

[Proofer]

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.

[kano]

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]

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,

[Proofer]

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%.

[-ck]

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]

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.

[BkkCoins]

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.

[-ck]

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.

[-ck]

Try turning donation off

[-ck]

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.

[bitlane]

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.

[P4man]

[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