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

The code only saves ADL values when auto isn't selected for that value. If auto is on then it writes out the range provided by the user rather than any current value. Also, when I say it saves ADL values it's not querying ADL directly but using values already maintained by cgminer in it's adl structure which should be reflected on the screen at the time a user chooses to write a config. I think that's reasonable but I'm not an expert and ckolivas would have to decide if that's safe.

After reading thru most of the code this was the only way I could see that allowed saving a user tweaked state as a config.

That sounds awfully bug-prone to me.
For one, ADL doesn't have a particularly good record when it comes to reporting back the correct/actual values. Also, instead of not writing out settings that weren't set, it'll write out more or less random values in those cases (e.g. the case where the user doesn't want cgminer to handle those settings; suddenly cgminer will handle them, resulting in possible conflicts with external programs).
cgminer goes out of its way to be safe; I think this change would undermine that. Instead, you should have a look at the code and simply not write out values that mean "unset".

Here's a patch against 2.0.8 for anyone who wants to test and feedback.
It brings in my improved runtime config write code and the fan display in percent option.

http://pastebin.com/PJ7e8sSF

I think I have good logic but wonder if I should change the zero check to some minimum RPM value, eg. <500 so that even if it's not actual zero but just limping like dead it'll indicate that.

The logic I altered is,

if (gf != -1 && (!opt_fan_percent || gf == 0))
  show rpm
else if(gp != -1)
  show percent

only a slight change from previous.

anyone know how i can use cgminer with phatk 2.1?

Percent values are only what PWM settings the card is sending to its fan, and may have absolutely no correlation with what RPM the fan is actually running at. That's why it defaults to showing RPM instead which is actually the detected speed. On the other hand, the idea to show RPM when it's zero is a good safety mechanism, but I assume you take into account that many cards don't report RPM speed?

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.

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.

Weird.  Let me try an replicate it tonight.

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.

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.

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

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

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.

It's a bug.

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

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.

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://bitcointalksearch.org/topic/m.646839

Read above and below that link also.

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