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

[GenTarkin]

2.0.8 is about 7mh/s slower than 2.0.3 on my HD 6950 =./

Havent tried any versions between 2.0.3 and this one

[1713989212]

1713989212

[1713989212]

1713989212

[1713989212]

1713989212

[ancow]

Interesting setup.  A couple questions
1) What starts miner.conf on boot.

Upstart.

2) You say you use cgminer.conf to handle configuration but I don't see where you reference it (or the -c parameter).  What am I missing?

I assume the "/usr/local/bin/startcg" program/script does that.

3) What does the "-c" do in the line "exec /usr/bin/screen -dmS Miner su -c /usr/local/bin/startcg ubuntu"?

It's quite obviously a parameter to su. See "man su"

[DeathAndTaxes]

I assume the "/usr/local/bin/startcg" program/script does that.

He provided the startcg script also which is why I was wondering where the -c parameter and name of config file is:

startcg

#!/bin/bash

export AMDAPPSDKROOT=/home/ubuntu/AMD-APP-SDK-v2.4-lnx32/
export LD_LIBRARY_PATH=${AMDAPPSDKROOT}lib/x86:${LD_LIBRARY_PATH}
export DISPLAY=:0

cgminer 2>>/var/log/cgminer.log

[ancow]

He provided the startcg script also which is why I was wondering where the -c parameter and name of config file is:

You do realise that cgminer automatically uses ~/.cgminer/cgminer.conf if nothing else is specified?

[DeathAndTaxes]

He provided the startcg script also which is why I was wondering where the -c parameter and name of config file is:

You do realise that cgminer automatically uses ~/.cgminer/cgminer.conf if nothing else is specified?

Without the -c param?  No I wasn't aware of that.  I assumed (I guess incorrectly) that it used the default config if you told it to read from config file w/ -c

[ancow]

He provided the startcg script also which is why I was wondering where the -c parameter and name of config file is:

You do realise that cgminer automatically uses ~/.cgminer/cgminer.conf if nothing else is specified?

Without the -c param?  No I wasn't aware of that.  I assumed (I guess incorrectly) that it used the default config if you told it to read from config file w/ -c

And I was beginning to wonder what I was missing...
I'm sure if you search up this thread (either for the 2.0.8 or the 2.0.7 announcement, IIRC), you'll find the proper info.

[BkkCoins]

Interesting setup.  A couple questions
1) What starts miner.conf on boot.
2) You say you use cgminer.conf to handle configuration but I don't see where you reference it (or the -c parameter).  What am I missing?
3) What does the "-c" do in the line "exec /usr/bin/screen -dmS Miner su -c /usr/local/bin/startcg ubuntu"?

Although mostly answered above I'll add a few bits...

1. On Ubuntu now the preferred init system is Upstart. It should eventually replace SysV (/etc/init.d style) methods for system init. Note that the miner.conf is not a script but a config that tells Upstart what and when to do things. I could improve mine by having it cue on X started rather than the "sleep 15" (which allows X time to init), but I'm lazy and the fews pokes I made at syntax to wait for X didn't work right.

2. I coded the changes a while back (and submitted to author) for writing a cgminer.conf based on current values. One of the "enhancements" was it being able to use a default config so that simpler startup commands could be used and config tweaks while running could be saved. Also a new pool config format was a side effect.

3. This tells su to run a command (as optional user too). I use this as Upstart currently has no better way to "run as" a non-root user. I don't run as root since a vulnerability in cgminer could allow a hacker to gain root access. It does talk across the net after all (though it doesn't listen, better safe than sorry).

[kano]

...
2. I coded the changes a while back (and submitted to author) for writing a cgminer.conf based on current values. One of the "enhancements" was it being able to use a default config so that simpler startup commands could be used and config tweaks while running could be saved. Also a new pool config format was a side effect.
...

Ah it was you ...
We have recently had a discussion in this thread about that code that doesn't work ...
But no one replied that they were the one who wrote it.

If you start cgminer with multiple GPU's and get it to save.
Then restart cgminer loading the default it created - it fails to load it.
I think it's caused by decimal points in comma separated numbers ...
Anyway - you should fix it ...

On Linux it's just that one failure, but on windows I think it gets more failures.

Specific example:
https://bitcointalk.org/index.php?topic=28402.msg646839#msg646839

Read above and below that link also.

[BkkCoins]

...
2. I coded the changes a while back (and submitted to author) for writing a cgminer.conf based on current values. One of the "enhancements" was it being able to use a default config so that simpler startup commands could be used and config tweaks while running could be saved. Also a new pool config format was a side effect.
...

Ah it was you ...
We have recently had a discussion in this thread about that code that doesn't work ...
But no one replied that they were the one who wrote it.

If you start cgminer with multiple GPU's and get it to save.
Then restart cgminer loading the default it created - it fails to load it.
I think it's caused by decimal points in comma separated numbers ...
Anyway - you should fix it ...

On Linux it's just that one failure, but on windows I think it gets more failures.

Specific example:
https://bitcointalk.org/index.php?topic=28402.msg646839#msg646839

Read above and below that link also.

The commas mentioned are actually what separate each GPU value and are not part of the numeric value. I have been using my code with 2 GPUs without problems and have saved/loaded many times. I'm not saying the problem doesn't exist, just that it may be something specific to this user/config that needs to be looked at and figured out.

Also, I'm pretty sure that I have different code on my system than what was released. This happened due to the timing and my continued work on it after I submitted it. I think the release version saves some values that are never changed by the user's manual tweaking. That wouldn't cause this issue but once I saw that I modified my code to save the different tweaked values.

I didn't submit my changes because it was unclear if that was what most users would want and it was untested. Anyway, it's a fuzzy area for me as I don't know if my code works fine because it uses different values. The real problem is that no one except me tested the code and I've seen almost zero feedback on whether it works for most people or is broken everywhere. I do know without doubt that saving and loading works for me.

I'm willing to fix it and submit a patch but I'll need clear details on what happens that's wrong as I do not get the same behavior here. eg. my copy writes out
...
"intensity" : "8,8",
"gpu-engine" : "1020,970",
"gpu-fan" : "50-85,50-85",
"gpu-memclock" : "300,300",
"gpu-powertune" : "0,0",
"gpu-vddc" : "1.161,1.174",
"temp-cutoff" : "95,95",
"temp-overheat" : "85,85",
"temp-target" : "70,70",
...
when I save.

Oh, and a problem for me is that I'm still using my own edit of 2.0.6 - so I'd actually need to sync to the newest version before I could fix anything. Drats.

[-ck]

I believe the problem is actually that the vddc is saved as a range instead of a single number. I will look into it at some stage...

[kano]

...
2. I coded the changes a while back (and submitted to author) for writing a cgminer.conf based on current values. One of the "enhancements" was it being able to use a default config so that simpler startup commands could be used and config tweaks while running could be saved. Also a new pool config format was a side effect.
...

Ah it was you ...
We have recently had a discussion in this thread about that code that doesn't work ...
But no one replied that they were the one who wrote it.

If you start cgminer with multiple GPU's and get it to save.
Then restart cgminer loading the default it created - it fails to load it.
I think it's caused by decimal points in comma separated numbers ...
Anyway - you should fix it ...

On Linux it's just that one failure, but on windows I think it gets more failures.

Specific example:
https://bitcointalk.org/index.php?topic=28402.msg646839#msg646839

Read above and below that link also.

The commas mentioned are actually what separate each GPU value and are not part of the numeric value. I have been using my code with 2 GPUs without problems and have saved/loaded many times. I'm not saying the problem doesn't exist, just that it may be something specific to this user/config that needs to be looked at and figured out.

It's a bug.

[BkkCoins]

...
2. I coded the changes a while back (and submitted to author) for writing a cgminer.conf based on current values. One of the "enhancements" was it being able to use a default config so that simpler startup commands could be used and config tweaks while running could be saved. Also a new pool config format was a side effect.
...

Ah it was you ...
We have recently had a discussion in this thread about that code that doesn't work ...
But no one replied that they were the one who wrote it.

If you start cgminer with multiple GPU's and get it to save.
Then restart cgminer loading the default it created - it fails to load it.
I think it's caused by decimal points in comma separated numbers ...
Anyway - you should fix it ...

On Linux it's just that one failure, but on windows I think it gets more failures.

Specific example:
https://bitcointalk.org/index.php?topic=28402.msg646839#msg646839

Read above and below that link also.

The commas mentioned are actually what separate each GPU value and are not part of the numeric value. I have been using my code with 2 GPUs without problems and have saved/loaded many times. I'm not saying the problem doesn't exist, just that it may be something specific to this user/config that needs to be looked at and figured out.

It's a bug.

I'm not convinced. The example.conf file in git has 0.000 values in it (invalid) and maybe some users are leaving those values in on an initial conf setup. The write_config simply takes the current value of the gpu_vddc variable and writes it out. So for it to write 0.000 out the gpus would have to be set for 0.000 voltage. Maybe there is a situation where the runtime voltage value is incorrectly set to 0.000, or maybe under some conditions the variable is getting trashed to 0. The problem for me is that it works fine here and so unless someone can document how to reproduce these 0.000 vddc values I'm unable to track down how the file got written that way.

[-ck]

A value of 0 in the configuration implies "not set" which means cgminer does not try to set the value it has received.

[DeathAndTaxes]

...
2. I coded the changes a while back (and submitted to author) for writing a cgminer.conf based on current values. One of the "enhancements" was it being able to use a default config so that simpler startup commands could be used and config tweaks while running could be saved. Also a new pool config format was a side effect.
...

Ah it was you ...
We have recently had a discussion in this thread about that code that doesn't work ...
But no one replied that they were the one who wrote it.

If you start cgminer with multiple GPU's and get it to save.
Then restart cgminer loading the default it created - it fails to load it.
I think it's caused by decimal points in comma separated numbers ...
Anyway - you should fix it ...

On Linux it's just that one failure, but on windows I think it gets more failures.

Specific example:
https://bitcointalk.org/index.php?topic=28402.msg646839#msg646839

Read above and below that link also.

The commas mentioned are actually what separate each GPU value and are not part of the numeric value. I have been using my code with 2 GPUs without problems and have saved/loaded many times. I'm not saying the problem doesn't exist, just that it may be something specific to this user/config that needs to be looked at and figured out.

It's a bug.

I'm not convinced. The example.conf file in git has 0.000 values in it (invalid) and maybe some users are leaving those values in on an initial conf setup. The write_config simply takes the current value of the gpu_vddc variable and writes it out. So for it to write 0.000 out the gpus would have to be set for 0.000 voltage. Maybe there is a situation where the runtime voltage value is incorrectly set to 0.000, or maybe under some conditions the variable is getting trashed to 0. The problem for me is that it works fine here and so unless someone can document how to reproduce these 0.000 vddc values I'm unable to track down how the file got written that way.

I recall this happening to me (was easily fixed) but I will see if I can replicate it this evening.

IIRC it went something like this
a) start cgminer using command line params (all valid).
b) cgminer runs & mines fine.
c) use save configuration to default file option.
c) open file and some params (not ones I explicitly set like voltage) are 0.00.
d) launch cgminer and it complains about file format.  removing VDDC and other params fixes issue.

Commenting on the bolded part ... sometimes I access cgminer on my windows workstation using RDP.  That confuses cgminer and it reports clocks and voltage as zero.  There may be other times (issue w/ ADL) where cgminer is reporting invalid data (despite running fine).  Maybe the config file "writer" function should do some error checking and not write obviously invalid data.  Alternatively maybe cgminer can ignore zeroed values on startup (and not complain).

Still a minor bug.  The use of config file has made administration so much easier.

[DeathAndTaxes]

A value of 0 in the configuration implies "not set" which means cgminer does not try to set the value it has received.

However I do recall cgminer not starting up complaining about bad values.  What about 0.00 does it just ignore those or does it error out?

[BkkCoins]

I recall this happening to me (was easily fixed) but I will see if I can replicate it this evening.

IIRC it went something like this
a) start cgminer using command line params (all valid)
b) cgminer runs & mines fine
c) use save configuration to default file option
c) open file and some params (not ones I explicitly set like voltage) are 0.00
d) launch cgminer and it complains about file format.  removing VDDC and other params fixes issue.

I'd be very interested to know if it only happens with a value not set by previous conf or altered by user, ie. somehow defaulted by cgminer. It could be that vddc variable is not set unless explicit by loading conf or runtime user interaction.

I checked my local code compared to git and the git release stores gpu_vddc value but my local code access the ADL value differently. I recall that gpu_vddc is not altered when the user tweaks a value but the ADL value always has actual GPU setting. This is why my code writes a "current" config whereas I think the git code only writes whatever was loaded by past conf. This only has bearing for runtime gpu settings.

I should probably merge my code with git for an update as I think most likely users want to write a config containing actual current values, and it seems like this would also resolve any issue with invalid gpu_vddc values.

[BkkCoins]

A value of 0 in the configuration implies "not set" which means cgminer does not try to set the value it has received.

However I do recall cgminer not starting up complaining about bad values.  What about 0.00 does it just ignore those or does it error out?

I looked at the load config code and it compares the read value with a range <= 0 && >= 9999 to determine if error. So it should not allow any invalid value for gpu_vddc and should throw an error. The example.conf shouldn't have 0.000 there as default. Presumably a missing line would result in a default supplied by ADL code but I'm not certain.

[DeathAndTaxes]

A value of 0 in the configuration implies "not set" which means cgminer does not try to set the value it has received.

However I do recall cgminer not starting up complaining about bad values.  What about 0.00 does it just ignore those or does it error out?

I looked at the load config code and it compares the read value with a range <= 0 && >= 9999 to determine if error. So it should not allow any invalid value for gpu_vddc and should throw an error. The example.conf shouldn't have 0.000 there as default. Presumably a missing line would result in a default supplied by ADL code but I'm not certain.

Weird.  Let me try an replicate it tonight.

[P4man]

if I can replicate it this evening.

IIRC it went something like this
a) start cgminer using command line params (all valid).
b) cgminer runs & mines fine.
c) use save configuration to default file option.
c) open file and some params (not ones I explicitly set like voltage) are 0.00.
d) launch cgminer and it complains about file format.  removing VDDC and other params fixes issue.

I can confirm this. I have the exact same thing. Only VDDC is "wrong" and set to zero. Trying to launch cgminer results in an error unless I fill out the VDCC values or remove those lines.

[BkkCoins]

I've sync'd my local code to 2.0.8 now and the values for gpu settings are taken from ADL variables. This has been working for me and I think likely prevents a zero value ever getting written. I should make a patch and get this out to a few others for testing.

My code also has a display option for "fan in percent" as well (which is what I much prefer). If the RPM drops to zero it overrides percent and shows 0 RPM, just to be safe since apparently sometimes percents don't show correctly when the fan stops.