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

[tealover]

Ok I'm using cgminer.exe now

Using (4) 5830 overclocked to 945 mhz, and temps are at 60c

I'll see how it goes

[1714776738]

1714776738

[tealover]

GPU1: Invalid nonce HW error this is coming up infrequently.

Up above it says HW:12 next to GPU1

GPU1 is still getting me shares, but less than my other GPUs.

[slush]

Up above it says HW:12 next to GPU1
GPU1 is still getting me shares, but less than my other GPUs.

Looks like hw issue with that GPU. I wouldn't be surprised if phoenix reported incorrect hashrate for that GPU...

[tealover]

Up above it says HW:12 next to GPU1
GPU1 is still getting me shares, but less than my other GPUs.

Looks like hw issue with that GPU. I wouldn't be surprised if phoenix reported incorrect hashrate for that GPU...

That GPU is only getting about half the shares as my other 3 GPUs now

[os2sam]

GPU1: Invalid nonce HW error this is coming up infrequently.

Up above it says HW:12 next to GPU1

GPU1 is still getting me shares, but less than my other GPUs.

I would lower the clock on that GPU till you don't get any hardware error's.  It has probably taken some stress and can't run that high anymore.  My 5830 used to do 975 till stratum support then I had to lower it to 960.

But I don't recall ever seeing an "invalid nonce" error??
Sam

[tealover]

GPU1: Invalid nonce HW error this is coming up infrequently.

Up above it says HW:12 next to GPU1

GPU1 is still getting me shares, but less than my other GPUs.

I would lower the clock on that GPU till you don't get any hardware error's.  It has probably taken some stress and can't run that high anymore.  My 5830 used to do 975 till stratum support then I had to lower it to 960.

But I don't recall ever seeing an "invalid nonce" error??
Sam

Lowered overclock to default and still getting 1/2 HW Errors on that 1 GPU Temps on it are good though, around 60c

[os2sam]

GPU1: Invalid nonce HW error this is coming up infrequently.

Up above it says HW:12 next to GPU1

GPU1 is still getting me shares, but less than my other GPUs.

I would lower the clock on that GPU till you don't get any hardware error's.  It has probably taken some stress and can't run that high anymore.  My 5830 used to do 975 till stratum support then I had to lower it to 960.

But I don't recall ever seeing an "invalid nonce" error??
Sam

Lowered overclock to default and still getting 1/2 HW Errors on that 1 GPU Temps on it are good though, around 60c

The default being 800Mhz right?  What's your memory clock set to?

I would say that GPU may have taken some damage/stress.  If you've been running it for a year and a half that's probably a pretty good run though.

I'd run it at stock clock till it died.
Sam

[tealover]

GPU1: Invalid nonce HW error this is coming up infrequently.

Up above it says HW:12 next to GPU1

GPU1 is still getting me shares, but less than my other GPUs.

I would lower the clock on that GPU till you don't get any hardware error's.  It has probably taken some stress and can't run that high anymore.  My 5830 used to do 975 till stratum support then I had to lower it to 960.

But I don't recall ever seeing an "invalid nonce" error??
Sam

Lowered overclock to default and still getting 1/2 HW Errors on that 1 GPU Temps on it are good though, around 60c

The default being 800Mhz right?  What's your memory clock set to?

I would say that GPU may have taken some damage/stress.  If you've been running it for a year and a half that's probably a pretty good run though.

I'd run it at stock clock till it died.
Sam

Yes 800 mhz and memory at 500

[-ck]

Interesting. The only thing I can think of that could cause this is trying to submit a share even before gbt is fully set up, or the gbt structures sent by the pool are corrupt somehow. Does this happen shortly after startup? Is the GBT pool somewhere I can test it publicly or is this your custom pool? Thanks.

This does happen shortly after startup, and I am only running one 5830, so trying to submit a share that quickly seems unlikely.  I only ran it once, though, so not impossible by any means.  The pool is the one previously run by he who shall not be named.  (aka eligius)

ETA, I was running in screen, so I don't know if this is the same error I was getting before.  I can tell you that on 2.9.4 it first ran quite a while before crashing, and then crashed on startup when I ran it again, at which point I went back to 2.8.7 (and then when 2.9.5 came out, I got the segfault instead of the error I was getting in 2.9.4 [which I quoted someone else mentioning a few pages back]).  That said, 2.9.5 crashed on startup more than once, and this is why I didn't go for a second test run when 2.9.6 crashed at startup.

Well the crash is happening in the share submission path, so it must be trying to submit a share. That said, I found something else that might be a problem. Try current git master please.

[-ck]

I'm wondering if there is a way get get cgminer to use GBT with bitcoind (satoshi client), I know bitcoind doesn't support longpoll but it does support coinbase/append which should be enough to use GBT (i'm guessing) but it seems I can only get it to use getwork with bitcoind.

Any ideas? or is this just not possible at this point.

Nope, bitcoind does not support the extensions required by pool mining for cgminer to work with it at this time.

[rampone]

Hey,

I am trying to cross compile the newest cgminer for a tp-link 1043nd and I am failing. Anyone did that already and has a binary? Maybe it is not worth it, when asics come out, cpu of the router might be too slow?

the latest mistake compiling it is:

make[2]: Entering directory `/home/rampone/cgminerarm/cgminer'
  CC     cgminer-cgminer.o
In file included from /usr/include/curl/curl.h:35:0,
                 from cgminer.c:39:
/usr/include/curl/curlrules.h:142:3: error: size of array '__curl_rule_01__' is negative
/usr/include/curl/curlrules.h:152:3: error: size of array '__curl_rule_02__' is negative
In file included from miner.h:9:0,
                 from cgminer.c:44:
/usr/include/pthread.h:665:6: warning: '__regparm__' attribute directive ignored [-Wattributes]
/usr/include/pthread.h:677:3: warning: '__regparm__' attribute directive ignored [-Wattributes]
/usr/include/pthread.h:700:6: warning: '__regparm__' attribute directive ignored [-Wattributes]
/usr/include/pthread.h:713:3: warning: '__regparm__' attribute directive ignored [-Wattributes]
/usr/include/pthread.h:722:6: warning: '__regparm__' attribute directive ignored [-Wattributes]
cgminer.c:2207:13: warning: 'disable_pool' defined but not used [-Wunused-function]
make[2]: *** [cgminer-cgminer.o] Error 1
make[2]: Leaving directory `/home/rampone/cgminerarm/cgminer'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/rampone/cgminerarm/cgminer'

mmmh... its not that important... but hashing with it would be cool

(someone made a version for dd-wrt, but that is mips little endian, tp-link's mips is Big Endian)

[mdude77]

I think there's still something awry with gracefully handling disconnects.  It isn't unique to stratum, as I've seen it on LPs as well.

Right now have three units running... one with 1 GPU, one with 2 GPUs, and one with 3 GPUs.  At the time all were pointed to stratum pools with bitcoind (LP) as a backup.

My internet connection dropped for a short bit.  The 1GPU machine recovered properly.  The 2GPU crashed, the 3GPU hung.

I've seen this before, where those with multiple GPUs crash or hang when the 1GPU continues working.  The 1 and 3 GPU machines are window 7 x64, the 2 GPU is windows 8 x64.

Using 2.9.6.

M

[-ck]

The sudden interruption of work when a GPU is running flat out overclocked to the max is a great way of exposing instability, and has been there for as long as I can remember and is nothing to do with how cgminer handles failover, yet has to do with how tightly overclocked the GPUs are. It goes away if you lower the clocks.

[Roy Badami]

Still seeing backup pools that use stratum+tcp URLs detected as down by cgminer (2.9.6)

e.g. neither of these seem to work right as backup pools :

stratum+tcp://us3.eclipsemc.com:3333
stratum+tcp://eustratum.ozco.in:3333

However specifying them as http (even though they're not) seems to work:

http://us3.eclipsemc.com:3333
http://eustratum.ozco.in:3333

(Note I only see this problem for backup pools - specifying stratum+tcp for my first pool seems to work fine)

roy

[-ck]

Still seeing backup pools that use stratum+tcp URLs detected as down by cgminer (2.9.6)

e.g. neither of these seem to work right as backup pools :

stratum+tcp://us3.eclipsemc.com:3333
stratum+tcp://eustratum.ozco.in:3333

However specifying them as http (even though they're not) seems to work:

http://us3.eclipsemc.com:3333
http://eustratum.ozco.in:3333

(Note I only see this problem for backup pools - specifying stratum+tcp for my first pool seems to work fine)

roy

Yeah, not ideal, is it? Just get rid of *any* prefix and let cgminer figure it out. eg eustratum.ozco.in:3333

[Roy Badami]

Yeah, not ideal, is it? Just get rid of *any* prefix and let cgminer figure it out. eg eustratum.ozco.in:3333

Hmm, I thought I tried that - lemme give it another go....

[Roy Badami]

Yeah, not ideal, is it? Just get rid of *any* prefix and let cgminer figure it out. eg eustratum.ozco.in:3333

Hmm, I thought I tried that - lemme give it another go....

Yep, seems to work - don't know what I did wrong when I tried that in the past...

Thanks

roy

[Roy Badami]

Ah, OK, so you can enter it without any scheme prefix (http: or stratum+tcp:) in either cgminer.conf or in pool management.

But, either way pool management just displays it as http: (regardless of what it actually is).  And when you resave your config file the URLs just get saved to cgminer.conf as http URLs (even if you entered them without the http and even if they're really stratum).

It is a bit confusing, but it doesn't cause any real problems.  It seems that in cgminer http: seems to actually mean autodetect... (ETA: and stratum+tcp: seems to be broken and best avoided)

roy

[rampone]

Oh darn, seems like building on a 64 bit ubuntu with 64bit curl makes problem, when it tries to include it. mmmh. well, i guess ill try a 32bit ubuntu to cross compile cgminer... I'll report...

[-ck]

Oh darn, seems like building on a 64 bit ubuntu with 64bit curl makes problem, when it tries to include it. mmmh. well, i guess ill try a 32bit ubuntu to cross compile cgminer... I'll report...

No, that makes no sense as full 64bit ubuntu is the main development platform for it and where the binaries come from.