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

[KyrosKrane]

There are 2 temps.
The one passed there is the internal to the KLN temp target.

The code one is:
The abort temp:
KLN_KILLWORK_TEMP       53.5
It stops until it cools down to
KLN_COOLED_DOWN         45.5

Thanks, Kano, appreciate the reply.

Does that mean the temp in the settings file isn't actually used by cgminer? It's just passed to the Klondike device itself and used there?  Other than recompiling, is there a way to modify KLN_KILLWORK_TEMP? I'm guessing no; all caps usually indicates a constant in the code.

[1534265414]

1534265414

[1534265414]

1534265414

[1534265414]

1534265414

[1534265414]

1534265414

[1534265414]

1534265414

[loshia]

Uploaded 3.12.3 with the correct fix now, reused same announce post.

Thank you Con!
I will give it a shot and report back if get work locks are gone.
However I see that you still write in last_device_valid_work get_work without a lock. Is it ok? Every where you use locks when writing to it but not in get work
Thank you

[-ck]

Uploaded 3.12.3 with the correct fix now, reused same announce post.

Thank you Con!
I will give it a shot and report back if get work locks are gone.
However I see that you still write in last_device_valid_work get_work without a lock. Is it ok? Every where you use locks when writing to it but not in get work
Thank you

For that particular statistic it's pretty harmless and it's in get_work() for which the code needs to be as lean as possible. The lock protecting it elsewhere, stats_lock, is a global  lock potentially contended by quite a few threads so I decided against it.

[loshia]

Uploaded 3.12.3 with the correct fix now, reused same announce post.

Thank you Con!
I will give it a shot and report back if get work locks are gone.
However I see that you still write in last_device_valid_work get_work without a lock. Is it ok? Every where you use locks when writing to it but not in get work
Thank you

For that particular statistic it's pretty harmless and it's in get_work() for which the code needs to be as lean as possible. The lock protecting it elsewhere, stats_lock, is a global  lock potentially contended by quite a few threads so I decided against it.

Thank you!
I will post back my results in a couple of hours

[wyj1888]

who can gvie me a cgminer(AMD) for  MAX??   

[-ck]

who can gvie me a cgminer(AMD) for  MAX??   

You're in the wrong place. cgminer is a bitcoin miner ONLY and has no GPU code any more. Try sgminer.

[wyj1888]

who can gvie me a cgminer(AMD) for  MAX??   

You're in the wrong place. cgminer is a bitcoin miner ONLY and has no GPU code any more. Try sgminer.

where can I download Sgminer??

[-ck]

who can gvie me a cgminer(AMD) for  MAX??   

You're in the wrong place. cgminer is a bitcoin miner ONLY and has no GPU code any more. Try sgminer.

where can I download Sgminer??

http://lmgtfy.com/?q=sgminer

[Buchi-88]

Hello and thanks for the new release,

but I have also many HW Errors with this version?

I start the device with this command:

Code:

cd c:\programme\CGMiner-run
cgminer.exe -c c:\programme\CGMiner-run\cgminer.conf --icarus-timing=short --quiet --anu-freq 200

HW Errors are between 2 - 5% Is this OK??

greets

[-ck]

Hello and thanks for the new release,

but I have also many HW Errors with this version?

I start the device with this command:

Code:

cd c:\programme\CGMiner-run
cgminer.exe -c c:\programme\CGMiner-run\cgminer.conf --icarus-timing=short --quiet --anu-freq 200

HW Errors are between 2 - 5% Is this OK??

greets

You no longer need icarus timing with this release so remove it. HW errors are device dependant and 2-5% at frequency 200 (which is the default frequency anyway) that does seem a little high, but if your hashrate is consistent with frequency 200 (which is just under 1.6GH) then you can just ignore the errors. Most will run well at 250 without significantly more errors, but if your hashrate doesn't rise when you raise the frequency, don't do that. My particular one runs well at 275 but generates a lot of errors which I ignore since it still generates 2.2GH of good hashes.

[Buchi-88]

Hello and thanks for the new release,

but I have also many HW Errors with this version?

I start the device with this command:

Code:

cd c:\programme\CGMiner-run
cgminer.exe -c c:\programme\CGMiner-run\cgminer.conf --icarus-timing=short --quiet --anu-freq 200

HW Errors are between 2 - 5% Is this OK??

greets

You no longer need icarus timing with this release so remove it. HW errors are device dependant and 2-5% at frequency 200 (which is the default frequency anyway) that does seem a little high, but if your hashrate is consistent with frequency 200 (which is just under 1.6GH) then you can just ignore the errors. Most will run well at 250 without significantly more errors, but if your hashrate doesn't rise when you raise the frequency, don't do that. My particular one runs well at 275 but generates a lot of errors which I ignore since it still generates 2.2GH of good hashes.

Thanks,

i will test with these settings, and report at evening my experience

Code:

cd c:\programme\CGMiner-run cgminer.exe -c c:\programme\CGMiner-run\cgminer.conf  --quiet --anu-freq 200

config:

Code:

{
"pools" : [
{
"url" : "stratum+tcp://mint.bitminter.com:3333",
"user" : "xxx",
"pass" : "egalo",
"pool-priority" : "0"
}
],
"api-allow" : "W:127.0.0.1",
"api-listen" : true,
"api-port" : "4028",
"expiry" : "120",
"hotplug" : "5",
"kernel-path" : "/usr/local/bin",
"log" : "5",
"queue" : "1",
"scan-time" : "60",
"shares" : "0",
"no-pool-disable" : true
}

greets

[Grinners]

Downloaded the zip file.

Now I am confused... Do I not just run "C:\Chris\cgminer 3\cgminer_keccak-master\cgminer --keccak -o stratum+tcp://maxpool.1gh.com:17333 -u mJ75whnUbeJfu8dbqomn8ekEJ2aRUhwTkJ -p x" in command prompt?

"cgminer is not recognized" in command prompt...?

Yes super noob here

[-ck]

Downloaded the zip file.

Now I am confused... Do I not just run "C:\Chris\cgminer 3\cgminer_keccak-master\cgminer --keccak -o stratum+tcp://maxpool.1gh.com:17333 -u mJ75whnUbeJfu8dbqomn8ekEJ2aRUhwTkJ -p x" in command prompt?

"cgminer is not recognized" in command prompt...?

Yes super noob here

You are in completely the wrong place as this is the main forum thread for the master cgminer code which is purely for bitcoin mining ONLY. We have no keccak code and wherever you downloaded that from is where you need to seek help.

[KyrosKrane]

It would be nice if folks who are using forked miners (basically anything recent with GPU/scrypt support) would ask the developers of their version to rename the software, so it's clear it's no longer the mainline cgminer.

[HellDiverUK]

WARNING:  There may be a problem with cgminer 3.12.1 that makes it stop retrieving work. I will investigate further and possibly release a fix in the next 24 hours. In the meantime I suggest users do not upgrade.

Sigh.

The Antminer U1 support isn't very stable either, mine all crapped out after an hour or so, I ended up with 50-odd as they dropped out and came back on.  I have 10 of them on a Anker hub, running off a PC running Debian Wheezy.

I'll update the error messages when they happen again, I'm on an intermittent SSH connection through my phone from work at the moment.

Hmm I can try reinstating the attempted reset but I'm not sure it's going to fix that... How much were you overclocking them?

Sorry, only got back to this thread.  2GH, which they've been stable with.  They do run basically OK with BFG at 2.2GH (one or two of them run at 10% HW error as reported by BFG), but I tried knocking them down to 2GH to see if that would help.

Overnight I now have 20 ANU devices reported by the API, when I actually only have 10. 

[-ck]

WARNING:  There may be a problem with cgminer 3.12.1 that makes it stop retrieving work. I will investigate further and possibly release a fix in the next 24 hours. In the meantime I suggest users do not upgrade.

Sigh.

The Antminer U1 support isn't very stable either, mine all crapped out after an hour or so, I ended up with 50-odd as they dropped out and came back on.  I have 10 of them on a Anker hub, running off a PC running Debian Wheezy.

I'll update the error messages when they happen again, I'm on an intermittent SSH connection through my phone from work at the moment.

Hmm I can try reinstating the attempted reset but I'm not sure it's going to fix that... How much were you overclocking them?

Sorry, only got back to this thread.  2GH, which they've been stable with.  They do run basically OK with BFG at 2.2GH (one or two of them run at 10% HW error as reported by BFG), but I tried knocking them down to 2GH to see if that would help.

Overnight I now have 20 ANU devices reported by the API, when I actually only have 10. 

But they're still mining right? So the die - zombie - hotplug is just an ugly cosmetic issue, not that they have failed and stopped mining indefinitely. I've been running mine at 275 (2.2GH) which has been stable but I doubt they're all stable at that speed.

[fastcore]

Trend identified cgminer.exe as a virus and wiped it off my computer, blah!

[Dunkelheit667]

First of all, thanks a bunch for the Antminer U1 support.

3.12.3 running stable for two hours on my rpi. So far so good.

Just a thought, would be nice to have 12.5 MHz increments, allowing more specific fine tuning with +/- 100 GHash/s steps. Guess it's not that difficult implementing those values into the freq. table?

freq_hex freq_mhz ghash_s
0781   200.0   1.600
0801   212.5   1.700
0881   225.0   1.800
0901   237.5   1.900
0981   250.0   2.000
0A01   262.5   2.100
0A81   275.0   2.200

etc.

[Karin]

Unofficial Mac binaries have been updated for v3.12.3 and are available here.

These are precompiled universal binaries that support Mac OS X 10.5.8 through 10.9+.

[-ck]

First of all, thanks a bunch for the Antminer U1 support.

3.12.3 running stable for two hours on my rpi. So far so good.

Just a thought, would be nice to have 12.5 MHz increments, allowing more specific fine tuning with +/- 100 GHash/s steps. Guess it's not that difficult implementing those values into the freq. table?

freq_hex freq_mhz ghash_s
0781   200.0   1.600
0801   212.5   1.700
0881   225.0   1.800
0901   237.5   1.900
0981   250.0   2.000
0A01   262.5   2.100
0A81   275.0   2.200

etc.

The documentation specifies only certain numbers, have you seen anywhere the values you mention? It's easy to hack the code if you wish to try them and report back