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

[DutchBrat]

I turned on donation when it was first introduced but somehow my performance dropped, lots of

'pool not responding' errors

That's the main reason I turned it off back then, I much rather prefer to send some coins once in a while

That said, i am forgetting a lot these days (must be old age lol), so there are some coins coming your way as I type this !

Thanks for your hard and above all very good work 

Brat

[1715127261]

1715127261

[1715127261]

1715127261

[1715127261]

1715127261

[Queelis]

Agreed, you should just enable it and make sure it is stated clearly (and the same message should include explanation how to disable it, e.g. "to disable add -donation 0" flag), especially since the buggy donations are fixed.

It's not like a) people aren't given a choice or instructions how to disable it, and b) everyone who uses knows so much as to enable the donations.

I like the phrase "I believe in the exploitation of the stupid", so if users aren't clever enough to disable donations - well, thanks for their support


On a side note, a question - if I set a GPU voltage in CGminer, then restart the PC and start cgminer without the flag, does the voltage go back to default or stay at the previously set voltage? Because the BIOS says (with Radeon BIOS Editor) GPU voltage at load should be 1.1V, but cgminer and FurMark read it as 1V. That will hinder my overclocking results in the future.

[-ck]

Thanks a lot! The poor performance with donation on was my fault initially I've since fixed it but it doesn't matter. I haven't made a decision about enabling donations by default but for now it's not a high priority issue.

If you successfully close cgminer properly it *should* return to the default values on shutdown. That said, the windows version has this knack of not closing properly. How/why, remains a mystery. Nonetheless the settings will go back to default on a reboot. None of the settings cgminer uses tell the card to keep settings across a reboot.

[Queelis]

If you successfully close cgminer properly it *should* return to the default values on shutdown. That said, the windows version has this knack of not closing properly. How/why, remains a mystery. Nonetheless the settings will go back to default on a reboot. None of the settings cgminer uses tell the card to keep settings across a reboot.

Thanks. Upon selling and removing my second graphics card I'll reinstall the drivers and will see whether this changes anything and then report back to you.

[hmblm1245]

I am having a hard time finding this and i'm sure its posted but i'll ask anyways. I have a 4 5850 setup and one of the 4 card's fan speed is showing 0RPM (sometimes 20RPM) for its fan speed. the rest are showing 2000-3000RPMish. the fan speed set in the conf file is 0-85 with auto-fan turned off. Below is an example of my config minus the user info. Also. i removed that card (card 4)and then the next card (card 3) is showing 0 - 20 RPM for its fan speed. GPUz and Afterburner show 85 percent and in the 2000-3000RPM range.

is there something that i am missing?

intensity" : "9,9,9,9",
"gpu-engine" : "0-920,0-920,0-920,0-920",
"gpu-fan" : "0-50,0-80,0-80,0-80",
"gpu-memclock" : "500,500,500,500",
"gpu-powertune" : "0,0,0,0",
"gpu-vddc" : "1.200,1.200,1.200,1.200",
"temp-cutoff" : "95,95,95,95",
"temp-overheat" : "85,85,85,85",
"temp-target" : "75,75,75,75",

"algo" : "c",
"api-port" : "4028",
"expiry" : "120",
"gpu-threads" : "2",
"log" : "5",
"queue" : "1",
"retry-pause" : "5",
"scan-time" : "60",
"temp-hysteresis" : "3",
"worksize" : "0",

"donation" : "0.00",
"shares" : "0",
"kernel-path" : "/usr/local/bin"

[siggy]

Is it possible to turn on the --submit-stale option in the *.conf file? 

What is the exact format the entry needs to be in the file?

thanks,
Sigg

[DeathAndTaxes]

Is it possible to turn on the --submit-stale option in the *.conf file? 
What is the exact format the entry needs to be in the file?

It can be done from the config.

I don't have it in front of me but I believe it is just:

Code:

"submit-stale" : true

[jake262144]

Code:

"submit-stale" : true

That's precisely what it is.
Unless you're appending that option at the very end, you'll need a comma too:

Code:

"submit-stale" : true,

That should be obvious but I'm pointing it out anyway for the sake of the less technical crowd. JSON takes no prisoners.

[jjiimm_64]

Code:

"submit-stale" : true

That's precisely what it is.
Unless you're appending that option at the very end, you'll need a comma too:

Code:

"submit-stale" : true,

That should be obvious but I'm pointing it out anyway for the sake of the less technical crowd. JSON takes no prisoners.

speaking of JSON,  has anyone got it working for the Volts ? 

anytime I put volts into the config, i cannot start cgminer. it will display a json error and stop. 

[jake262144]

You cannot use the default "0.000" values. Try populating the values with correct voltages.

Also, make sure you don't use comma as your decimal point as some cultures do. Should you do that, JaSON will massacre the poor, unsuspecting cgminer and no mining will be done that day.

[miscreanity]

speaking of JSON,  has anyone got it working for the Volts ?  

Code:

"gpu-vddc" : "1.100",

That line works for my setup.

[jjiimm_64]

speaking of JSON,  has anyone got it working for the Volts ?  

Code:

"gpu-vddc" : "1.100",

That line works for my setup.

will try again when I get home, but even when cgminer writes the conf to a file, restarting cgminer will crash.  removing this line will allow it to work.

[DeathAndTaxes]

will try again when I get home, but even when cgminer writes the conf to a file, restarting cgminer will crash.  removing this line will allow it to work.

The value must be valid.  In some instances cgminer will write 0 as voltage which isn't valid and will cause a parsing error.

[jjiimm_64]

But yeah - state exactly what you want with those 2 commands and once the CPU changes happen I'll put those 2 on first priority (for 5 BTC

I would like to add V to the list.  the more i read about undervolting, the more I want to try it.  especially with summer approaching.
Also, since reconfiguring a bunch of rigs will be easy to do from this interface, would be nice to be able to write the config to a file.


Kano,  I am willing to up the anti to get this stuff in....  10btc? anyone else willing to contribute?



1. ability to switch pools (i think setting a pools priority to 0 would work?)
2.  setting the following, for gpus's:

• "intensity" : "newValue",
• "gpu-engine" : "newValue",
• "gpu-vddc" : "newValue",
• "gpu-memclock" : "newValue",
• "gpu-fan":      "newValue",  ex(50-85)

3. ability to write current config to text file:   {command writeConfig,  param filename) (please fix the volt config bug)

[DeathAndTaxes]

But yeah - state exactly what you want with those 2 commands and once the CPU changes happen I'll put those 2 on first priority (for 5 BTC

I would like to add V to the list.  the more i read about undervolting, the more I want to try it.  especially with summer approaching.
Also, since reconfiguring a bunch of rigs will be easy to do from this interface, would be nice to be able to write the config to a file.


Kano,  I am willing to up the anti to get this stuff in....  10btc? anyone else willing to contribute?



1. ability to switch pools (i think setting a pools priority to 0 would work?)
2.  setting the following, for gpus's:

• "intensity" : "newValue",
• "gpu-engine" : "newValue",
• "gpu-vddc" : "newValue",
• "gpu-memclock" : "newValue",
• "gpu-fan":      "newValue",  ex(50-85)

3. ability to write current config to text file:   {command writeConfig,  param filename) (please fix the volt config bug)

I think Kano main objection to modification now is the code base will be changed significantly when cpu mining is removed.  He would rather wait until cpu mining is complete, finalized, and then work off that version for more PRC enhancements.

[jjiimm_64]

Well, I guess I have plenty of work to do getting the webpage working nicely, even before the enhancements are ready although it would be nice to code against a working version

[kano]

IRC

Code:

09:58 < kanoi> conman: question, since I'm far from knowing much about git ... 
               if I make some changes to api.c all this luke crap isn't gonna 
               mean I have to keep redoing it or anything like that? (I can 
               just work off the current version?)

Some changes are happening today or tomorrow.

Code:

10:23 < kanoi> I wait :)
10:23 < kanoi> I'll
10:24 < kanoi> maybe tomorrow or the weekend then

Edit: FYI we are both in Aus - it's Thu morning here

[-ck]

3. ability to write current config to text file:   {command writeConfig,  param filename) (please fix the volt config bug)

The volt config bug is fixed in git. Same with any value that is zero.

[-ck]

Massively updated git tree (new minor version coming soon):

    Display what support is built in.

    BitForce FPGA support
   
    cgminer will scan for and mine BitForce FPGAs on USB ports by providing the
    new --scan-serial <device> option, or autodetect them by searching
    /dev/serial/by-id for *BitFORCE_SHA256*

    Update copyright dates.

    Update README.

    Configure out building and support of all CPU mining code unless --enable-cpumining is enabled.

    Add configuration option for CPU mining which will default to off.

    Update example conf with 1% donation.

    Allow parsed values to be zero which will allow 0 values in the config file to work.

    Advertise that we can make our own midstate, so the pool can skip generating it for us

    Refactor the CPU scanhash_* functions to use a common API. Fixes bugs.
   
    - Before, some returned bool, and others returned int (which was then turned
      into a bool with a comparison); now, everything returns a bool
    - Before, some set hashes_done to nonce - 1 when a share was found and others
      set it to nonce + 1 or 2. This caused some algorithms to scan/submit shares
      twice with the new cpu_scanhash function. Now, it has all been replaced with
      last_nonce, which is set to the final nonce checked by the scanhash_* func.
    - VIA needs the full data, and cannot use midstate. All the others were
      expecting midstate and data+64 for their parameters. Now, we pass midstate
      and the full data pointer, and let the scanhash_* function choose which to
      use.

    Don't consider a pool lagging if a request has only just been filed.
    This should decrease the false positives for "pool not providing work fast enough".

    Invalidating work after longpoll made hash_pop return no work giving a false positive for dead pool.
    Rework hash_pop to retry while finds no staged work until the abstime timeout really expires.

    Remove TCP_NODELAY from curl options as many small packets may be contributing to network overload.

    Refactor miner_thread to be common code for any kind of device
   
    This expands on the device API, by taking the actual main thread out of the
    device's code, and calling the API only for specific tasks. This brings
    various changes that were made to the GPU thread code into the CPU miner.
    It also fixes a bug where shares found on old GPU work were discarded when
    it switched to a new work.

    Simplify submit_nonce loop and avoid potentially missing FOUND - 1 entry. Reported by Luke-Jr.

    Micro-optimisation in sha256_sse2 code courtesy of Guido Ascioti guido.ascioti@gmail.com

    Typo in readme.

   Refactor to abstract device-specific code

[Chefnet]

have you also done something for 7970 optimization?